Printer Friendly, PDF & Email Printer Friendly, PDF & Email

§170.315(g)(9) Application access — all data request

Version 1.1 Updated on 03-08-2016
Revision History
Version # Description of Change Version Date
1.0

Final Test Procedure

01-20-2016
1.1

Removed reference to time in paragraph (g)(9)(i)(B) Test Lab Verification step 1.

03-08-2016
Regulation Text
Regulation Text

§170.315 (g)(9) Application access – all data request

The following technical outcome and conditions must be met through the demonstration of an application programming interface.

  1. Functional requirements.
    1. 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 according to the standard specified in §170.205(a)(4) following the CCD document template.
    2. Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.
  2. Documentation—
    1. The API must include accompanying documentation that contains, at a minimum:
      1. API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.
      2. The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).
      3. Terms of use. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements.
    2. The documentation used to meet paragraph (g)(9)(ii)(A) of this section must be available via a publicly accessible hyperlink.
Standard(s) Referenced

Paragraph (g)(9)(i)(A)

§ 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1, August 2015

Please refer to the Data Elements and Vocabularies applicable to the Common Clinical Data Set (CCDS) as outlined in the Common Clinical Data Set Reference Document

Please consult the Final Rule entitled: 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications for a detailed description of the certification criterion with which these testing steps are associated. We also encourage developers to consult the Certification Companion Guide in tandem with the test procedure as they provide clarifications that may be useful for product development and testing.

Note: The order in which the test steps are listed reflects the sequence of the certification criterion and does not necessarily prescribe the order in which the test should take place.
 

Testing components

No GAP Icon Documentation Icon Visual Inspection Icon Test Tool Icon ONC Supplied Test Data Icon

The following technical outcome and conditions must be met through the demonstration of an application programming interface.

 

Paragraph (g)(9)(i)(A)

System Under Test Test Lab Verification

Setup

  1. Using the ETT: Message Validators – C-CDA R2.1 Validator, the health IT developer downloads the ONC-supplied data instructions through the sender download selections of the “APIAccess_Amb” or “APIAccess_Inp” criteria and one of the API instruction documents, and then executes the download.

Demonstrate API

  1. Using the ONC-supplied API instruction document returned in step 1 and the Health IT Module’s identified API functions (including the ID or token generated as part of the “Application Access – patient selection” certification criterion at § 170.315(g)(7)), the user demonstrates that the API responds to and returns all data from the Common Clinical Data Set in a summary record formatted in accordance with the standard adopted at § 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, DSTU Release 2.1 following the CCD document template and including the CCDS data requirements as specified in the CCDS Reference Document for the unique patient identified by the ID or token.
  2. For each CCD document created in step 2, the user submits the CCD document to the tester for verification.
  3. Based on the health IT setting(s) to be certified, a user repeats steps 1-3 for each of the ambulatory and/or inpatient care plan instruction documents found in the ETT: Message Validators. The demonstration of the API is required for all of the API instruction documents for a given health IT setting.

Demonstrate API

  1. For each API instruction set downloaded in step 1 of the SUT, the tester verifies that the identified API routine(s) can respond to a request for “all patient data” and return all data in the CCDS in a single document using the CCD document template.
  2. Using ETT: Message Validators – C- R2.1 Validator, the tester uploads the submitted CCD document returned from the identified API routine(s) through the sender upload selection of the “APIAccess_Amb” or “APIAccess_Inp” criteria and file name of the API instruction document, and the tester executes the upload of the submitted file to the ETT: Message Validators.
  3. The tester uses the validation report produced by the ETT: Message Validators in step 2 to verify that it indicates passing without error to confirm that the CCD document returned by the API is in a summary record formatted in accordance with the standard adopted at § 170.205(a)(4) using the CCD document template. 
  4. As required by the ONC-supplied API instructions with the corresponding file names as uploaded in step 2, the tester uses the ONC-supplied API instruction document and the ETT: Message Validators Message Content Report to verify the additional checks for equivalent text for the content of all section level narrative text.

