Authorized Certification Body

Full Title

This description of an Authorized Certification Body applies solely to the evaluation of applications used by Patients or authorized users to access Electronic Health Information (EHI) and upload of data to providers.

Goals

1. Put the user in control of the capability of using their own personal devices for access to their own data like personal health information. See wiki page on Patient Choice.
2. Allow certified mobile apps to assert its own assurance level to web sites on the internet.
3. Align with the evolving mobile driver’s license effort as source of identity proofing with minimal personal data disclosure (in cooperation with the Kantara PIMDL work group).

Context

• The 21st Century Cures Act (see references) requires "seamless and secure access, exchange, and use of electronic health information" by the patient or their authorized proxies.
  • It also addresses the interchange of data among health care providers, which is not covered in this proposal.
• Much of the language used in the Cures Act is directled towards Health IT Modules running in provider's web sites. It is adapted here to the case of Health IT for patients and their proxies.

Problems

In a Kantara work group report on Patient Choice it is shown that applications running on user’s device have not been able to secure user data. In order for records to be downloaded to user’s devices, it is known that some level of certification of the apps, or at least the developers of the apps, some structure must be in place that can report that the app will be sufficiently responsive to patient needs for security and privacy. This is a proposal to seek funding from the US HHS ONC to build out and create a long-term funding plan for a testing assurance program as well as an online registry that can be queried in real-time to validate apps prior to downloading patient information onto them.

Solutions

This solution for user apps is based on existing requirements of the ONC for EHR. Since that EHR solution required a trust infrastructure, it is proposed to take a similar approach to user apps.

• See the documentation on What You Need to Know About the Conditions and Maintenance of Certification.
• It is assumed here that the most common patient device will be a smart phone but other devices like laptops and wearable or home medical devices will also be addressed in the future.

1. Information Blocking - there must be no action that constitutes information blocking. But this only applies to apps that are from certified developers.
2. The following communications must be provided for Health IT apps.
   1. The user ability of the app.
   2. The interoperability of the apis used by the app.
   3. The security of the app.
   4. User experiences when patients or delegates use the app.
   5. Business practices of the app developers.
   6. The manner in which the technologies in the app have been used in health IT.
3. Application Programming Interfaces (APIs) that are used for communications with:
   1. Electronic Health Records Providers (EHR) or Health Information Exchanges (HIE).
   2. OpenID Providers of Identity Services
   3. Credential Services Providers for both (1) Patient Identity Proofing and (2) patient authentication using 2 factors both communicated directly for the patient's device.
   4. Medical Record Locator Services
   5. Trust Registries of providers of authorized certification.
4. Real World Testing
   1. Set up of a test EHR or HIE
   2. User Experience test program for users in as many categories as time allows.
5. Attestations - will be established by the formation of Device Assessment criteria that can be used by test labs to certify app developers.

References

• ONC’s Cures Act Final Rule supports seamless and secure access, exchange, and use of electronic health information
• ONC's Cures Act Final Rule