1. Proctor Sheet: Requirements - Attestation
1.1. Guides & Resources
1.1.1. FAQs on Drummond Customer Portal
1.1.2. ONC Certification Program Test Procedure
1.1.3. ONC Certification Program CCG
1.1.4. USCDI v3 Test Data Download
1.1.5. C-CDA R.2.1 Message Validator for USCDI v3
1.1.6. ETT Testing Tool Support Group
1.1.7. ETT Testing Tool Supplemental Guide
1.1.8. Third-party Tools
1.1.8.1. Postman - API Test Client
1.1.8.1.1. Screen1: Response Example
1.1.8.2. SSL Server Test: Security Layer Analyzer
1.1.8.2.1. Screen1: Overall
1.1.8.2.2. Screen2" TLS
1.2. g.9.0: Test Readiness Confirmation and Setup
1.2.1. 1. Preload test data for Ambulatory and/or Inpatient settings.
1.2.2. 2. Prior to the start of testing, Proctor has Developer verbally confirm they have executed all the applicable test cases against their 170.315(g)(9) implementation.
1.3. g.9.1: Respond to Requests for Patient Data for All Data Categories
1.3.1. 1 Using the developer-supplied API test client, Proctor will verify the following minimum requirements during the test event:
1.3.1.1. • The API call being executed (including any messages being sent from the client to the API server) and the results returned from the API server to the API client in raw form using XML, JSON, or other computable format.
1.3.1.1.1. Postman - API Test Client
1.3.1.2. • Authentication to the API server uses a valid login or other security credential.
1.3.1.3. • Demonstrates the ability to use a validated security token for the API session for subsequent API calls until the session expires or time out.
1.3.1.4. • Demonstrate the communication security layer being used between the API Client and the API Server.
1.3.1.4.1. SSL Server Test: Security Layer Analyzer
1.3.2. 2. Using all of the sample patients from the Test Data for the applicable setting(s), Developer demonstrates that the API responds to request for the patient data for the unique patient identified by the ID or token and returns a summary record (CCD).
1.3.2.1. Proctor Performs Visual Validation
1.3.2.1.1. Inspects that all required USCDI classes/elements are present
1.3.2.1.2. Inspects equivalent text for the content of all section level narrative text
1.3.2.1.3. Inspects use of the HL7 templates for Provenance, Clinical Notes, Care Team Member, and Unique Device Identifier (UDI)
1.3.2.2. Proctor (or Developer) Validates each CCD Received via the Test Client
1.3.2.2.1. Validate with Message Validator
1.3.3. 3. Developer demonstrates that the API responds to a request for the patient data for a specified period: - a date request and - a date range request.
1.3.3.1. Proctor verifies that the health IT module can return the patient data for each of the specified periods, and that based upon the health IT developer’s documentation the data is accurate and without omission.
1.4. g.9.2: API Documentation
1.4.1. 1 Developer provides documentation describing the API, with the intended audience of developers, and includes at a minimum:
1.4.2. 2 Developer supplies the API’s Terms of Use, which needs to include, at a minimum, any associated developer policies and required developer agreements.
1.4.3. 3 Developer verifies API documentation supplied is available via a publicly accessible hyperlink.
1.4.4. 4 Proctor reviews submitted documentation and verifies:
1.4.5. CHPL Examples
1.4.5.1. Filter By Criteria
1.4.5.2. Select a Product
1.4.5.3. Select G.9 API Document Link
1.4.5.4. G7 Public Doc
1.5. ONC Criteria and Standards
2. ONC Certified Third Party Products
2.1. Dynamic Health IT
2.1.1. ConnectEHR+BulkFHIR
2.1.1.1. g.7 Application access — patient selection
2.1.1.2. g.9 Application access — all data request
2.1.1.3. g.10 Standardized API for patient and population services (FHIR)
2.1.2. CQM Solutions
2.1.2.1. c.1 Capture
2.1.2.2. c.2 Calculate
2.1.2.3. c3. Report
2.1.3. Patient Portal
2.1.3.1. e.1 View, download, and transmit to 3rd party
2.2. Carefluence
2.2.1. Carefluence Open API
2.2.1.1. g.7 Application access — patient selection
2.2.1.2. g.9 Application access — all data request
2.2.1.3. g.10 Standardized API for patient and population services (FHIR)
2.3. CitiusTech
2.3.1. PERFORM+Connect
2.3.1.1. g.7 Application access — patient selection
2.3.1.2. g.10 Standardized API for patient and population services (FHIR)
3. Guidance
3.1. No API standard required, but HL7 FHIR highly encouraged
3.2. Security
3.2.1. Pre-registration of Applications using API allowed, but cautioned
3.2.2. Follow Best Practices
3.2.3. Implement a "Trusted Connection"
3.2.3.1. § 170.210(a)(2): Standards Hub Reference
3.2.3.2. § 170.210(c)(2): Standards Hub Reference
3.2.4. HIPPA Privacy Rule Considerations
3.2.4.1. Final Rule Response
3.3. Public Link to API Documentation
3.4. Developer Demonstrate API Functionality
3.5. Upgrading API After Certification: Condtions:
3.5.1. Notify ONC-ACB of Changes
3.5.2. Keep API Documentaton Up-to-date AfterCertification
3.5.3. Update Transparency/Disclosure Documentation
4. g.9 relationship to g.2
4.1. Indirect Relationship: Existence of patient information and CCD available to API
4.1.1. g.2 Measure Calculation
4.1.1.1. Required Test 2a - Patient Electronic Access (certified to (e)(1) and, (g)(9) or (g)(10))
4.1.1.1.1. Denominator = The number of unique patients discharged from an eligible hospital or CAH inpatient or emergency department in Reporting Period
4.1.1.1.2. Numerator = Number of Patient Health Information Available to Access via API within 36 hours in Denominator Sent in Reporting Period
4.1.1.2. OR....
4.1.1.3. Required Test 2c - Patient Electronic Access (certified to (g)(9) or (g)(10))
4.1.1.3.1. Denominator = The number of unique patients discharged from an eligible hospital or CAH inpatient or emergency department in Reporting Perioderiod
4.1.1.3.2. Numerator = Number of Patient Health Information Available to Access via API within 36 hours in Denominator Sent in Reporting Period