Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Identity Helpers:

  • Provide features that help Manufacturer Back End Systems more quickly identify HCB's, HCP's, and patients as they interact with Manufacture Back End Systems.

Child pages (Children Display)
Image RemovedImage Added


Info

Many of the below points use the phrase "General Noah Storage Benefit" to describe a rationale.  The benefit of storing information in Noah provides the following benefits compared to storing the data outside of Noah (e.g. storing the information in a system registry key, xml file, stored on a computer)

  • The data is stored inside the Noah database. Data is easily backed up and restored with the other important patient data.  The database is also a more secure storage location.

  • If the new PC is implemented (which hosts the database), then moving the database to the new PC will result in keeping the information.

  • If the Noah installation is networked, then data will be available on each Noah workstation automatically.  Between 50-60% of installations use a shared database between computers inside the business.


Title

User Story

Notes

HIMSA Member application stores private data for the Hearing Care Business (HCB)

As a HIMSA member company, I have the ability to store and retrieve important information in Noah that my application will use as it pertains to a HCB.  Examples of this type of data are:

  • HCB account number

  • Preferences for software settings

Rationale: General Noah Storage Benefit

Q: Is it possible for other company applications to read this private data?

A: No.  HIMSA API's will not make this possible.

This is an available feature for the Module API but not yet the Noah Web API.

See Diagram 1 below.

Noah provides a globally unique Hearing Care Business / Noah Installation ID

Member company Noah compatible applications are able to read a globally unique ID for the HCB which is the Noah Mobile Alias.  The Noah module API now makes it possible to read the Noah Mobile Alias.

Rationale: This ID provides an additional identifier that can be used by the member company's outside systems.

Q: Why is the phrase "Noah Installation" mentioned in the title?

A: From the perspective of a Noah installation, the database is seen as unique.  If a HCB has 3 non-networked installations of Noah then each installation is seen as unique, HIMSA has no way to know that these 3 separate installations are for the same HCB.

This situation is also the case if a HCB runs 3 physically distinct offices.  Each office may share a database in each office but Noah/HIMSA has no hard knowledge that they are the same company.

Further, it is possible that Noah is setup so that a database is shared by many offices.

The unique ID will be the Noah Mobile Alias.  Starting with Noah 4.10 the ModuleApi has been extended with a new method ‘GetNamesForRemoteHost()’ which return a collection of aliases/remotehost names.

Q: What will happen if a back end system sends patient data to the wrong Noah installation?

A: HIMSA will reject the data and return an error code.


HIMSA Member application stores private data for the Hearing Care Professional (HCP)

As a HIMSA member company, I have the ability to store and retrieve important information in Noah that my application will use as it pertains to a HCP.  Examples of this type of data are:

  • A member company system user ID

  • Preferences for software settings

Rationale: General Noah Storage Benefit

This is an available feature for the Module API but not yet the Noah Web API

See Diagram 1 below.

Noah provides a globally unique Hearing HCP ID

Member company Noah compatible applications are able to read a globally unique ID for the HCP. The member company application can read this ID and enclose it with data that is sent outside of the Noah installation.

Rationale: This ID will provide as an additional identifier that can be used by the member company's outside systems.

With Noah 4.12 and newer, each Noah user will have a GUID assigned to it.

HIMSA Member application stores private data for Noah patient records

As a HIMSA member company I have the ability to store and retrieve important information in Noah that my application will use as it pertains to a specific patient.  Examples of this type of data are:

  • A member company system patient ID

  • Information such as "Is patient a first time hearing aid user?"

Rationale: General Noah Storage Benefit

This is an available feature for the Module API but not yet the Noah Web API

See Diagram 1 below.




Noah provides a globally unique Patient ID

Member company Noah compatible applications are able to read a globally unique ID for patient records.The member company application can read this ID and enclose it with data that is sent outside of the Noah installation.

Rationale: This ID will provide as an additional identifier that can be used by the member company's outside systems.

Noah patient records have a patient GUID.

Noah Will NOT append application links with additional ID's or information

When links to another application are activated by a HCP (as a Noah user), Noah activates the linking information provided by the member company.  Noah will not add any additional information in the activation of the link.

The link is provided to Noah from the manufacturer's back end system.  Any and all information the back end needs to operate will need to be included in the link provided to Noah.



Diagram

Image Modified