21th 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 21th 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 coherient 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 managging the accounts of the patients - See Access control and SMART on FHIR
Expose the Patient reorcd with all its 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 managging the accounts of the practitioners - See Access control and SMART on FHIR
Expose the Patient reorcds 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 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 Access control and SMART on FHIR
Expose the Patient reorcds with all their USCDI data elements
Configure the API clients to be allowed to be granted access (ready-only) to resources to 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 needed in order to validate against these conformance resources.
A mapping between USCDI and the US Core profiles can be found in the US Core ImplementationGuide.
See Firely Auth Introduction for details on how to configure a client to interact with Firely Server and Firely Auth.