Paragraph (g)(9)(i)(B)

System Under Test Test Lab Verification
  1. The Health IT Module’s identified API functions return data to the developer-identified requesting application for a specific date that the requesting application identifies.
  2. The Health IT Module’s identified API functions, return data to the developer-identified requesting application for a specific date range that the requesting application identifies.
  1. The tester verifies that the API routine(s) can respond to a request for patient data for a specific date, and that the patient data returned is accurate and without omission based upon the health IT developer’s documentation for data return based upon a date request.
  2. The tester verifies that the API routine(s) can respond to a request for patient data for a date range, and that the patient data returned is accurate and without omission based upon the health IT developer’s documentation for data return based upon a date range request.

Paragraph (g)(9)(ii)(A)(1)

System Under Test Test Lab Verification

The health IT developer supplies documentation describing the API, with the intended audience of developers, and includes at a minimum:

  • API syntax;
  • function names;
  • required and optional parameters and their data types;
  • return variables and their types/structures; and
  • exceptions and exception handling methods and their returns.

The tester verifies that the identified documentation for the Health IT Module’s API definition is accurate and without omission, and that it matches the version of the software release.


Paragraph (g)(9)(ii)(A)(2)

System Under Test Test Lab Verification

The health IT developer supplies accompanying documentation describing the Health IT Module’s API implementation requirements, with the intended audience of developers, which must include:

  • The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

The tester verifies that the identified documentation for interfacing with the Health IT Module’s API (including both the software components and the configuration) is accurate and without omission and that it matches the version of the software release. 


Paragraph (g)(9)(ii)(A)(3)

System Under Test Test Lab Verification

The health IT developer supplies the API’s Terms of Use, which needs to include, at a minimum, any associated developer policies and required developer agreements.

The tester verifies that the identified documentation contains the Terms of Use and that it matches the version of the software release.


Paragraph (g)(9)(ii)(B)

System Under Test Test Lab Verification

The documentation used to meet paragraph (g)(9)(ii)(A) of this section must be available via a publicly accessible hyperlink.

The tester verifies that the supplied documentation is publicly accessible by hyperlink.


Version 1.9 Updated on 09-21-2018
Revision History
Version # Description of Change Version Date
1.0

Initial Publication

10-30-2015
1.1

Certification requirement revised to include that C-CDA creation performance (§ 170.315(g)(6)) is required for this criterion.

Clarifications added relating to “third-party API” definition, additional audit record user access details, data exclusions related to patient data accessed within a specific date range, terms of use details related to third party applications, API access, and hyperlink, and details around the meaning of token as a patient identifier.

02-05-2016
1.2

Further adjustments to clarifications included with version 1.1 were made and to also be consistent with clarifications included in the CCGs for (g)(7) and (g)(8) certification criteria.

Terms of use documentation and hyperlink clarifications added.

HIPAA specific bullet removed from general clarifications section to avoid confusion.

03-28-2016
1.3

Added clarification in the “applies to entire criterion section” related to the product update requirements.

11-09-2016
1.4

Added clarification regarding the number of CCD documents that may be returned for a specific date range.

Added clarification on API Registration requirements and removed guidance on API registration mechanism (dynamic registration). Added clarification on the definition of a “trusted connection”. Clarification added to subparagraph (i)(B) on the method used to identify a patient.

07-07-2017
1.5

Added clarification for paragraph (g)(9)(ii)(B) that documentation must be available to the public via a hyperlink without any additional access requirements.

08-25-2017
1.6

Revised clarification for paragraph (g)(9)(ii)(B) that the hyperlink provided for all of the documentation must reflect the most recent version of all the documentation, not just the terms of use.

Provided notification of March 2017 Validator Update of C-CDA 2.1 Corrections adoption and compliance requirements for paragraph (g)(9)(i)(A).

09-29-2017
1.7

