ONC Certification Documentation for the Coral Health’s Records app:

This page provides a series of answers to comply with ONC information requirements on how our app handles the user data.



45 CFR 170.315 (b)(6) (Data Export):

A user can configure the technology to create export summaries using the Continuity of Care Document document template.


All records in the application, regardless of where they are imported from, can be exported in the Continuity of Care Document document template format. To export a document the user can use the actions menu on a given record, or activate the functionality by performing a long press action on the record display information.




45 CFR 170.315 (d)(1) (Authentication, Access Control, Authorization):

Verify against a unique identifier(s) (e.g., username or number) that a user seeking access to electronic health information is the one claimed; and [...] establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided.


We use SMART on FHIR OAuth2 authentication protocol, where we uniquely identify the user by their user id, which is provided to our application when connecting to the FHIR enabled authentication system. The authentication grants access only to the patients' records.



45 CFR 170.315 (d)(2) (Auditable Events and Tamper-resistance):

The health IT records actions pertaining to electronic health information [...] when health IT is in use; changes to user privileges when health IT is in use; and records the date and time [each action occurs]. [...] The health IT records the audit log status [...] when the audit log status is changed and records the date and time each action occurs. [...] The health IT records the information [...] when the encryption status of locally stored electronic health information on end-user devices is changed and records the date and time each action occurs.


Our app features an audit log in the Setting tab, which is tamper proof and can be exported from the app as needed by the end user. Each entry in the audit log contains a cryptographic hash of the entry data and the previous entry hash. By using this approach we can gurantee that the audit log is tamper proof and immutable.




45 CFR 170.315 (d)(3) (Audit Report(s)):

Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data.


Our apps' audit report allows for sorting on each of the columns and can be exported in CSV format. Once exported, the user can use third-party tools, such as Microsoft Excel to do advanced filtering on the data based on date, event type or additional information. To achieve in-app sorting, the user can tap on the column headers, which toggles between ascending/descending sort ordering on the selected column.




45 CFR 170.315 (d)(5) (Automatic Access Time-out):

Automatically stop user access to health information after a predetermined period of inactivity. [...] Require user authentication in order to resume or regain the access that was stopped.


Since we are providing a mobile app this feature is built into the two supported mobile app platforms, Android and iOS. After period of inactivity the phone screen goes into a locked state. This is set-up by default by both mobile operating system manufacturers and can be further configured to include biometric information as well as device lock time-out periods. The standard OAuth2 flow uses expiring tokens, which prevent subsequent data refresh without new log-in after a period of inactivity.



45 CFR 170.315 (d)(7) (End-user Device Encryption):

Technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of the technology on those devices stops [or] technology is designed to prevent electronic health information from being locally stored on end-user devices after use of the technology on those devices stops.


All health record information stored on device is encrypted at all times using the AES-CTR 256-bit symmetric encryption. The encryption key is generated using secure on-device random generator and is stored in the device secure keystore. Unencrypted information, in order to be presented to the end user, exists only in memory while the user is using the app and is never written on the device storage.



45 CFR 170.315 (d)(8) (Integrity):

Verify [...] upon receipt of electronically exchanged health information that such information has not been altered.


All communication with third-party servers (through FHIR) is done using HTTPS (SSL) which does integrity checks on the data within the protocol. We produce SHA256 hashes on all internally created data.



45 CFR 170.315 (d)(9) (Trusted Connection):

Health IT needs to provide a level of trusted connection using either 1) encrypted and integrity message protection or 2) a trusted connection for transport.


All communication with third-party servers (through FHIR) is done using HTTPS (SSL) which does integrity checks on the data within the protocol. Only HTTPS servers certificates issued by a certification authority are accepted by our application.



45 CFR 170.315 (d)(11) (Accounting of Disclosures):

Record disclosures made for treatment, payment, and health care operations.


Not applicable. Our application simply pulls existing EHR records from third-party providers and it's not the primary source of the health information.



45 CFR 170.315 (g)(3) (Safety-enhanced Design):

User-centered design processes must be applied to each capability technology.


Our application follows the material design patterns and it's built using the standard material design components. All parts of the user interface have undergone extensive user experience testing.



45 CFR 170.315 (g)(4) (Quality Management System):

For each capability that a technology includes and for which that capability's certification is sought, the use of a Quality Management System (QMS) in the development, testing, implementation, and maintenance of that capability must be identified.


Each functionality of the application is subjected to standard suite of automated unit tests and integration tests. These tests run every time a developer makes a change in the application source code. No net new source code change is accepted without tests proving that the change is correct. Each new release of the application is also subjected to extensive manual user experience and accessibility testing.



45 CFR 170.315 (g)(5) (Accessibility-centered Design):

The use of a health IT accessibility-centered design standard or law in the development, testing, implementation and maintenance of that capability must be identified.


Each new release of the application is subjected to extensive accessibility testing. Part of our QMS ensures that the application can be used with a screen reader functionality on both Android and iOS. All visual components that are not text are appropriately labeled with tooltips for visual aid.



45 CFR 170.315 (g)(7) (Application Access - Patient Selection):

The technology must be able to receive a request with sufficient information to uniquely identify a patient and return an ID or other token that can be used by an application to subsequently execute requests for that patient’s data.


Not applicable. Our application is a mobile application that connects to third-party systems via SMART on FHIR and all user authentication and verification is done by the third-party authentication portal (OAuth2).



45 CFR 170.315 (g)(8) (Application Access - Data Category Request):

Respond to requests for patient data (based on an ID or other token) for each of the individual data categories specified in the Common Clinical Data Set and return the full set of data for that data category (according to the specified standards, where applicable) in a computable format.


Not applicable. Our application is a mobile application that can only be manually operated by a user. The application does not provide means for remote connection to it. Manually triggered export in the Common Clinical Data Set format is available within the application.



45 CFR 170.315 (g)(9) (Application Access - All Data Request):

Respond to requests for patient data (based on an ID or other token) for all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified standards, where applicable) in a summary record formatted [...] following the CCD document template.


Not applicable. Our application is a mobile application that can only be manually operated by a user. The application does not provide means for remote connection to it. Manually triggered export in the Common Clinical Data Set format is available within the application.



45 CFR 170.523 (k)(1) (Pricing Transparency):

Any additional types of costs that an EP, EH, or CAH would pay to implement the Complete EHR's or EHR Module's capabilities in order to attempt to meet meaningful use objectives and measures.


Not applicable. Our application is provided free of charge.



45 CFR 170.523 (n) (Complaint Process):

Submit a list of complaints received to the National Coordinator on a quarterly basis each calendar year that includes the number of complaints received, the nature/substance of each complaint, and the type of complainant for each complaint.


We are compliant with this request.

Explore our solutions for

Providers and Labs

Providers and Labs

Seamlessly view your patients’ full history so you can focus on truly personalized care.

Payers

Payers

Cut manual effort and costs by automating multi-party administrative processes.

Life Sciences

Life Sciences

Access the critical data needed to facilitate life-saving drug discovery.

Public Health Authorities

Public Health Authorities

Isolate and respond to disease outbreaks before they spread.