The functional requirement is broken down into the following systems or modules:

• Patient
• Patient Fitting History
• Patient Visit Scheduling
• Product Selection
• Hearing Instrument Fitting

This system will allow users to enter, modify and delete patient personal and audiometric information.

1. Allow users to add, modify and delete:
   • Patient Personal Information:
     • Last name.
     • First name.
     • Patient ID Number.
     • Gender.
     • Address.
     • E-mail.
     • Telephones (Home, Work, Mobile).
     • Fax
   • 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.
2. Generate reports.
   • Audiogram Graphs.
   • Patients List.
3. Import Data.
   • Import Patient Data (CSV format).
4. Export Data.
   • Export Patient Data (CSV, NOAH CSV formats).

Patients List

• Filters:

Users will be able to view and delete patient’s fitting session data.

1. Allow users to query patient’s fitting information based on:
   • Date.
   • Circuit/Model.
   • Programming Mode.
2. Generate reports.
   • Fitting history and session notes reports based on information saved during fitting/programming.
   • Instrument Fitting Graphs.

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.

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.

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.

1. Detect/Select instrument from list of all products.
2. Detect a Serial Number mismatch (between instrument and database).
3. Detect an Audiogram mismatch (between instrument and database).
4. Display the following parameters and settings of the read/detected instrument:
   • Model
   • Style
   • Serial No.
   • Memories
   • Memory Access
   • External VC
   • Circuit Adjustment Parameters
   • Prescription Type
5. Make real-time or batch adjustments to the hearing instrument.
6. 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.
7. History List:
   • Keep track of parameter change history (i.e. history list).
   • Allow selective undo's based on that history list.
8. Response curves: Options for viewing such as:
   • Open Fit
   • 2cc Coupler
   • I/O Curves
9. Parameter Adjustments.
   • Allow any parameter to be modified. Offer simple GUI controls for Standard Mode, and advanced options for Expert Mode.
   • Equalizers. Move equalizers in group (see Windows Media Player for behavior).
   • Provide a standard list of parameter groups for all products (disable the group of not applicable to a specific product):
     • Equalizers.
     • Frequency Cut-off (if applicable): Feedback Control (High Cut), Occlusion Control (Low Cut).
     • Compression: Ratio, TK, MPO, Time Constants.
     • Expansion: Ratio, Threshold.
     • Advanced: Mic Inputs, Bass Boost, Power-on Delay, Power-on Level, VC Start Position, Vent size, Dome size, Tubing size / Tubing Type.
     • Adaptive: Feedback Canceller, Noise Reduction, Directionality and Dir Sensibility.
     • Gain: Overall Gain, Volume Control, User VC, Analog/Digital External VC, Mute.
     • Indicator Tones: Memories, Low Battery, Events.
     • Other: Product Style, Serial Number.
     • Datalog.
10. Defaults. Allow applying defaults to an instrument:
    • Test Program (Factory pre-defined).
    • Shipping Program (Factory pre-defined).
    • Custom Program (factory or customer specific).
11. Program (i.e. Burn) new settings to the circuit.
12. Save adjustments/settings to a database file.
13. Technical Support Assistance:
    • Screen capture feature, for quick reporting or troubleshooting. This should perhaps include patient data and product fitting screen (each tab).
    • System Information.
      • Save to file.
      • Send by e-mail.

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.

1. 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)

This feature will provide users with a variety of fitting adjustments and tips to address specific patient complaints.

1. 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
     • Only loud sound too loud
     • All sounds too loud
     • Dishwasher sounds / Water running 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)
2. Display tips for alternative options for addressing the patient's complaint that do not involve programming adjustments to be made.

This feature is utilized to import settings from a previous fitting to the connected hearing instrument or to memory.

1. Retrieve/import saved settings from a previous fitting to the connected hearing instrument or to memory.
2. Users can import saved settings to either the right or the left side.
3. Saved settings can be imported from one memory to any other available memory on multi memory hearing instruments.
4. Users will be allowed to delete saved fitting information.

• 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.

• Allow modification of patient's audiograms at any given time (not just at the beginning of the session). However, warn that the provider has to re-autofit after performing this operation.

• 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.

1. Use 1024×600 dpi screen resolution as the application window minimum size. Basically, allow the application to be used in netbook computers.
2. Maximize window to use full screen size.
3. Use company's marketing colors and/or designs as part of the look-n-feel, wherever possible.
4. Allow application to update the entire look-n-feel with minor changes (using templates/themes/skins).

1. Hint as to which are the required fields. Provide feedback if left empty.
2. Validate birth date input and provide visual cues of locale's date format.
3. Allow keyboard and mouse data entry of Audiogram values.

1. During reading/detecting of hearing instrument, provide visual cues to user as to what is happening (eg. dialog box).
2. For a Binaural Fitting, show both fitting frames. For a Monaural Fitting, show only the frame from the active side.
3. Prompt user to save/burn fitting when exiting Fitting and changes to instrument were never saved/burnt.
4. Hide Advanced Features from default screen layout.
5. Provide car-stereo type equalizers that are standard for all products.

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).

• Notify user in a message window of any on-going operation, especially when interacting with the programming box, or any operation that takes a long time.

The system must be able to store fitting data to any source. It should write and read data from:

• a stand-alone database
• a NOAH database
• any other source (XML, Text, etc.).

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).

• Skinnable.
• Uniform look-n-feel across products.
• Uniform notation and terms across products.
• Company colors and theme.

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.

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.

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).

Which users can do which things and when.

• System must not damage circuitry.
• System must not cause any hearing damage while in user or patient’s ear.

1. 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.
2. 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.

• 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.

The certification requirements and standards the software must meet.

• NOAH 3.0 and 4.0 certification (from HIMSA).
• NOAHLink certification (from HIMSA).
• HIPAA compliance (see US Dept. of Health & Human Services, and also HIPAA).