App Data Access Rules and Use of Data

The document below covers ideas that are suggested to be implemented with the Noah Mobile project. The rules for access and use of data are brought up for the following reasons:

Noah Mobile opens the level of access to patient’s records. It is important that Hearing Care Professionals (HCP’s) feel that their patient data remains private.
The introduction of the Noah Mobile Relay service to remotely connect computing devices (e.g. tablets) to Hearing Care Professional Businesses (HCPB’s) does raise the bar in regards to ensuring that HIMSA’s overall security plan for Noah is well thought out.

Reader’s prerequisite - please read “App Development Categories” before the content in this document. The explanation of category types (user interactive vs. service) is essential.

REVIEWING AND USING DATA CREATED BY OTHER HEARING INSTRUMENT MANUFACTURERS

Today, with modules, it is possible for Manufacturer A to see that there is a fitting record for Manufacture B for a given selected patient. Module A cannot read the fitting data as it is not standardized and as there is only one patient selected, it is hard to imagine misuse of data (e.g. learning about the HCPB practices).

With Noah mobile, apps will have the technical ability to see other manufacturer activity across many patients. It was once considered if Noah should hide data, such as Manufacturer B created data from A, but that idea was rejected by the hearing instrument manufacturers. Including data hiding rules would then have adverse usability aspects such as:

Manufacturer A’s app would not be able to look for the presence of previous hearing instrument selections (from other manufacturers). Without this ability, the app would not be able to determine in an automated fashion, that the patient is not a first time instrument user.
It is envisioned that many apps will show a list of patient activity after a patient has been selected – something similar to what the Noah 4 session browser showstoday. Without having access to all actions, it would be impossible for the app create the complete session history and it is felt that many HPC’s would find this confusing, some may feel that the app is not working correctly. An app developer is prohibited to use other licenses fitting actions for the purpose of getting information on competitors’ business.

DATA ACCESS CONTROLS AVAILABLE TO THE HCPB

The HCPB has the following tools available to control access to their data:

They will have the ability to first grant that an app has access to the data in Noah; the app has to be approved by a Noah user having administrative privileges.
The HCPB can also restrict access to the amount of patient demographic data that is available to the app.
Logging of all data access is supported by an extensive audit trail system. The audit trail system provides the HCP with the ability to review data access as monitored by Noah. This is seen as the most effective tool to help ensure that app developers are accessing and using the data contained in Noah correctly. The Noah mobile API SDK documentation will also mention the fact that all access is being tracked and can be reviewed by the HCP. This should provide as a natural deterrent to data misuse.

Please see the user stories available in section 2.X of the Noah Mobile user story collection for more information.

OVERVIEW OF USE OF COPIED DATA

Once an app has gained access to a piece of data it then has the technical ability to use it to create another piece of data. A prime example of this would be that of a fitting module reading a pure tone audiogram in order to create a fitting action.

Who is the owner of the data? HIMSA assumes that the true owner of the data is the HCPB that ran the software which created the resulting data. The concept of ownership can become confusing depending on the data consumer’s point of view.

If the app does copy data, then the real important aspect is how properly the data is controlled once it has been copied.

In order to make this simple for all parties to follow HIMSA will design policies which deal with data that is copied. HIMSA believes that all member companies do want to handle data in an ethical and legal manner. These policies are not written with the assumption that a member will at some point misuse data but, rather, to address the topic that is on everybody’s mind these days. It is wise to have good policies in place to help deter any misuse. If one company misuses data, then there is a very good chance that HCP’s will lose trust in the complete system thus affecting all member companies relying on Noah Mobile.

Default use of data restrictions

Rather than focusing on the ownership of data the following default data restrictions will be in place for all apps.
In general an app can copy data to different computing systems but in a restrictive manner. The data can be copied for its stated intended use and nothing else.

Apps are not allowed to copy data except in the following situations:

