FHIR HL7: The Foundation of HealthTech Interoperability

FHIR has emerged as a transformative standard in healthcare data exchange, developed by HL7 (Health Level Seven International) to address one of healthcare's most persistent challenges: seamless information sharing across different systems and institutions. This standard represents a modern approach to healthcare interoperability, defining how healthcare information can be exchanged between systems while maintaining data integrity and security.

Built on contemporary web technologies, FHIR enables healthcare providers, patients, insurers, and healthcare technology companies to access and share vital medical information efficiently and securely. The standard's primary goal extends beyond simple data exchange – it aims to improve patient care by ensuring that critical health information is available whenever and wherever it's needed, from hospital emergency rooms to patient mobile devices.

Key components of FHIR

Resources

They are the fundamental building blocks of FHIR. These are small, independent components that can be individually searched, updated, extended, or adopted. Examples of resources include a patient, procedure, medication, or observation. Currently, there are 157 defined resource types. Below is the official list, available here.

As a structured data model, FHIR contains a set of predefined elements. These elements, defined by HL7, ensure that all resources (at least in their core version) are standardized. Importantly, resources are represented as JSON and XML, which are both human- and computer-readable.

Here is an example of a patient representation as a FHIR object in JSON format:

{
  "resourceType" : "Patient",
  "id" : "example",
  "identifier" : [{
    "use" : "usual",
    "type" : {
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
        "code" : "MR"
      }]
    },
    "system" : "urn:oid:1.2.36.146.595.217.0.1",
    "value" : "12345",
    "period" : {
      "start" : "2001-05-06"
    },
    "assigner" : {
      "display" : "Acme Healthcare"
    }
  }],
  "active" : true,
  "name" : [{
    "use" : "official",
    "family" : "Chalmers",
    "given" : ["Peter",
    "James"]
  },
  {
    "use" : "usual",
    "given" : ["Jim"]
  },
  {
    "use" : "maiden",
    "family" : "Windsor",
    "given" : ["Peter",
    "James"],
    "period" : {
      "end" : "2002"
    }
  }],
  "telecom" : [{
    "use" : "home"
  },
  {
    "system" : "phone",
    "value" : "(03) 5555 6473",
    "use" : "work",
    "rank" : 1
  },
  {
    "system" : "phone",
    "value" : "(03) 3410 5613",
    "use" : "mobile",
    "rank" : 2
  },
  {
    "system" : "phone",
    "value" : "(03) 5555 8834",
    "use" : "old",
    "period" : {
      "end" : "2014"
    }
  }],
  "gender" : "male",
  "birthDate" : "1974-12-25",
  "_birthDate" : {
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDefinition/patient-birthTime",
      "valueDateTime" : "1974-12-25T14:35:45-05:00"
    }]
  },
  "deceasedBoolean" : false,
  "address" : [{
    "use" : "home",
    "type" : "both",
    "text" : "534 Erewhon St PeasantVille, Rainbow, Vic  3999",
    "line" : ["534 Erewhon St"],
    "city" : "PleasantVille",
    "district" : "Rainbow",
    "state" : "Vic",
    "postalCode" : "3999",
    "period" : {
      "start" : "1974-12-25"
    }
  }],
  "contact" : [{
    "relationship" : [{
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v2-0131",
        "code" : "N"
      }]
    }],
    "name" : {
      "family" : "du Marché",
      "_family" : {
        "extension" : [{
          "url" : "http://hl7.org/fhir/StructureDefinition/humanname-own-prefix",
          "valueString" : "VV"
        }]
      },
      "given" : ["Bénédicte"]
    },
    "additionalName" : [{
      "use" : "nickname",
      "given" : ["Béné"]
    }],
    "telecom" : [{
      "system" : "phone",
      "value" : "+33 (237) 998327"
    }],
    "address" : {
      "use" : "home",
      "type" : "both",
      "line" : ["534 Erewhon St"],
      "city" : "PleasantVille",
      "district" : "Rainbow",
      "state" : "Vic",
      "postalCode" : "3999",
      "period" : {
        "start" : "1974-12-25"
      }
    },
    "additionalAddress" : [{
      "use" : "work",
      "line" : ["123 Smart St"],
      "city" : "PleasantVille",
      "state" : "Vic",
      "postalCode" : "3999"
    }],
    "gender" : "female",
    "period" : {
      "start" : "2012"
    }
  }],
  "managingOrganization" : {
    "reference" : "Organization/1"
  }
}

Based on the example above, we can highlight a few points:

• Complex patient identifier structure - This approach allows assigning different identifiers to the same patient, which is useful when the patient is registered in different systems (e.g., hospitals, insurers). However, it can lead to challenges with synchronizing data between different systems and the risk of duplicates if identifiers are incorrectly assigned.
• Expanded representation of names - This flexible approach is useful in various situations where a patient may be known by different names depending on the context, such as in hospital documentation vs. personal contacts. However, implementing this in systems requires careful attention to ensure consistency and proper mapping between different forms of names.
• Managing multiple phone numbers - A patient can have several different phone numbers, even of the same type (e.g., mobile).
• Extensions - An example can be seen in the patient's birth date. This is a powerful tool that fills in gaps in standard data models. However, during development, it can lead to issues with storing data in databases or validating the data.

TIP: You don't need to be familiar with all FHIR resources. Most developers in their daily work with FHIR use only a handful of them, such as Patient, Practitioner, or Organization. Much depends on your specific industry - in insurance, you'll work with FHIR resources like Claim, Coverage, or CoverageEligibilityRequest. If you're working on a project with DICOM images, you'll need resources like ServiceRequest, ImagingStudy, or DiagnosticReport. Therefore, it's not worth focusing on learning all resources. Instead, concentrate on the fundamentals that will allow you to quickly jump into a new domain like medications or insurance when needed. These fundamentals include:

• Data Types
• Terminology
• References
• Search queries
• Profiles

RESTful APIs

RESTful API in FHIR provides a standardized HTTP-based interface for healthcare systems to exchange medical data securely and efficiently. The key functionalities include CRUD operations for basic data manipulation, search capabilities for querying resources, and transaction support for complex operations. Key features of FHIR API:

• CRUD Operations
  • Contains all standard operations (Create, Read, Update, Delete)
  • Delete performs logical deletion only - records remain accessible however hidden from standard queries
• Search and Filtering
  • Each resource type has predefined search parameters specified in FHIR documentation under "Search Parameters" section. Here you can find search parameters for Patient 
  • Parameters have assigned types (string, token, date, reference) determining their usage
  • Supports chained search parameters (e.g., Encounter?patient.name=Doe returns encounters for patients named "Doe")
  • FHIR servers may disable certain search parameters if not needed or not implement them at all 
• Bulk Operations
  • Provides asynchronous API for retrieving large datasets
  • There are three export operation types: patient-level (all patient compartment data), group-level (specified group of patients), system-level (all data including non-patient resources)
  • Uses NDJSON (Newline Delimited JSON) as required format for data export

TIP: Although FHIR servers provide search functionality, they are not suitable for running complex queries. Instead, you should consider implementing a data warehouse or analytical database that regularly synchronizes with your server.

FHIR Servers

A FHIR server is a platform designed to store, retrieve, and exchange healthcare data in accordance with the FHIR (Fast Healthcare Interoperability Resources) standard. It facilitates the practical application of the FHIR standard for exchanging healthcare information. FHIR standard functions like a programming language - offering the necessary rules and structure for implementation, but requiring a platform to make it operational. The FHIR server serves as this platform, enabling the execution of the FHIR standard. 

There are many FHIR servers available on the market that we can utilize. These include:

• Cloud solutions, for example:some text
  • AWS HealthLake (Check out our Open Source Terraform Healthlake module for bootstrapping HealthLake, including Smart on FHIR configuration!) 
  • Cloud Healthcare API
  • Azure FHIR service
• Open Source, for example:some text
  • HAPI FHIR
  • fhir-server
  • node-fhir-server-code

TIP: It is important to remember that the choice should be considered for the specific use case – servers can differ in terms of how the FHIR standard is implemented, the costs of deployment and maintenance, the functionalities offered (such as bulk export or import, resources history), and the technological solutions like the database, which can impact scalability in the future.

FHIR Profiles 

What is often emphasized for the FHIR standard is the adherence to the 80/20 rule - suggesting that 80% of implementation needs should be covered by the core specification, with the remaining 20% handled through extensions. FHIR profiles enable customization of resource definitions by specifying which resource elements are required and which are optional.

Profiling can be complex, and sources point to several key challenges:

• Complexity: Defining profiles can be difficult, particularly for complex use cases.
• Conflicts: Different profiles may impose conflicting constraints or extensions on the same resource, which can hinder interoperability.
• Understanding: FHIR profiles can be challenging to understand for those unfamiliar with the FHIR specification.

As mentioned above, creating FHIR profiles manually is complex and time-consuming. However, there are tools that simplify this process, such as:

• Forge: A graphical application for creating and editing FHIR profiles without the need for coding.
• Simplifier.net: An online platform for collaboration, publishing, and versioning of FHIR profiles.
• FHIR Shorthand (FSH) and SUSHI: A scripting language and tool for quickly creating FHIR profiles in code format.
• IG Publisher: A tool for generating complete implementation guides containing FHIR profiles and guidelines.

Implementation Guides

Even if you're a newcomer to the FHIR world, you've probably already encountered an Implementation Guide. But what exactly is it?

Implementation Guides are particularly valuable for developers because they eliminate guesswork from FHIR development. Instead of diving deep into the vast ocean of FHIR documentation and making assumptions about how to implement features, developers get clear, practical guidance. They provide ready-made patterns for common scenarios, validation rules that catch errors early, and concrete examples of how to structure your resources correctly. It's like having an experienced FHIR developer looking over your shoulder, pointing out best practices and helping you avoid common pitfalls.

Think of IGs as detailed cookbooks that transform abstract FHIR specifications into practical, ready-to-use recipes. Instead of spending weeks figuring out how to model healthcare scenarios, developers can follow clear, tested patterns. They specify exactly which resources to use, how to structure them, and what extensions are needed – saving countless hours of development time and reducing implementation errors. 

The US Core Implementation Guide demonstrates this perfectly. It gives developers clear rules for implementing everything from basic patient demographics to complex clinical observations. This standardization ensures that when one system sends data to another, both sides are speaking exactly the same language. IGs serve as a shared reference point for development teams, providing validation tools and test scenarios to verify implementations against the standard.

TIP: If you need to create your own implementation guide, check out how the best ones are made - examples like US Core or International Patient Summary are excellent references to follow. In fact, many national implementation guides draw from US Core.

Why should FHIR be a foundation for your healthcare product? 

Starting a new healthcare project comes with countless technical decisions, but choosing FHIR as your foundation shouldn't be one of them. Whether you're building a patient portal, clinical decision support system, or healthcare analytics platform, FHIR offers a battle-tested framework that saves you from reinventing the wheel.

Integrations 

When developing a healthcare product, integration is key. You’ll likely need to implement numerous integrations, not only with internal systems but also with external services that your product must communicate with. By leveraging a FHIR server, the complexity of mapping resources is eliminated, drastically reducing the time needed to implement integrations. This leads to faster and more efficient product development, allowing your team to focus on building out valuable features rather than spending time on technical debt related to data mapping.

Regulations 

Furthermore, as healthcare regulations continue to evolve, FHIR offers an important advantage. According to the 8 Key Insights from the 2024 State of FHIR Survey, many countries are introducing stricter regulations around healthcare data exchange, with penalties for non-compliance. By adopting FHIR, you ensure your product is aligned with global standards, mitigating the risk of regulatory issues and future-proofing your solution as new regulations emerge.

Patient engagement