Made revisions to a prior clarification in paragraph (g)(9)(ii)(A) regarding the terms of use. Added a new clarification for paragraph (g)(9)(ii)(A) regarding enforcement of the health IT developer’s terms of use, which is out of scope for this criterion. Additionally, noted CMS guidance that providers may not prohibit patients from using the app of the patient’s choice.

02-01-2018
1.8

Provides notification of April 2018 Validator Update of C-CDA 2.1 Corrections adoption and compliance requirements within paragraph (g)(9)(i)(A). Note: Due to an error in calculation ONC is also updating the dates for compliance with the March 2017 Validator Update of C-CDA 2.1 Corrections that were adopted September 29, 2017.

05-02-2018
1.9

Provides notification of August 2018 Validator Update of C-CDA 2.1 Corrections adoption and compliance requirements within paragraph (g)(9)(i)(A).

09-21-2018
Regulation Text
Regulation Text

§170.315 (g)(9) Application access – all data request

The following technical outcome and conditions must be met through the demonstration of an application programming interface.

  1. Functional requirements.
    1. 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 according to the standard specified in §170.205(a)(4) following the CCD document template.
    2. Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.
  2. Documentation—
    1. The API must include accompanying documentation that contains, at a minimum:
      1. API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.
      2. The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).
      3. Terms of use. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements.
    2. The documentation used to meet paragraph (g)(9)(ii)(A) of this section must be available via a publicly accessible hyperlink.
Standard(s) Referenced

Paragraph (g)(9)(i)(A)

§ 170.205(a)(4) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use Release 2.1, August 2015

Please refer to the Data Elements and Vocabularies applicable to the Common Clinical Data Set (CCDS) as outlined in the Common Clinical Data Set Reference Document

Certification Companion Guide: Application access — all data request

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product development. The CCG is not a substitute for the 2015 Edition final regulation. It extracts key portions of the rule’s preamble and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the 2015 Edition final rule or other included regulatory reference. The CCG is for public use and should not be sold or redistributed.
 

 

Certification Requirements

Privacy and Security: This certification criterion was adopted at § 170.315(g)(9). As a result, an ONC-ACB must ensure that a product presented for certification to this criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “VDT” and (e)(2) “secure messaging,” which are explicitly stated.

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively the developer must state that no accessibility-centered design was used.
  • C-CDA creation performance (§ 170.315(g)(6)) does not need to be explicitly tested with this criterion unless it is the only criterion within the scope of the requested certification that includes C-CDA creation capabilities. Note that the application of § 170.315(g)(6) depends on the C-CDA templates explicitly required by the C-CDA-referenced criterion or criteria included within the scope of the certificate sought. Please refer to the C-CDA Creation Performance Certification Companion Guide for more details.
Table for Privacy and Security
Technical Explanations and Clarifications

 

Applies to entire criterion