Explicit notification of data copy. The app clearly makes it known in the GUI that the data will be transferred to another system and for what purpose.
Implicit notification of data copy. Through the use of the app it is reasonably obvious to a HCP that the data will be transferred to another system. Examples being:
1. A browser based order app where the pure tone audiogram is needed as part of the order and is shown on the order form. The audiogram was copied to the server hosting the browser based page.
2. An Android based app running on a tablet may read all actions for a selected patient record so that it can create a list of past activity and then create a session list similar to what Noah System provides today. In this case it is assumed that the app will have a copy of the data on the device in order to display the data.
3. A synchronization feature where the app will copy all or large subsets of patient data for use when the app does not have the possibility to be connected to Noah.
Service apps can work in an automated fashion as an interactive user is not necessarily watching what is going on. HIMSA will require contractual assurances that the service app developer clearly state to their users, in writing, how they use the data collected.
Data copied by A, B, and C above cannot be used for any other purpose then originally copied for. This also means that even if the data is patient de-identified (i.e. name is stripped off) it still cannot be used for any other purpose. Using the order app – audiogram example above, this would mean that the company copying the audiogram could not combine this audiogram with other patient audiograms to run analysis on hearing loss vs. types of instruments ordered.
a. Note: Please keep in mind that most countries today have strict rules on the use of patient related data (e.g. HIPAA). These rules will also act as a very powerful deterrent from inappropriate use of data. However, once data has become de-identified HIPAA no longer applies.
The HIMSA certification process will be fashioned to ask for details about what data might be copied out of Noah and then verify that either A, B, or C is met. HIMSA will not be able to test for the compliance on this particular point but will rather ask the member company to document the use of this data. HIMSA assumes that the member company will provide the users with a EULA or reference to some other document which outlines the apps use of data.
What happens if somebody breaks the rules? What happens if a member company uses data (or data in a manner not approved by the HCPB)? Besides the HCPB taking whatever action it feels is necessary, HIMSA will reserve the right to consider options such as:
a. Revoking certification of the app(s) involved
b. Blocking the app from using the HIMSA provided cloud services.

Special provisions for use of data?
Q: Can an app developer make an agreement (e.g. a contractual agreement) with an HCPB to gather (copy) and use the copied data for other uses, compared to default restrictions listed above?
A: Yes, as long as the end user is aware that this activity is taking place, then this is a business relationship issue between the app developer and the HCPB.

STATES OF DATA – AUDIT TRAIL AND DATA PROTECTION

Data is often considered to be in 1 of 3 states from an IT perspective: Data in use, motion and rest. To aid in this next section the following definitions are used:

Data in motion / data that is being moved across a network or computer memory with the understanding that it will be read or updated.
Data in use / data that is ready to be read or potentially updated
Data at rest / data that is not in use, or no intention of use. The data is stored as an archive. In the case of Noah mobile, “data at rest” is not considered as Noah does not provide a feature to archive data out of the Noah database. All data is in the database and could be called up by Noah or a module/app at any time – it is considered “Data at rest”.

Data will be in motion as an app reads and writes data with Noah. In this case Noah has the responsibility to exchange the data in a secure method (e.g. https). Apps do not have any special requirements to fulfill.

The main focus is the “data in use”. In the context of this section both data protection and the audit trail are of particular interest.

Today, with modules, this topic is not as important as the module which is running on the same physical computer that the Noah software is and the data being exchanged is done so in the computer’s memory, then transferred across the internal network, encrypted, and then stored in a database on a Windows computer.

It is also recommended that the computer holding the database have its drive encrypted if the computer is found to have any reasonable risk of loss or theft. Click here for more details.

If the app is integrating with Noah using the Noah mobile API, then it does expose itself to performing more tasks that were taken care of by Windows or Noah.

Requirement – “data in use” must be encrypted or the HCP must have a way to enable a situation where the database be encrypted. Examples of this would be:

HIMSA’s recommendation for PC laptops is to enable drive encryption.
iOS provides encryption, see https://support.apple.com/en-us/HT202064

Why? In general it is standard data security practice but it becomes more important for portable devices such as laptop and tablets. Being portable increases the chance of loss or theft. Loss of a device with patient related data, not encrypted, would be a severe violation of security mandates (e.g. HIPAA).

What does this mean to an app developer?

If “data in use” is used in the app then it should be encrypted if it resides on the device. The app developer should strongly encourage the use of an encryption method they feel is appropriate for their users. HIMSA will also spend time creating support documentation on this topic for the common devices known to be used.
It is highly suggested that any data obtained from Noah and “in use” in an app should be completely deleted/destroyed from that app immediately after use. If this method is followed, and the data obtained was not copied elsewhere, then the Audit trail requirements will be fulfilled – see US 2.03 “Recording Access to Patient Data” for more details.
If the app does leave any of the data obtained from Noah in the app after use then the app developer has the responsibility to track which user(s) later adds data, reads, or updates any of the data – essentially the app will need to recreate the features discussed in US 2.0.3 or use the features support via the Noah mobile API to facilitate these features.
- For example, an iOS based app provides features to synchronize data between data stored in the Noah database and the app. The app will need to provide an authentication method as well as track the items listed in 2.0.3. The Noah audit trail be added by the app at a centralized location but the app still has the responsibility to watch for the events that need to be recorded.

Q: Why does HIMSA list the above as a requirement?
A: HIMSA would like to ensure that the same level of data security that is available today with Windows based modules are not decreased with the Noah mobile API. HCP’s place a lot of faith in storing and securing their data correctly and just assume that this will always be the case.