FAQs
HL7 FHIR
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 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’s database.
System Architecture
Smile achieves scalability in two ways:
- The system has been built using a largely stateless design. This means that – provided the underlying database platform has been configured correctly – it should be possible to add an unlimited number of horizontal cluster nodes of Smile, and to place a stateless load balancer in front of the solution.
- Furthermore, our product roadmap includes plans to implement support for various additional storage modules. This includes plans for time-series storage modules such as InfluxDB as well as support for big data modules such as Apache Hadoop. These modules will be useful for applications where very large datasets are generated over time (such as time-series data, continuously streaming sensor data, etc.).
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.
Security
Smile includes support for authentication based on both internal and external identity providers. It ships with a self-contained database module that may be used to store user accounts, including passwords that are stored using a configurable salted hash algorithm for maximum security. Smile also includes the ability to integrate with external user directories, such as an external LDAP database or external Microsoft Active Directory installation. When using this mechanism, all authentication decisions are delegated to the external system, and credentials are not kept in Smile’s internal database.
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 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 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 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 is designed to be capable of integration with any conformant OAuth2 provider.
Smile 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).
This includes:
- 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 read and write all resources that the current user can access
- 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.
Potential Uses
Smile is ideally suited to support messaging-based input from patients, remote monitoring tooling, and health care providers. We do not take a prescriptive approach to FHIR resources; instead we support all elements of the specification. This flexibility allows application designers to select the most appropriate messaging for their needs. The extensive search and query support in Smile makes retrieving and using the information simple. Smile is designed to scale rapidly, and to support very large data sets, which is useful when collecting large amounts of information generated by remote monitoring systems from the general population. Smile can be a direct recipient of data from automated systems and a storage node for user applications designed to meet constituent needs.