FHIR (Fast Healthcare Interoperability Resources) Specification is a standard for exchanging healthcare information electronically.
Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. To support automated clinical decision support and other machine-based processing, the data must also be structured and standardized.
HL7 has been addressing these challenges by producing healthcare data exchange and information modeling standards for over 20 years. FHIR is a new specification based on emerging industry approaches, and informed by years of lessons around requirements, successes and challenges gained through defining and implementing HL7 v2, HL7 v3 and the RIM, and CDA. FHIR can be used as a stand-alone data exchange standard, and it can also be used in partnership with existing widely used standards.
FHIR aims to simplify implementation without sacrificing information integrity. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications. FHIR has built-in mechanisms for traceability to the HL7 RIM as well as other important content models. This ensures alignment to HL7’s previously defined patterns and best practices without requiring the implementer to have intimate knowledge of the RIM or any HL7 v3 derivations.
Visit the HL7 FHIR Website for more information.
FHIR Profiles are simply a handful of resources: StructureDefinition, ValueSet, and CodeSystem (for R3) are the main ones. All of these resources are supported by Smile CDR so you can upload them as you would upload any other resource. Naturally, if you have security rules in place then you might need to create an administrative user and grant them appropriate permissions in order for them to be able to upload these resources.
Once your profile resources are uploaded, you can validate any other resource against the profile. For example, if you have uploaded a StructureDefinition for a constraint on Observation, you can post candidate Observations to [base]/Observation/$validate and the server will return a validation outcome against those resources.
This validation automatically includes both structural validation and terminology validation. If you have referenced terminology (either internal FHIR terminology or external terminology), those bindings will be automatically checked as well. Note that if you want to validate against an external code system – such as SNOMED CT or LOINC – then this needs to be pre-loaded into Smile CDR’s database.
Smile CDR achieves scalability in two ways:
We are in the process of developing shareable benchmarking data, which will be made available upon completion. We would also welcome the opportunity to explore any specific requirements you might have in order to develop benchmarks that are based on actual projected usage patterns.
We believe very strongly in the SMART on FHIR model for OAuth2/OpenID Connect based authorization of health apps against a health data infostructure/infrastructure. Smile CDR includes the ability to act as a SMART on FHIR compatible OAuth2/OpenID Connect server, and has OAuth2 scope-granting screens that have been customized to display accessible definitions of the scopes being authorized. For example, the SMART
patient/*.read scope can be displayed as “Access any data for patient”, reflecting a definition that users will understand.
Smile CDR includes a complete access-control mechanism that is built around these scopes. It is able to recognize that a user has a specific set of SMART on FHIR scopes for which they have been authorized, and can block FHIR requests and responses exceeding the limits of those scopes.
Smile CDR also includes support for consuming SMART on FHIR tokens that have been supplied by an external provider. Because the OAuth2 specifications do not specify a standard mechanism for token verification, it is not possible to certify that the product can interoperate out-of-the-box with an arbitrary provider; however, Smile CDR is designed to be capable of integration with any conformant OAuth2 provider.
Smile CDR includes support for all SMART on FHIR commonly used scopes that are relevant to a CDR-type deployment (e.g. excluding scopes which only make sense in the context of an EHR/EMR-based app deployment).
patient/*.read – permission to read any resource for the current patient
user/*.* – permission to read and write all resources that the current user can access
openid profile – permission to retrieve information about the current logged-in user
online_access – request a
refresh_token that can be used to obtain a new access token to replace an expired one, and that will be usable for as long as the end-user remains online
offline_access – request a
refresh_token that can be used to obtain a new access token to replace an expired one, even after the end-user no long is online after the access token expires
It is important to note that in the context of a standalone CDR, the concept of current patient has a less consistent definition than it does in the context of an EHR/EMR. Some discussion regarding specific customer requirements will ensure that the system can be configured to provide complete privacy.