The functional requirement is broken down into two (2) systems or modules.

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. Export Data.
   • Export Patient Data (CSV, NOAH CSV formats).

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.

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. Automatically read and detect the model and style of the circuit and display its content to screen.
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 instrument that was read/detected:
   • 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. 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. Burn/program new settings to the circuit.
8. Save adjustments/settings to a database file.

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:
   • WDRC
   • AGC-o
   • Linear
   • Restaurant
   • Telephone
   • Music
   • Television
   • Theatre / Place of Worship
   • Intense Noise
   • AutoAdapt (for Adaptive Directional products)

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.

This feature allows memory's fitting parameters to be copied to another memory program in the same ear.

1. Users will be allowed to copy a selected memory’s fitting parameters to another memory in the same ear.

1. Use 1024×768 dpi screen resolution as the application window minimum size.
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 source. It should read data from a stand-alone database, or from a NOAH database, or any other source for that matter. 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).

The system must be able to store fitting data to any source. It should write and read data from a stand-alone database, or from a NOAH database, or 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).

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 under Windows 95, 98, ME, 2000, XP, 2003, and Vista.
• Database Engine: Firebird.
• Database Connectiviy: Multi-user.
• Network: TCP/IP.
• End Users: Production, Quality Control, Audiologist, Dispensers, Module Accounts, Engineers.

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 2.0 and 3.0 certification (from HIMSA[]). * NOAHLink certification (from [[http://www.himsa.com|HIMSA[]). * HIPAA compliance (see [[http://www.hhs.gov/ocr/hipaa|US Dept. of Health & Human Services, and also HIPAA).