Clarifications:

  • Security:
    • For the purposes of certification there is no conformance requirement related to the registration of third party applications that use the APIs. If a Health IT module requires registration as a pre-condition for accessing the APIs, then, the process must be clearly specified in the API documentation as required by the criterion. We strongly believe that registration should not be used as a means to block information sharing via APIs.
    • This criterion does not currently include any security requirements beyond the privacy and security approach detailed above, but we encourage organizations to follow security best practices and implement security controls, such as penetration testing, encryption, audits, and monitoring as appropriate. We expect health IT developers to include information on how to securely use their APIs in the public documentation required by the certification criteria and follow industry best practices. [see also 80 FR 62676]
    • We strongly encourage developers to build security into their APIs following best practice guidance, such as the Department of Homeland Security’s Build Security In initiative.1 [see also 80 FR 62677]
    • A “trusted connection” means the link is encrypted/integrity protected according to § 170.210(a)(2) or (c)(2). As such, we do not believe it is necessary to specifically name HTTPS and/or SSL/TLS as this standard already covers encryption and integrity protection for data in motion. [see also 80 FR 62676]
    • APIs could be used when consent or authorization by an individual is required. In circumstances where there is a requirement to document a patient’s request or particular preferences, APIs can enable compliance with documentation requirements. The HIPAA Privacy Rule2 permits the use of electronic documents to qualify as writings for the purpose of proving signature, e.g., electronic signatures. [see also 80 FR 62677]
  • The audit record should be able to distinguish the specific user who accessed the data using a third-party application through the certified API in order to meet the requirements of § 170.315(d)(2) or (d)(10).
  • A health IT developer must demonstrate that its API functionality properly performs consistent with this certification criterion’s requirements. How this is done is up to the health IT developer. Doing so could include, but is not limited to, the health IT developer using existing tools or creating its own app or “client” to interact with the API as well as using a third-party application.
  • By requiring that documentation and terms of use be open and transparent to the public by requiring a hyperlink to such documentation to be published with the product on the ONC Certified Health IT Product List, we hope to encourage an open ecosystem of diverse and innovative applications that can successfully and easily interact with different Health IT Modules’ APIs. [see also 80 FR 62679]
  • Health IT developers are able to update/upgrade/improve functionality that’s within the scope of certification, provided that certain rules and conditions are followed. The “API criteria” § 170.315(g)(7), § 170.315(g)(8), and § 170.315(g)(9) are treated no different under this regulatory structure. If a developer seeks to update their API functionality post-certification a developer will need to consider the following:
    • If their ONC-ACB requires notification or updated documentation associated with the functionality they changed. This procedure is at the discretion of the ONC-ACB and may result in an additional CHPL listing.
    • Pursuant to the certification criteria, there is a documentation portion in each. Which would include (publicly available) technical specs, configuration requirements, and terms of use. Insofar as a developer updates their API post-certification, they are expected to keep all of this documentation up-to-date. Similarly, ONC-ACBs are expected to oversee/enforce/surveil that this action is taken and could find a non-conformity if those updates are not made.
    • If any of their changes would require updates to the developer’s § 170.523(k)(1) disclosures (the broader product transparency disclosures)


 


1 https://buildsecurityin.us-cert.gov/
2 45 CFR Part 160 and Part 164, Subparts A and E


Paragraph (g)(9)(i)(A)

Technical outcome – The API must be able to respond to requests for patient data (using an ID or other token) for all of the data categories specified in the Common Clinical Data Set at one time in a summary record formatted according to the Consolidated CDA Release 2.1 Continuity of Care Document (CCD) template.

