For many Payers HL7 FHIR is a new world. The CMS Interoperability and Patient Access Rule is driving Payers to implement HL7 FHIR Implementation Guides that cover:
- Claims
- Clinical
- Drug Formulary
- Provider/Pharmacy Directory
Many payers have asked about strategies to test FHIR APIs. This document lays out an approach to a manageable testing strategy.
Check with your Vendor
The HL7 organization and the accelerator projects that are responsible for publishing the Implementation Guides that meet Payer’s needs in complying with the CMS Interoperability Rule incorporate automated testing into the publishing of the FHIR Specification and the Implementation Guides that build on that specification.
Testing resources provided by organizations such as Aegis.net with their Touchstone platform utilize the testing scripts provided to ensure conformance with the Implementation Guides.
Compartmentalized Testing
There should be four discrete areas of focus for testing efforts:
- Data Transformation Testing
- User Authentication and Authorization Testing
- Third Party Application Management Testing
- Standardized Testing (Touchstone or equivalent)
Data Transformation Testing
Payers are typically exporting data from data warehouses or from enterprise systems, typically using flat files. The focus in data transformation should be on:
- Did all data supplied get landed into FHIR resources?
- Did the data get translated and represented using the correct code systems?
- Did the json or xml records loaded into the FHIR server pass the FHIR validation checks to ensure they confirm with the correct FHIR Profiles?
User Authentication and Authorization Testing
The Patient Access APIs , excluding the Provider Directory API, require a member to authenticate and then authorize the sharing of their data with a third party app. For this testing the focus should be on proving:
- The Happy Path works, where a member successfully logs in, authorizes sharing and an app is then able to retrieve the approved data from the API.
- The alternate path where a member authenticates but then chooses to NOT authorize sharing. The app should not be able to retrieve data for the member.
- The unhappy path where a member fails to login and therefore can’t authorize sharing. In this case an app should not be able to access data.
- Where members don’t have a digital account the payer could also test the process where a member accesses the API, creates a digital account and then proceeds through the authentication and authorization paths.
Third Party Application Management Testing
For a Third-party app to use the FHIR Patient Access APIs it needs to acquire an OAuth2.0/SMART-on-FHIR App Launch Framework credential. The focus on testing here should be on:
- Confirming that an app without proper credentials is unable to retrieve data from the secured areas of the API.
- Conforming that the flow to register an app works thereby enabling an app to retrieve data when authorized by a member.
- Confirming that the credentials for an app can be deactivated and the app is no longer able to retrieve new data from the secured parts of the API.
Standardized Testing (Touchstone or equivalent)
Aegis.net’s Touchstone platform provides testing of FHIR APIs. https://www.aegis.net/touchstone.html
The ONC also provides a testing harness to check for conformance with the SMART-on-FHIR App Launch Framework. This tests that the authentication and authorization for third party apps is working correctly. https://inferno.healthit.gov/inferno/
[]: