Solutions
Trisotech
Trisotech the Pioneer

Fast Healthcare Interoperability Resources (FHIR)

Title Shadow

What is FHIR®?

The HL7® FHIR® standard is a free and open standards framework created by Health Level Seven® International (HL7®) and intended to facilitate the interoperability of computerized healthcare systems. FHIR® officially stands for Fast Health Interoperable Resources, although today, almost everyone including HL7® uses the approved alternate name Fast Healthcare Interoperability Resources. The FHIR® standard provides a standard data model for describing healthcare health and administrative data and a RESTful API (Application Programming Interface) using JSON, XML or Turtle to manipulate and search that data. FHIR also provides open-source tools, a collection of global FHIR servers for testing etc., and a robust community of implementors.

HL7 Fast Healthcare Interoperability Resources (FHIR) Logo

Note: HL7®, and FHIR® are the registered trademarks of Health Level Seven International and their use of these trademarks does not constitute an endorsement by HL7.

Learn More

What is HL7®?

Health Level Seven® International (HL7®), found at hl7.org, is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information to support clinical practice and the management, delivery and evaluation of health services. The HL7 organization is supported by more than 1,600 members from over 50 countries representing healthcare providers, government stakeholders, payers, pharmaceutical companies, vendors/suppliers, and consulting firms.

Who Uses FHIR?

FHIR is a recent standard, but its usage is exploding. The standard’s evolution to include imaging resources, financial resources and clinical decision support resources has allowed for more comprehensive data analytics, precision medicine, and automated clinical pathways. Also driving the standard’s adoption is the growing expectation among patients and the new generation of physicians that healthcare data sharing should be as convenient and secure as financial services data sharing. Finally, demand for interoperability continues to grow as widespread adoption of EHR systems, changes in business models such as accountable care, and government regulations make data standardization and data sharing a standard of care.

While nearly every healthcare service organization recognizes the need for standardization of data representation and manipulation, and many have been working towards this for years, adoption of FHIR has been accelerated by government regulatory requirements and FHIR adoption by healthcare software vendors including many of the biggest industry names such as Epic, Cerner, Allscripts, athenahealth, and others. At the same time, consumer software vendors like Apple, Google, and Microsoft have embraced FHIR almost assuredly making this the standard that everyone in healthcare will adopt.

The biggest single driver for adoption of the FHIR standards comes from U.S. federal health leaders at CMS (the Centers for Medicare & Medicaid Services) and ONC (the Office of the National Coordinator for Health IT.) CMS and the ONC have used the 21st Century Cures Act (45 CFR 170.215) to implement new final rules geared towards healthcare interoperability improvement. The 21st Century Cures Act was signed into law in 2016 and then sent to the ONC and CMS for review. Upon review, the ONC and CMS produced two primary new rules, the Information Blocking final rule and Interoperability and Patient Access final rule. CMS is now also finalizing the Interoperability and Prior Authorization Final Rule via CMS Interoperability and Prior Authorization proposed rule.

At this time (Sep. 2021) the Interoperability and Prior Authorization final rule (CMS-9123-F) was withdrawn for review and approval by the Director of the Office of Management and Budget (OMB).

Learn More

These two agencies have created final rules including the FHIR standard data Resources and APIs using USCDI – the US Core Data Set for Interoperability. The US Core Implementation is based on FHIR Version R4. In its rule, CMS requires Medicare Advantage plans, state Medicare and CHIP managed care entities, Medicaid managed care plans and qualified health plans in the federal exchanges to implement, test, and monitor openly published FHIR-based APIs to make patient claims and other health information available to patients through third-party applications and developers. ONC requires that FHIR must be the standard by which health IT developers certify their APIs. An additional rule in the interoperability space will go into effect in 2023 and require impacted payers to provide information about a patient’s prior authorizations as part of a patient access API, giving patients a better understanding of how the prior authorization process impacts their care.

Because EHR vendor’s proprietary systems have made it exceptionally difficult to exchange patient and other healthcare data, physicians and other healthcare providers, hospitals, health IT vendors, and health information exchanges are required under the Information Blocking rules to respond to any legitimate request to exchange or provide access to electronic health information (EHI) stored in their electronic health record (EHR) system. Such a request could come from a patient, another provider, a health plan seeking information for clinical purposes, or a public health agency. This effectively eliminates what is generally referred to as “information blocking” a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.

