The IT Developer’s Guide to FHIR for Healthcare

We’ve put together this guide to provide IT developers with a comprehensive overview of FHIR, including the basics of how FHIR works, how to implement FHIR, and valuable learning resources for those who want to delve even deeper into FHIR. In this guide, we’ll talk about:

• What is FHIR?
• How FHIR Works
• Benefits of FHIR
• An Overview of FHIR for IT Developers
• Putting FHIR to Work for You
• Learning Resources for FHIR
• Further Reading on FHIR for IT Developers

What is FHIR?

FHIR (Fast Healthcare Interoperability Resources) is a relatively new setof standards providing a mechanism for exchanging data betweenhealthcare applications. Health Level Seven International first sponsored FHIR (pronounced“fire”) in 2011, and it remains in active development. As HL7 explains, “The intended scope of FHIR is broad, covering human and veterinary, clinical care, public health, clinical trials, administration and financial aspects. The standard is intended for global use and in a wide variety of architectures and scenarios.”

You may wonder why FHIR is more exciting when compared to other interoperability standards like clinical document architecture or the continuity of care record standards. The most significant difference between popular interoperability standards and FHIR is speed. FHIR supports four methods for information exchange including REST, which is the standard the internet uses.

How FHIR Works

To put it into perspective, FHIR works like the internet for healthcare records. Google uses technology similar to FHIR to give you search results when you search for the best sushi in your area. There’s no server with a database of the sushi restaurants in your area. Instead, Google crawls the internet and catalogs the data so that it can give you fast, accurate results if you ask for them.

As crude as that description may seem, that’s FHIR in a nutshell. The same standards used to protect banking information and other means of authentication and security are there as well. FHIR is safe and secure, plus it’s both fast and flexible. FHIR works for everyone from your local family provider to volunteer clinic in the middle of a desert or jungle, at least in theory. Like its predecessor, the HL7 standards, FHIR has its share of challenges.

The biggest challenge is a prominent issue that exists with HL7 implementation, as well – it’s possible for two different applications to implement different versions of FHIR, which means the systems are not interoperable, despite both having implemented FHIR in some form. It’s also possible for developers to implement only some of the available FHIR APIs or implement only partial APIs. The end result in either scenario is the same: falling short of the interoperability the industry is striving for.

The Need for FHIR Implementation

For IT developers, implementing FHIR is faster than other interoperability standards because it’s more powerful but easy to learn and develop. We’ll get you started by explaining the basics and providing a few ideas for you to build on, but it’s genuinely a standard you can mold to your needs.

Healthcare is currently buried under mountains of data, but much of it is unorganized or out of reach. People responsible for emergency care may not have the patient history they need which might force them to resort to guessing or basing their treatment on the information the patient provides. If the patient is unable to give any history or allergy information, the problem gets worse.

FHIR, if used as a standard, removes these problems and puts a patient’s history at the doctor’s fingertips. An excellent example of how easy FHIR makes data exchange is this patient browser on GitHub. It’s a simple HTML5 app that lets you browse data the same way you search for movies on your favorite streaming service. You can check out a working demo here.

An Overview of FHIR for IT Developers

The initial thought when you read about FHIR and what it’s designed to do is always human healthcare. Healthcare providers struggle with exchanging information and developers struggle to provide ways for them to do it. Everyone has their own ideas, and they use methods that may not play well with others. FHIR works for everyone from hospitals to veterinarians.

Resources represent healthcare data in the FHIR realm. Resources are used to build an instance-level picture of the data to exchange. Resources may aid in exchanging the data or provide a means to store the data like a web page does for the internet. In order to keep this process and the structure of resources consistent, resources must include the following things:

• A URL to identify the resource
• Metadata to aid in searches and for cataloging
• An XHTML summary so people can read it
• Definitions for data elements
• An extensibility framework specific to healthcare

The 145 resource types that FHIR supports must be in either XML, JSON, or RDF formats,usually. A patient represented in XML may look like this. The same patient represented in JSON looks like this. The screenshot below illustrates how a patient could be represented as aFHIR object in JSON, with XML encoding defined in the specification:

Screenshot via HL7

JSON is easier, and you may find uses for it in other applications as well. XML is no slacker and should work if XML is your favorite of the most popular among your development team. Here’s a more detailed look at what elements comprise a resource:

• resourceType (line 2): One of the 145 resource types defined by FHIR. This is a required element.
• id (line 3): This element is the id of the resource and must always be present when a resource is exchanged. The only exception is during the create operation.
• meta (lines 4 to 7): This element provides common uses and other context information to all resources. It’s usually present, but not always, and some metadata items may be required in certain implementations or use contexts.
• text (lines 8 to 11): This element consists of XHTML that provides a human-readable representation for the resource. It’s not a required element, but it is recommended.
• extension (lines 12 to 17): This optional element includes extensions defined by the extensibility framework.
• data (lines 18 to 43): Another optional element, this section includes a different set of data elements defined for each type of resource.

It’s unlikely you’ll run across any software that can’t deal with XML or JSON. However, you can use RDF and Turtle to build your resources. XML, JSON, and RDF are formats used regularly for websites and data-driven web apps. If we’re honest, it doesn’t matter what you favor as long as you remain consistent and get the syntax right.

Resources may get assigned a URL to help identify the resource plus help you find it. Similar to a web page which may use a relative URL, the URL is not always defined within the resource. If you want copies of the resource to point to the original at all times, adding a URL inside the resource is necessary. However, this may be unnecessary in most cases. You’ll have to make that decision.

You can manipulate data using FHIR’s built-in REST API. You can use POST, DELETE, GET, and PUT to create, read, or otherwise manage resources. For instance, you could use “PUT https://www.example.com/path-to-your-resource/resource-type/resource-id” to update a resource when the data changes or needs to get changed for whatever reason.

Granted, our example is rather basic, and you’ll end up using a more elaborate URL and resource identity system, but that’s the general idea behind using URLs and the REST API. As long as the URLs are encoded using UTF-8 and consistent, everything should work much like browsing to your favorite website or blog to read a post.

The same layers of security and encryption that protect your credit card information while you shop on Amazon or stand guard over your online checking account sit between the person trying to access the resources and the resource. While we make it sound like you’re building an internet for healthcare records, the data is safe and encrypted and only available to authorized people, just like your bank account.

Putting FHIR to Work for You

In healthcare, the most common resources include patient history, patient conditions, and patient treatments. It’s a little more complicated than that, but for our purposes, let’s assume it’s that simple. The first task in the development chain is creating a server and building an API for browsers or phone apps. The process is similar to making a web app to serve data, which is part of the appeal of FHIR.

In this instance, you need a server, a database, and FHIR resources to search or serve. You can store FHIR data in a database and skip some of the resource creation steps. However, you’ll need a way to map the FHIR resources as objects and maintain that mapping and the database.Instead, storing the FHIR resources like documents and using something like MongoDB to track them is easier.

MongoDB makes organizing and changing documents much simpler overall. Explaining MongoDB falls outside the scope of this article, but we urge you to take a more in-depth look at it and weigh your options before trekking off to build a relational database and FHIR apps. It’s fast and flexible, plus they made it with documents in mind. That’s a strong selling point for using MongoDB with FHIR resources.

We’re making a few assumptions now and assuming you took our advice about using a document database instead of MySQL or something similar. Many of the following steps require knowledge of your needs and development prowess, which we do not possess. For that reason, refer to this information only as a guide and do your homework on the software and devices you plan to use.

If you’re just developing an app or browser, you can test them without creating a bunch of fake patients and building a server by using some of the public test servers here. You can find servers behind that link configured for nearly any scenario or code you want to use.

Screenshot via HL7

This is, again, a highly simplified example, but we’ll assume for illustration purposes that the needs associated with this project are for a hospital or practice. Under those terms, the three things you need to get done include the following:

• Search for a patient or patients
• Create and store patients
• Retrieve specific patient data

Step one is creating a server, but you need to make some choices at this point before you get started and realize a better option exists. Using open source servers is a budget-friendly way to get started. Open source software is free most of the time, and you can get support online through forums and wikis. Some developers offer support and implementation help for a fee as well.

Unless you have a plan for a server, an excellent place to begin yourjourney and get some insight on what other developers are doing is by checking out some open source FHIR implementations and servers. You can see the code and how they approach problems and solve them. You may find an answer there are well, and you can avoid developing your own server solution.

Screenshot via HL7

