21st Century Cures Act, §170.315 g(10) Standardized API for patient and population services - 🇺🇸
Overview
Note
Firely Server v5 has been officially certified against §170.315 g(10) 2015 Cures Edition Health IT. For more details, see our CHPL listing. Mandatory disclosures can be found here.
Firely Server is ready to comply with important criteria for the 21st Century Cures Act without any additional configuration. See the Standard referenced section provided by the ONC for a full list of standards working in combination to provide an API conforming to §170.315 g(10) 2015 Cures Edition Health IT.
See How to Test Firely Server on Inferno for more information on how to pass the official 21st Century Cures Act test.
§170.315 g(10) APIs
The g(10) criteria describes the interaction of multiple ImplementationGuides, namely:
Together these ImplementationGuides form a coherent set of APIs allowing to build different APIs hosted on the provider side to enable a secure exchange of information:
Patient API
SMART App Launch allows Patients to launch an app as a standalone application to request data from a FHIR server in their name. Using US Core conformant resources, different data categories can be exposed as an EHR in this case. US Core defines diverse SearchParameters that can be used to find data in the EHR. To implement a Patient API it is necessary to:
Enable SMART on FHIR and point Firely Server to an authorization server managing the accounts of the patients - See Introduction Access control
Expose the Patient records with all their USCDI data elements
Configure the API clients to be allowed to be granted access (ready-only) to resources on behalf of the patient - See Configuration of API clients in Firely Auth
Practitioner API
SMART App Launch allows Practitioners to start a new workflow outside of the EHR by using additional apps that interact with the FHIR server. Practitioners can launch the app within the EHR and interact with data for a single Patient or a group of Patients, if authorization is granted. To implement a Practitioner API it is necessary to:
Enable SMART on FHIR and point Firely Server to an authorization server managing the accounts of the practitioners - See Introduction Access control
Expose the Patient records with all their USCDI data elements
Configure the API clients to be allowed to be granted access (ready-only) to resources on behalf of the practitioner - See Configuration of API clients in Firely Auth
In case Firely Server acts as a backend of an EHR, forward the launch context information from the EHR to the authorization server to open the API client in the correct context - See LaunchContext endpoint
Multi-Patient API
For system-to-system interactions, a Multi-Patient API allows clients to export Patient records in bulk. To implement a Multi-Patient API it is necessary to:
Enable SMART on FHIR and point Firely Server to an authorization server configured with pre-authorized backend API clients - See Introduction Access control
Expose the Patient records with all their USCDI data elements
Configure the API clients to be allowed to be granted access (ready-only) to resources necessary for their specific use case - See Configuration of API clients in Firely Auth
Supported versions
Firely provides official support for the following versions of the ImplementationGuides described above to implement these APIs:
US Core Version
Status
References
US Core 3.1.1
✅
US Core 4.0.0
✅
US Core 5.0.1
✅
All versions of SMART on FHIR and Bulk Data Access approved for the SVAP Process in 2022 are supported by Firely Server:
ImplementationGuide
Status
References
Bulk Data Access 1.0.0
✅
Bulk Data Access 2.0.0
✅
SMART on FHIR 1.0.0
✅
SMART on FHIR 2.0.0
✅
Conformance & Configuration
Firely Server provides full profile and interaction support as defined in “Conforming to US Core”:
Firely Server can be populated with resources conforming to US Core
All elements defined as must-support by the implementation guide are supported
All references between FHIR resources defined as must-support by the implementation guide are supported
All search and CRUD interactions defined by US Core are supported, including optional search parameters
All StructureDefinitions for profiles and extensions (v3.1.1) are loaded by default in the standard SQLite administration database of Firely Server. No additional configuration is needed to validate against these conformance resources.
A mapping between USCDI and the US Core profiles can be found in the US Core ImplementationGuide.
See Tutorial for details on how to configure a client to interact with Firely Server and Firely Auth.