Finally, the API Condition and Maintenance of Certification (45 CFR 170.404(b)(3)) requires software developers with health IT previously certified for technical API conformance, to provide all customers with upgraded API technology certified to this new certification criterion by December 31, 2022.

Other Major Governmental Projects Around the Globe

Almost every country has some set of interoperability initiatives associated with the FHIR standard. Some examples include:

  • NHS Digital (part of the National Health Service), the publicly funded healthcare system in England, – designs, develops and operates the national IT and data services that support clinicians at work, help patients get the best care, and use data to improve health and care. With the adoption of FHIR release 4 they intend to create a unified approach to interoperability across England, Scotland, Wales and Northern Ireland. This will enable consistent information flows across borders to improve health and care outcomes for all citizens.
  • Brazil – The IT Department of the Sistema Único de Saúde (SUS) part of the Brazilian Ministry of Health, started one of the world’s largest platforms for national health interoperability, called the National Health Data Network, which uses HL7 FHIR R4 as a standard in all its information exchanges.
  • Canada has significantly engaged with FHIR standards at both the national and provincial levels. National support includes the Standards Council of Canada, Canadian Institute for Health Information (CIHI), Canada Health Infoway InfoCentral (an open, group-based community platform available for clinicians, e-health representatives, vendors, developers, and others interested in working collaboratively to accelerate clinical interoperability in Canada), and the Industry Trade Association of Canada (ITAC) Health Interoperability Standards Committee. Most provincial organizations also have some FHIR-based projects through their Health Information Standards Committees (HISC) with Ontario (eHealth Ontario), British Columbia (B.C. Fast Healthcare Interoperability Resources [FHIR] Standards) leading the way for FHIR.

What is FHIR® Used For?

Because FHIR® provides a standard way of describing healthcare data and relationships as well as methods (standard APIs) for manipulating and searching that data, FHIR is suitable for use in many environments such as EHR-based data sharing, cloud communications, mobile phone apps, server communications in large institutional healthcare providers, and much more. FHIR defines modular components called “Resources” and those building blocks can be used to create clinical and administrative healthcare applications and systems in much the same way as other modern internet applications do at a considerably lower cost than other existing alternatives. The FHIR standard enables developers to build “browser-based” applications that allow access to data no matter what EHR system forms the user’s base infrastructure.

By using FHIR organizations can, when needed, get away from document-centric approaches like encounter notes, patient charts and faxes and expose discrete data elements as a service request. For example, a provider may not¬ want to retrieve an entire document about the patient, he or she may just want the patient’s latest complete blood count (CBC) information. FHIR is also providing new interoperability opportunities, such as direct information exchange with patients so they can more easily access their own medical record via a common web portal or mobile app, as well as with organizations in other parts of the healthcare value chain such as health insurers, life insurers and life sciences companies.

While the FHIR standard is great, it is not without some issues. The most obvious is that not every use case in health care can possibly be accounted for in a standard. Both the sheer breadth of healthcare solutions and the constantly changing clinical and pharmaceutical landscapes make the task too great. However, FHIR does have a “solution” for that. One of the original premises of creating the standard recognized the problem and states that the standard is intended to handle 80% of the use cases in healthcare. That other 20% is up to organizations with additional needs to provide themselves. In order to facilitate these additions, the FHIR standard provides a very easy-to-use “extension” capability.

Another issue is one common to both emerging and older in-place standards – versioning. More about this in the section FHIR Versions and What They Mean below ↓↓

Finally, the FHIR standard is huge and comprehensive. That makes the use of it by various countries and organizations difficult to manage and support. Many organizations need only a subset of the full standard and some organizations may store the same information in different ways and still be compliant. This has led to “Implementations” of the standard for specific interoperability purposes. The Implementation Guide Registry lists nearly 150 of these Implementation Guides ranging from the US Core Data Set for Interoperability (USCDI). Other guides include the International Patient Summary, the Australian Base, the US Drug Formulary, Genomics Reporting, and many more. Because Extensions and API access can be part of the implementation guide, some Implementations even specify things like “read only” access by limiting the acceptable “Interactions”.
See The FHIR Standard below ↓↓

Fast Healthcare Interoperability Resources (FHIR)

The FHIR® Standard