That solves storing patients, and the server gives you access to the data. Now you need an API. You can find an excellent example of an FHIR server and API here that uses Microsoft Azure. Azure is a good option if you don’t have the resources or budget to create your own data center. A quick Google search will net you similar solutions for Amazon, DigitalOcean, oryour favorite service.

Screenshot via GitHub

A key feature and problem with FHIR is its flexibility. The two previous paragraphs may be all you need to get started and develop a working FHIR server and API. Granted, we haven’t added any security or authentication methods to our setup, but our goal is getting it working and into beta testing. HAPI may be a more straightforward solution, and you can skip all the coding and use almost any commercial server.

HAPI provides this guide that boasts the ability to build a healthcare database and FHIR API in 15 minutes. It took us about 40 minutes to get it running using Ubuntu as our server in a virtual machine. However, this is an excellent learning opportunity, and we suggest trying it. It uses Java, Tomcat, and Apache Derby for the database. You can use another database if you don’t like Derby.

Hopefully, we demonstrated the flexibility of FHIR and provided some real-world working examples to check out. However, we barely scratched the surface of what FHIR is capable of and what developers are doing with it. The next step for you is digging deeper into the code and finding learning opportunities. You can only glean so much from looking at other people’s work and ideas.

Learning Resources for FHIR

Screenshot via HL7

The best place to learn more about FHIR is through one of HL7’s fundamentals courses. Check the link for registration dates and course dates. They close and open registration periodically. The instructors are FHIR experts and work with FHIR, so no textbook teachers. You don’t need any understanding of FHIR to succeed in the course. Nonetheless, we suggest studying up on it a bit beforehand.

Firely offers a professional server solution for FHIR. They also provide excellent training tools, classes, and onsite training. If you take HL7’s course followed by Firely’s, you’ll be on your way to becoming an FHIR implementation expert. Firely takes you deeper into FHIR and offers some pretty advanced training classes. Additional training resources include:

• The Learning Center: they offer a wide variety of healthcare training with some FHIR peppered in at times.
• National Library of Medicine: a quick search here nets 263 FHIR related topics to check out.
• HL7: they offer much more than their fundamentals training.

Check with colleges and universities in your area to see if they offer continuing education classes on FHIR or the tools you need to make FHIR work for you. Don’t rely on internet tutorials and free training to get you going. You’ll miss out on critical issues like solving problems related to securing the data for use with mobile apps or creating FHIR browsers that resist hackers.

Some Final Notes

FHIR is powerful and may topple the current hierarchy of interoperability in healthcare. Arguably, FHIR is trampling other standards, but it’s hard to get developers and providers to make changes. Once they have a working solution, they tend to stick with that solution. FHIR is a significant improvement over previous and current standards, but inconsistent implementation of FHIR continues to be a hurdle in the path towards interoperability.

FHIR isn’t the only way to apply the benefits of APIs to healthcare information systems. An API solution like Integrate can make interoperability both practical and cost-effective while eliminating the usual barriers to interoperability. Integrate offers read and write capabilities with any EHR through a robust set of universal, real-time REST APIs and a unified data model to standardize EHR integration. That means no need to worry about applications implementing different versions of FHIR or a different set of APIs; to connect to an EHR, you only need to code once to the Integrate APIs to support the seamless exchange of healthcare information between EHR platforms, clinical, and administrative systems. Thanks to Integrate, IT developers can provide real-time access to clinical and administrative data without compromising PHI security. Visit our API Learning Center to learn more.

Further Reading on FHIR for IT Developers

Want to learn even more about FHIR? The following resources provide useful information on FHIR in practice, including tutorials and other resources for IT developers who want to implement FHIR:

• Beyond One-Off Integrations: A Commercial, Substitutable, Reusable, Standards-Based, Electronic Health Record–Connected App
• HL7 FHIR for Developers
• Interoperability Proving Ground (IPG)
• API Resource Collection in Health (ARCH)
• SMART on FHIR Tutorials
• FHIR for Developers
• Terminologies: Critical, but often deferred in FHIR application development
• Playing with FHIR – TUT002 : Creating a PATIENT Resource
• Using FHIR to Simplify Healthcare Application Development
• Tutorial: Access FHIR API with Postman
• HAPI on FHIR 10.16.2018
• Building a FHIR IG
• FHIR Tutorial