ezFIT 5 Software Requirements
Functional Requirements
The functional requirement is broken down into the following systems or modules:
Patient
This system will allow users to enter, modify and delete patient personal and audiometric information.
Allow users to add, modify and delete:
Patient Personal Information:
Additional Information (Optional)
Occupation
Social Security Number
Referral
Physician
Insurance 1 Name
Insurance 1 Number
Insurance 2 Name
Insurance 2 Number
Other
Patient Audiometric Information:
Speech Test Results (SRT, MCL, UCL).
Style of hearing instrument used.
Audiograms (Left and Right): Air Conduction, with Speech and Sound Shadows.
Generate reports.
Audiogram Graphs.
Patients List.
Import Data.
Export Data.
Reports
Patients List
Patient's Fitting History
Users will be able to view and delete patient’s fitting session data.
Allow users to query patient’s fitting information based on:
Date.
Circuit/Model.
Programming Mode.
Generate reports.
Patient Visit Scheduling
Optional module supporting the following:
List of office hours available for appointment.
Allow booking a certain time slot for a patient visit (appointment).
Allow editing or deleting appointment slots.
Allow sending email appointment notifications to patients.
Product Selection
When getting ready to fit an instrument, provide a list of products (whether available or discontinued) appropriate for the patient's hearing loss. The product should also display information relating to it such as:
Product Description.
Detailed Specifications.
Product Range against the current patient's hearing loss.
Styles supported, highlighting the suggested styles to use for the current patient's hearing loss.
Product image.
Once the product is selected, perform the following:
Read or Detect Instrument. If reading fails, automatically try to detect the model and style of the instrument, and display its content to screen.
Simulate Instrument. Use default parameter values to simulate in screen.
Cancel / Exit.
Fitting (Adjusting hearing instrument parameters to fit patient's hearing loss)
This system will allow users the capability of programming hearing instruments and simplifying the fitting process with automated fitting and fine-tuning algorithms. Patient’s fitting data can be saved for use during future programming and fitting adjustments.
Programming Instrument
-
Detect a Serial Number mismatch (between instrument and database).
Detect an Audiogram mismatch (between instrument and database).
Display the following parameters and settings of the read/detected instrument:
Make real-time or batch adjustments to the hearing instrument.
Binaural linking: Optionally, in a binaural fit, link both instruments and screens automatically, so that changes on one side (left or right) can be applied automatically to the other side.
History List:
Response curves: Options for viewing such as:
Open Fit
2cc Coupler
I/O Curves
Parameter Adjustments.
Defaults. Allow applying defaults to an instrument:
Test Program (Factory pre-defined).
Shipping Program (Factory pre-defined).
Custom Program (factory or customer specific).
Program (i.e. Burn) new settings to the circuit.
Save adjustments/settings to a database file.
Technical Support Assistance:
Autofit/Environmental Settings
This system will allow users to automatically adjust the hearing instrument parameters according to the patient's audiogram. There are several different autofits and environmental settings available depending on the circuitry of the hearing instrument and the patient's listening needs.
Automatically adjust the hearing instrument parameters to best-fit patient's audiometric information and selected prescription type. Possible Autofit types:
Normal (WDRC)
AGC-o
Linear
Restaurant / Party
Telephone
Music
Television
Theatre / Place of Worship
Intense Noise
AutoAdapt (for products supporting Adaptive Directionality)
IntelliScan (for products supporting Scene Detection)
Clarujust (if supported)
Fitting Solutions Guide
This feature will provide users with a variety of fitting adjustments and tips to address specific patient complaints.
Automatically applies adjustments to hearing instrument parameters to address specific patient complaints. Common issues are:
Feedback / Chirping
Barrel / Hollow / Echo / Plugged / Occlusion
Background Noise
Rushing Water / Fan Noise / Static / Circuit Noise
Can hear but not understand / Speech is unclear
Own Voice
Nasal/Stuffy
Booming Echo
Tinny / Harsh / Raspy
Can hear distant sounds but not close up
Too Loud
Too Soft (Weak)
Soft sounds too soft
All sounds too soft
Sounds Tinny / Harsh / Raspy
No perceived benefit
Pumping (cuts in and out)
Display tips for alternative options for addressing the patient's complaint that do not involve programming adjustments to be made.
Importing Fitting
This feature is utilized to import settings from a previous fitting to the connected hearing instrument or to memory.
Retrieve/import saved settings from a previous fitting to the connected hearing instrument or to memory.
Users can import saved settings to either the right or the left side.
Saved settings can be imported from one memory to any other available memory on multi memory hearing instruments.
Users will be allowed to delete saved fitting information.
Copying Parameters
Current Instrument Memory: Allow copying a selected memory’s fitting parameters to another memory in the same ear side.
Other Intrument Memory (aka Linked Programming): Allow the current instrument's memory settings to be copied to the other side (other ear). This simplifies the binaural fitting of instruments when each ear has similar hearing loss.
Audiograms
Standard Audiograms
In Situ Audiograms
Ensure that if a new in situ audiogram is created that this is stored as a session. The purpose is to record each of the audiograms created as an audit trail and troubleshooting tool. If a patient is tested (hearing) each year, and then their hearing aid programmed, the audiogram function in 4.x simply replaces the old one in the database. It is not set up to store the audiogram as a session. Additionally, if the in situ verification is used to program the hearing aid, it would be wise to have a record of the audiogram from that session so that the provider can determine that xyz audiogram was used, which was performed via in situ verification on the patient to program the hearing aid. Without the information recorded anywhere, there is no leg for a provider to stand on for why the hearing aid is programmed a specific way and with the values being so different in some cases up to 15 - 20 dB.
NOTE: In ezFIT 4.x, this is an issue since once the in situ audiogram is selected and saved, that replaces the audiogram in the hearing aid and database. That was by design. We need to support both audiograms, but that will be left for the next platform…We only have space to save one audiogram in each hearing aid, and that is the main reason we replace the audiogram altogether.
User Interface Requirements
General
Use 1024×600 dpi screen resolution as the application window minimum size. Basically, allow the application to be used in netbook computers.
Maximize window to use full screen size.
Use company's marketing colors and/or designs as part of the look-n-feel, wherever possible.
Allow application to update the entire look-n-feel with minor changes (using templates/themes/skins).
Patient
Hint as to which are the required fields. Provide feedback if left empty.
Validate birth date input and provide visual cues of locale's date format.
Allow keyboard and mouse data entry of Audiogram values.
Fitting
Programming Instrument
During reading/detecting of hearing instrument, provide visual cues to user as to what is happening (eg. dialog box).
For a Binaural Fitting, show both fitting frames. For a Monaural Fitting, show only the frame from the active side.
Prompt user to save/burn fitting when exiting Fitting and changes to instrument were never saved/burnt.
Hide Advanced Features from default screen layout.
Provide car-stereo type equalizers that are standard for all products.
Implementation Requirements
Patient
The system must be able to read patient data from any of the following sources. It should read data from:
Stand-alone database.
NOAH database.
CSV file.
XML file.
Keeping this in mind, the design must allow a modular setup, in which data is always displayed the same way, but data is read from its source dependent on the setup/mode (stand-alone or NOAH).
Fitting
Programming Instrument
The system must be able to store fitting data to any source. It should write and read data from:
Keeping this in mind, the design must allow a modular setup when it requires writing or reading fitting session data. Data to be written or read is always formatted the same way, but the final low level write/read is going to be dependent on the setup/mode (stand-alone or NOAH).
Graphical User Interface
Skinnable.
Uniform look-n-feel across products.
Uniform notation and terms across products.
Company colors and theme.
Non-Functional Requirements
Environmental
The minimal environment in which the software will have to operate.
Hardware: PC compatible, 900
MHz Processor, 64MB RAM, 30
MB free disk space, serial or USB port.
Operating System: Allow execution using using Microsoft .NET under Windows 2000, XP, 2003, Vista, and 7.
Database Engine: Firebird (embedded for local database, server for network setup).
Database Connectiviy: Multi-user.
Network: TCP/IP.
Server: PHP scripts.
End Users: Providers (Audiologists and Dispensers), Production, Quality Control, Engineers, and Module Accounts.
The minimum performance requirements to operate.
Must launch and execute within 15 sec.
Must perform fittings within chip manufacturer‘s specified time (when using a Hi-Pro programming box).
Must read and write to database (local or server) within 15 sec of a database operation request.
Robustness
The sorts of abuse the software will have to resist, and how it will respond.
System must be able to recover from a corrupted database – even after a crash.
System must deny illegal requests politely.
System must not crash due to lack of storage or user overload.
Scalability
The capacity to grow as business needs change.
Single machine installation: Provide embedded database engine (Firebird).
Small to medium business with several machines: Allow network deployment using client-server model (Firebird server for Windows).
Safety
Which users can do which things and when.
Documentation
User documentation must be detailed, complete and accurate. It should include:
Hardware and software requirements.
Installation instructions.
Fitting tutorial.
Frequently asked questions.
Support contact information.
System documentation must be detailed, complete and accurate. It needs to include:
Individual components and their functionality, hierarchy, inheritance and relationships.
Integration, installation and deployment instructions.
Test procedures.
Security
By complying with HIPAA regulations, most security concerns should be addressed. This would also take care of the European requirements, since currently, they are not as strict as the HIPAA regulations.
Certification
The certification requirements and standards the software must meet.
NOAH 3.0 and 4.0 certification (from
HIMSA).
NOAHLink certification (from
HIMSA).
-