Clarifications:

  • Please refer to the 2015 Edition Common Clinical Data Set for the data standards that are required.
  • The technology specifications should be designed and implemented in such a way as to return meaningful responses to queries, particularly with regard to exceptions and exception handling, and should make it easy for applications to discover what data exists for the patient. [see also 80 FR 62678]
  • The term “token” that is used here is not to be interpreted as the token in the OAuth2 workflow, but simply as something that would uniquely identify a patient.
  • In order to mitigate potential interoperability errors and inconsistent implementation of the HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, Draft Standard for Trial Use, Release 2.1, ONC assesses, approves, and incorporates corrections as part of required testing and certification to this criterion. [see FAQ #51] Certified health IT adoption and compliance with the following corrections are necessary because they implement updates to vocabularies, update rules for cardinality and conformance statements, and promote proper exchange of C-CDA documents. Consistent with FAQ 51, there is a 90-day delay from the time the CCG has been updated with the ONC-approved corrections to when compliance with the corrections will be required to pass testing (i.e., C-CDA 2.1 Validator). Similarly consistent with FAQ 51, there will be an 18-month delay before a finding of a correction’s absence in certified health IT during surveillance would constitute a non-conformity under the Program.

Paragraph (g)(9)(i)(B)

Technical outcome – The API must be able to respond to requests for patient data associated with a specific date as well as with a specific date range.

Clarifications:

  • Health IT returning an entire patient record that does not reflect the specific date or date range requested is not permissible when a specific date or date range is requested. [see also 80 FR 62678]
  • The developer can determine the method and the amount of data by which the health IT uniquely identifies a patient. [see also 80 FR 62678]
  • The API must be able to send, at minimum all required data for a specified date range(s). We acknowledge that there will be organizational policies and/or safety best practices that will dictate additional data to be sent and when data is considered complete and/or ready for being sent. This should be appropriately described in the API documentation.
  • The approach used to provide the CCD document(s) is set by the API. An approach based on providing one or more CCD documents matching to the patient’s selected date or date range is a valid approach.

Paragraph (g)(9)(ii)(A)(1)

Technical outcome – The API must include accompanying documentation which contains API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.

Clarifications:

  • No additional clarifications available.

Paragraph (g)(9)(ii)(A)(2)

Technical outcome – The API must include accompanying documentation, which contains software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

Clarifications:

  • No additional clarifications available.

Paragraph (g)(9)(ii)(A)(3)

Technical outcome – The API must include the terms of use for the API including, at a minimum any associated developer policies and required developer agreements.

Clarifications:

  • Health IT developers must be clear and transparent about the general terms of agreements or contracts that will typically apply to all prospective third party applications.
  • Health IT developers that typically execute unique agreements or contracts with interested third party applications using their API must disclose this practice as part of their terms of use.
  • For the purposes of certification, a health IT developer is accountable for documenting and making public the provisions of its API’s terms of use. If, post-certification, a health IT developer permits its customers to deploy and integrate its API in ways where the customer would be able to layer on its own specific terms of use unique to that organization, the health IT developer would need to disclose this business practice in its terms of use. A health IT developer is NOT expected to change or factor instances into its terms of use where its customers establish additional, organizational-specific terms for the API’s use.
  • Pursuant to the certification criterion’s documentation requirement, health IT developers are required to make their API documentation publicly available, including the terms of use (and its associated policies and required developer agreements). Developers’ enforcement of their terms of use is beyond the scope of conformance to this certification criterion. This criterion focuses on the technical API capabilities with which a Health IT Module must be in compliance and documentation requirements as specified. For example, this certification criterion does not require health IT developers to evaluate app developers or prohibit such activity (though such activities may implicate other requirements of the Program). We also note that CMS, specifically in the patient access context, states that “[p]roviders may not prohibit patients from using any application, including third-party applications, which meet the technical specifications of the API, including the security requirements of the API.”3

 


https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/MedicaidEPStage3_Obj5.pdf


Paragraph (g)(9)(ii)(B)

Technical outcome – The documentation used to meet the provisions in (g)(9)(ii)(A)(1)-(3) must be available through a publicly accessible hyperlink.

Clarifications:

  • The hyperlink provided for all of the documentation referenced by provision (g)(9)(ii)(A) must reflect the most current version of the Health IT developer’s documentation.
  • All of the documentation referenced by provision (g)(9)(ii)(A) must be accessible to the public via a hyperlink without additional access requirements, including, without limitation, any form of registration, account creation, “click-through” agreements, or requirement to provide contact details or other information prior to accessing the documentation.

Regulation Text
Regulation Text

§170.315 (g)(9) Application access – all data request

The following technical outcome and conditions must be met through the demonstration of an application programming interface.

  1. Functional requirements.
    1. 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 according to the standard specified in §170.205(a)(4) following the CCD document template.
    2. Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.
  2. Documentation—
    1. The API must include accompanying documentation that contains, at a minimum:
      1. API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.
      2. The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).
      3. Terms of use. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements.
    2. The documentation used to meet paragraph (g)(9)(ii)(A) of this section must be available via a publicly accessible hyperlink.
Testing Tool

Edge Testing Tool (ETT): Message Validators

 

Test Tool Documentation

Test Tool Supplemental Guide

 

Criterion Subparagraph Test Data
(g)(9)(i)

Inpatient setting: - 170.315_g9_api_access_inp_sample*.docx (All Samples)

Ambulatory setting - 170.315_g9_api_access _amb_sample*.docx (All Samples)

Content last reviewed on September 21, 2018
Was this page helpful?