Because worldwide healthcare is very diverse, the full FHIR standard is large and comprehensive. The intended scope of FHIR is broad, covering human and veterinary clinical care, public health, clinical trials, administration, and financial areas. It is designed to enable information exchange that supports providing healthcare for global use and in a wide variety of architectures and environments. The FHIR standard is implemented on top of the HTTPS (HTTP Secure) protocol and builds on and adapts modern, widely used RESTful practices to provide interoperability for integrated healthcare services across a wide range of teams and organizations. The standard is also licensed under Creative Commons “No Rights Reserved” license which means it is free to use.

While described as five components (see What Is FHIR? above ↑↑), the FHIR standard really contains two primary components, Resources and APIs. From an operational perspective, HL7’s internal standards development and governance processes determine what a Resource is, and which Resources exist. In addition, the FHIR specification also provides a mechanism for contextualizing resources for specific needs within specific bounds called Profiles. The FHIR framework also contains a verifiable and testable syntax, a set of rules and constraints, methods and interface signatures for “FHIR-aware” APIs, and specifications for the implementation of a server capable of requesting and delivering FHIR business objects.

Resources

Resources are instance-level representations of healthcare entities – a collection of information models that define the data elements, constraints, and relationships for “business objects” that are relevant to healthcare such as Patient, Procedure, Encounter, Observation, Order, etc. There are currently 145 defined Resources and over 50 more “proposed/expected” to be built listed on the FHIR website.

