Authorized Certification Body

Full Title

This description of an Authorized Certification Body (ACB) 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 directed 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. Basis and Scope - while it does not appear to be clearly stated, the intent of 45 CFR (170 and 171) seems to apply to programmers of Health ID systems that reside in EHR's.
   1. It is the intent of this effort to extend the certificate of compliance (CoC) to native apps running on smartphones with a Authorized Certification Body to include the Kantara Initiative.
2. Information Blocking - there must be no action that constitutes information blocking. But this only applies to apps that are from certified developers.
3. 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.
4. 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.
5. 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.
6. Attestations - will be established by the formation of Device Assessment criteria that can be used by test labs to certify app developers.

Definitions

Note that the Final Rule currently applies to what the EHR must support. But all of the following apply to capabilities of mobile apps that should be included in any certified mobile app.

• Certified Application = An application running on a user's personal device (smartphone or similar) that is from a Certified Developer and has been registered with an ACB using the applicable SAC,
• ONC
• Native app = RFC 6749 (https://tools.ietf.org/​html/​rfc6749) describes native applications as “clients installed and executed on the device used by the resource owner (i.e., desktop applications, and native mobile applications).” IETF RFC 8252 (https://tools.ietf.org/​html/​rfc8252), referenced by the HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART IG) (adopted in § 170.215(a)(3)), updates RFC 6749 and provides guidance for OAuth 2.0 authorization requests from native applications. RFC 8252 describes technology and security practices that can be used to enable native applications to securely authenticate their identity and prevent well-documented security threats. Notable examples include Dynamic Client Registration Protocol (IETF RFC 7591) (https://tools.ietf.org/​html/​rfc7591) to enable native applications to receive per-instance client secrets, private-use URI scheme redirect URIs to support native apps to verify their identity, and Proof Key for Code Exchange (PKCE) (IETF RFC 7636) (https://tools.ietf.org/​html/​rfc7636) to secure the authorization code during the authorization process.
• Refresh Tokens = In the ONC Cures Act Proposed Rule (84 FR 7481), we stated, “The SMART Guide specifies the use of `refresh tokens' as optional. We believe that this requirement is necessary in order to enable persistent access by apps, especially in a patient access context. Thus, we propose to make their use mandatory with a minimum refresh token life of three months . . . we wish to emphasize that implementing refresh token support is directly intended to enable a patient's `persistent access' to their electronic health information without special effort (i.e., without having to frequently re-authenticate and re-authorize while using their preferred app).” Recognizing that patients will largely use smartphone applications (native applications) to access their health information, we would substantially limit patients' ability to access their electronic health information without special effort if native applications were categorically excluded from enabling “persistent access.”
• Protections for authentication factors = we identified that it is possible for native applications to use secure storage capabilities and technologies on mobile platforms to secure a refresh token, a client secret, or both. Indeed, section 3.0.1 of the SMART IG provides examples of native applications that can meet either the “confidential app profile” or the “public app profile.” Examples of technologies native applications can use to secure a refresh token, a client secret, or both include operating system-specific features to register application-claimed, private-use Uniform Resource Identifier (URI) schemes as OAuth 2.0 redirect URIs, and technologies that enable applications to securely store credentials through on-device storage. (references were to Android tech specs.)

Code of Conduct

• The following are required of any Authorized Certification Body.

  In the regulatory text, we removed § 170.523(k)(2) to further reduce administrative burden for health IT developers and ONC-ACBs, and included the instructions to do so (85 FR 25951). Because we removed § 170.523(k)(2), the requirement in § 170.523(f)(1)(xxi) that the ONC-ACB include the attestation from that section in its certified product listing should also have been removed. We inadvertently omitted that removal from the amendatory instructions for § 170.523(f) (85 FR 25950). We are correcting the error by removing the requirement in § 170.523(f)(1)(xxi) because the Principles of Proper Conduct for ONC-ACBs should accurately reflect the policies we proposed, the public commented on, and that we then finalized in the ONC Cures Act Final Rule. Further, because the remnant has no meaning in the absence of the other provision, and can impose no benefit or obligation, the correction of such errors does not constitute a substantive change. As such, we therefore find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

Disclaimer

It is suggested that this apply to mobile applications as well.

• from 42 CFR 170.523 (k)(1) (i)

“This Health IT Module is [specify Edition of health IT certification criteria] compliant and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.”

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