FHIR also plays a significant role in enhancing patient engagement, which is increasingly recognized as critical for improving healthcare outcomes. By using FHIR, you make it easier to share patient data between healthcare systems, enabling patients to access their medical records, stay informed about their care, and take an active role in managing their health. APIs enable seamless integration of patient portals with EHRs, making tasks like scheduling appointments, sending messages, and holding virtual consultations more efficient. Additionally, with remote monitoring devices, FHIR allows data to flow directly to a provider’s system, enhancing real-time monitoring and personalized care. A strong example of this is the open-source product fasten-onprem (https://github.com/fastenhealth/fasten-onprem), which allows patients to aggregate data from multiple EHRs. Thanks to the FHIR standard, the project currently supports over 25,000 healthcare institutions, empowering patients to have a comprehensive view of their health data across different providers.

Key challenges for FHIR

While FHIR solves many healthcare interoperability problems, let's be honest - it comes with its own set of challenges that you should be aware of before diving in. Being prepared for these hurdles will help you navigate your FHIR implementation more effectively.

Data analytics 

FHIR's JSON-based document structure, while flexible and comprehensive, presents significant challenges for data storage and analysis. Traditional relational databases, optimized for flat table structures, struggle to efficiently handle FHIR's aggregated domain model and nested data formats. Attempts to map FHIR structures directly to SQL tables often result in hundreds of separate tables, making data manipulation and analysis cumbersome. Although modern databases, including columnar ones, have improved capabilities for handling nested data structures, and implementations exist for storing FHIR data in systems like PostgreSQL, BigQuery, and Apache Parquet, the diversity of SQL dialects and approaches complicates code portability and knowledge sharing. Moreover, users and analytical tools still predominantly prefer flat data views, creating a persistent tension between FHIR's rich hierarchical structure and practical analytical needs. 

To address this challenge, the SQL on FHIR initiative emerged to standardize FHIR data querying across different database implementations, promoting interoperability and simplifying healthcare data analytics.

Expertise  

Numerous healthcare organizations, particularly smaller clinics and practices, struggle with limited resources and expertise to adopt FHIR successfully. For those with restricted IT budgets, the cost and complexity of transitioning to a FHIR-compliant system can be significant. Furthermore, there is a shortage of professionals skilled in both the technical aspects of FHIR and the clinical workflows it must support, which leaves many organizations unprepared to implement the standard effectively. Even for experienced developers, the barrier to entry is remarkably high. 

Interoperability in practice 

We've explored what FHIR is, the problems it solves, and its challenges. Now, let's look at how organizations are actually using FHIR to transform healthcare and solve real-world problems. These examples demonstrate FHIR's practical impact beyond just technical specifications.

Apple Health Records

Apple Health Records demonstrates how FHIR can transform patient engagement in healthcare. By implementing SMART on FHIR standards, Apple created a system where patients can aggregate their health records from multiple institutions alongside their self-generated health data. This means patients can now have their medical information organized into one comprehensive view right on their iPhone or iPad, helping them better understand their overall health and share key elements of their medical history when visiting new providers.

The implementation goes beyond just viewing data - it creates a two-way communication channel. Healthcare providers can view patient-generated health data within their existing electronic health record workflows, enabling more informed conversations during visits. The system supports sharing various health metrics, from exercise minutes and heart rate to blood pressure and lab results, all while maintaining strict security standards. All health record data is encrypted in transit and at rest, with Apple ensuring they cannot access or view any health information shared between patients and providers.

Currently, Apple Health Records is supported by hundreds of institutions in the US, more than a dozen in Canada, and two in the UK. You can find the complete list here.

Ukrainian National E-health

The Ukrainian National E-health system represents one of the world's largest FHIR-based projects in production, serving over 36.5 million users and handling 1,000 requests per second. Built on a microservices architecture, the system employs electronic digital signatures and blockchain-like algorithms to ensure data integrity and security.

What makes this implementation particularly noteworthy is its comprehensive approach to digitizing healthcare. The system includes practical features like ePrescription and eReferral modules, with 27% of electronic prescriptions being reimbursed within just one hour. Through pseudonymization of patient data and Attribute-Based Access Control (ABAC), it effectively balances accessibility with security, transforming Ukraine's largely paper-based medical system into a modern, digital healthcare infrastructure.

HealthGorilla

In the US healthcare market, HealthGorilla provides another compelling example of FHIR's real-world impact. It’s approved as Qualified Health Information Networks (QHINs) under the TEFCA framework, HealthGorilla built a national health information network that enables seamless data sharing between patients, providers, payers, digital health companies, and labs.

At its core, HealthGorilla leverages FHIR through a suite of APIs that allow digital health developers to aggregate each patient's entire clinical history in one place. This FHIR-based approach solves several critical healthcare challenges: it eliminates the need for time-consuming manual methods of accessing medical records, removes the burden of direct outreach to multiple physicians, and ends the reliance on patients to recall their medical history from memory.

Through their Patient Access solution, healthcare organizations can now enable consumers to retrieve and share their comprehensive clinical data from a nationwide network of clinics, hospitals, and EHR systems in near real-time. This highlights how FHIR can transform traditionally complex and fragmented healthcare data access into a streamlined, efficient process.

Summary

Thank you for making it to the end of this long article! The world of FHIR is a fascinating ecosystem that continues to evolve and grow. Although we've covered many aspects, we've only scratched the surface of them. Each of the topics discussed deserves its own in-depth exploration. Particularly interesting are the issues of interoperability, data security, and the possibilities that FHIR opens up for healthcare systems worldwide.

At Momentum, we've helped numerous healthcare organizations navigate the complexities of FHIR implementation, from small clinics to large hospital networks. Our team of experienced healthcare developers and architects understands both the technical intricacies of FHIR and the unique challenges of the healthcare industry. Whether you're just starting your FHIR journey or looking to optimize your existing implementation, we're here to help you build robust, scalable healthcare solutions that make a real difference in patient care.

If you're intrigued by specific topics, stay tuned to our blog. In upcoming articles, we'll take a detailed look at FHIR implementation in hospital systems, the standard's use in mobile applications, and the latest trends in medical data exchange.

Have a FHIR-related challenge you'd like to discuss? Reach out to our team today - we're always excited to share our expertise and help healthcare organizations unlock the full potential of interoperability.