All Resources have these five features in common:

  • A URL that identifies the Resource (example https://example.com/path/Patient/98635402)
  • Common metadata (includes Logical ID [such as Patient ID] explicitly represented in the URL, version ID, and last modified date.)
  • A human-readable XHTML summary
  • A set of defined data elements – a different set for each type of Resource
  • An extensibility framework to support variation in healthcare

Each Resource type defined in FHIR has a manager (or “entity set”) that lives at the address [FHIR Server]/[type]where the [type] is the name of the Resource type. For instance, the Resource manager for the type Patient will live at: https://server/path/Patient. Each Resource instance also carries a human-readable text representation using html as an alternative contingency display option for clinical safety. This is often used for complex clinical information where existing systems currently use simple textual/document-based approaches.

Extending and restricting Resources (collectively known as ‘profiling a Resource’) is done with a “StructureDefinition” Resource, which is a statement of rules about where extensions are used and/or how the data elements in a Resource are used.

For those of you less familiar with information models and data structures it might help to visualize each Resource as one of 145 single spreadsheets (Patient, Observation, Encounter, etc. tabs at bottom) in a spreadsheet file (perhaps Resources.xslx) where the data fields like Name, Gender, Birthdate, Patient Identifier, etc. are columns for the Patient spreadsheet. Each Resource has different data and relationships so the columns for each Resource would be different. Finally, think of each instance (Patient Bill Bloggs; ID 98635402) as the rows. In reality, the data models are far more sophisticated than a spreadsheet and commonly include relational links to other Resources.

APIs – How FHIR Data Exchange is Implemented and Managed

By definition, an API (Application Program Interface) is a collection of well-defined interfaces for interoperating between two applications. Although not required (implementers can also use GraphQL), the FHIR specification targets RESTful interfaces for API implementation. For manipulation of Resources, FHIR provides a REST API with a rich but simple set of Instance, Type, and System interactions that include:

  • Create – Create a new Resource with a server assigned id = POST https://example.com/path/{resourceType}
  • Read – Read the current state of the Resource = GET https://example.com/path/{resourceType}/{id}
  • Update – Update an existing Resource by its id (or create it if it is new) = PUT https://example.com/path/{resourceType}/{id}
  • Delete – Delete a Resource = DELETE https://example.com/path/{resourceType}/{id}
  • Search – Search the Resource type or all Resources based on some filter criteria = GET https://example.com/path/{resourceType}?search parameters
  • History – Retrieve the change history for a particular Resource or all Resources = GET https://example.com/path/{resourceType}/{id}/history

There are also more comprehensive interactions that include Batch/Transaction, Operation, Vread, Patch, and Capabilities. In addition to these interactions, there is an operations framework, which includes endpoints for validation, messaging, and documents.

Extending and Restricting the API – defining a set of desired behaviors – is done via the CapabilityStatement Resource which lists the REST interactions (read, update, search, etc.) that a server provides or that a client uses, along with some supporting information for each. The only interaction that servers are required to support is the Capabilities interaction itself – to retrieve the server’s CapabilityStatement. Beyond that, servers and clients support and use whichever API calls are relevant to their specific use case. FHIR servers can also provide additional operations that are not part of the FHIR specification. The Conformance Resource supports defining what OperationDefinitions make use of particular names on an endpoint. Implementations are also able to extend the FHIR API using additional content types. For instance, it might be useful to read or update the appointment resources using a vCard-based format. vCard defines its own mime type, and additional mime types can safely be used along with those defined in the FHIR specification.

Managing Variability

The FHIR specification describes a set of base resources, frameworks and APIs that are used in many different contexts in healthcare. Recognizing the wide variation between different geo-political jurisdictions and segments of the healthcare industry with no central authority to impose common business practices, the intent of the standard was to provide coverage for 80% of the common use cases and define a simple framework for extending the existing Resources and describing their use with Extensions and Profiles.

Profiles can define:

  • Rules about which Resource elements are or are not used, and what additional elements are added that are not part of the base specification
  • Rules about which API features are used, and how
  • Rules about which terminologies are used in particular elements
  • Descriptions of how the Resource elements and API features map to local requirements and/or implementations

By default, all systems can read all Resources, but applications can add more control and meaning using Profiles. Many healthcare contexts require extensive local agreements between parties to make sure data exchanges are accurate and complete. Healthcare variability can also be seen where the same information may be represented differently and with different levels of detail, granularity, and nesting by exchanging parties. For example, in some cases a blood pressure measurement may be just a simple observation, a vital sign measure, while in other cases it can be a rich set of highly defined data that includes things like controlled vocabularies for posture, exercise, etc. The Resource types defined in the FHIR specification focus on the general, common use cases. Richer and more specific content can be supported and standardized by defining “profiles” on the base Resource types.

FHIR Versions and What They Mean

As standards change over time and presumably get better, those currently using previous versions of the standard face hard choices about how to, or even if they should, change production-level systems to conform. This is especially problematic when specific versions of the standard get included in contracts and even law as has already happened with some United States laws (see Who Uses FHIR above ↑↑).

Today, the current standard is FHIR Release 4 (FHIR R4) which now contains fully normative content for many Resources. As you might see from the milestones below, work on many projects including those described below were undertaken at the standard’s earlier development levels.

Here are some major milestones in the FHIR development timeline:
Dec 27, 2018 4.0.0 Release 4 (1st Normative Content + Trial Use Developments) also called R4
Feb 21, 2017 3.0.0 Release 3 (STU – Standard for Trial Use) also called STU3
Oct 24, 2015 1.0.0 DSTU2 (Second Draft Standard for Trial Use)
Sept 30, 2014 0.0.82 DSTU1 (First Draft Standard for Trial Use)
Some early projects using the FHIR standard of note include:
  • Dec. 2014 – The Argonaut Project is a private sector initiative to advance industry adoption of modern, open interoperability standards. The purpose of the Argonaut Project is to rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for electronic health records and other health information technology based on Internet standards and architectural patterns and styles.
  • Jan. 2018 – The Da Vinci Project stakeholders are industry leaders and health IT technical experts who are working together to accelerate the adoption of HL7 Fast Healthcare Interoperability Resources (HL7® FHIR®) as the standard to support and integrate value-based care (VBC) data exchange across communities.

Trisotech and FHIR®

Trisotech supports the FHIR standard in several ways including the FHIR R4 Accelerator, direct connections to FHIR Terminology Servers, Healthcare Value Sets and Code Systems lookup/auto-completion support, extended Healthcare run time automation support and Terminology/Definition Linking in Models.

Trisotech offers various FHIR modeling accelerators and the Digital Automation Suite can integrate with various FHIR servers.

Learn More
Digital Automation Suite logo

The FHIR R4 Accelerator – FHIR at Your Fingertips

Trisotech provides pre-defined and pre-populated FHIR R4 Resources Accelerator. This Accelerator provides predefined FHIR Resource structures in the form of FEEL data types for use in the Decision, Workflow and Case modelers, and the Discovery Accelerator. Adding a FHIR Resource as a FEEL data type to a model is a simple drag and drop operation. The FHIR Resources in the Accelerator are organized by category (e.g. Individuals, Diagnostics, Medications, etc.) and sub-category (e.g. Individual->Patient, Provider, etc.) reflecting the FHIR standard Resource Index for quick reference. Specific Resources can also be found through the Trisotech Accelerator search function. Once a FEEL data type has been added to a model, all the fields in that structure are available for use in the modelers. In for example, clinical decision tables and other DMN logic, FEEL statements for condition expressions in sequence flows (decisions) in Workflows, etc.

FHIR Resource FEEL data types as input data in DMN models, for example, can be used “by reference” meaning there is only a single modeling source for the definitions thus locking them so they can only be administered using specific privileges. This addresses separation of concerns issues. Multiple Accelerators can address custom Implementations and differing version support since accelerators can be copied and/or changed per user needs. The use of this Accelerator can easily save hundreds of hours of work for a healthcare organization adopting FHIR.

FHIR Terminology Server Support

The Trisotech modelers and automation functions support a direct connection to your FHIR Terminology Server of choice. The FHIR Terminology server settings are configured in the Administrator interface. Many large healthcare organizations have their own terminology servers and there are numerous publicly accessible terminology servers, as well. Each Terminology Server supports a specific set of operations defined by the service provider on the RESTful interface (APIs). Technically, to achieve this these servers typically provide ValueSet and CodeSystem FHIR Resources via expanded FHIR operations defined by OperationDefinition Resources.

Trisotech makes extensive use of these Resources by connecting Terminology Servers to the Knowledge Entity Modeler (KEM) for Terms definitions and supports linking and auto-completion lookups from those servers for Decision, Workflow and Case Modelers.

FHIR Value Set and Coding Systems Lookup and Auto-completion Support

Each Term in a KEM model has a tab for Healthcare coding which offers auto-completion of codes using ValueSets and CodeSystems from a FHIR Terminology server. In the ValueSets section you can search for ValueSets by keyword in the search field (such as “Diabetes”) to get a list of ValueSets available. Select the result you want to add, and it will appear in the Coding list auto filling the 3 fields Coding system, Code and Display name. You can add more than one code (i.e. a list) to support multiple codes for more detailed specifications or in support of multiple coding systems such as ICD9/10, SNOMED, LOINC, CPT, etc. Once a ValueSet has been added to the KEM model, a suggestion dropdown which will appear when you type content into it. The suggestions will be filtered from every coding system you already have in your current model, and it will also search on your FHIR Terminology Server for corresponding ones not yet added. Finally, the user can put a coding system URL directly into the Coding System field and the modeler will automatically replace the URL with the coding system name. (e.g. http://snomed.info/sct sets SCTUSX as the Coding System Name.

FHIR Term Linking in Model Shapes

Terms used in the Name and Description fields of model shapes can be linked to Terms created in the Knowledge Entity Modeler (KEM). This means you have direct access to organizational vocabularies (Terms) that can be defined and maintained by connections to FHIR Terminology Servers. Using your own organizational Terms associated with specific Value Sets and Code Systems ushers in a new era in conformance and a powerful way to specify and limit coding system use across the entire organization.

Healthcare-specific Extended FEEL Functions and FHIR

New healthcare-specific extended FEEL functions (“healthcare codes”, “healthcare term codes”, and “healthcare code in term”) are also available in the modeler menu and to access KEM Terms or coding system codes (e.g. ICD-10, LOINC, etc.) in the automation engines at run time. These are typically used with Decision Models (DMN) to determine if specific healthcare codes defined by a Term in your Knowledge Entity Model or a specific code or term in an external coding system terminology server are present for a Patient. This makes determining a specific condition in a Patient (such as “Diabetes” defined via codes your organization supports) visual and very simple to understand in clinical decision models and clinical pathway workflow models.

Trisotech’s powerful combination of extended Healthcare FEEL functions, FHIR Terminology Server support and direct URL support for other terminology servers makes decision making in DMN models and sequence flows in Workflow models available at runtime through the Trisotech automation engines.

Resources

Related to FHIR

Trisotech

the
Pioneer

View all

Learn how it works

Request Demo

Confirm your budget

Request Pricing

Discuss your project

Request Meeting
Graph

If your Business runs on Rules, it should run on Trisotech!

Get Digital Enterprise Suite