+1 312 646-5077 sales@objectivegroup.com

FHIR is an open standard that has gained widespread industry recognition and support for its potential to make interoperability a reality in healthcare.

Healthcare organizations must consider carefully when making changes in health information technology.  You must insure the changes are future-proof, and solutions need to be interoperable to support the transition to value-based care.

FHIR is an open standard that has gained widespread industry recognition and support for its potential to make interoperability a reality in healthcare. FHIR has excellent documentation, is relatively easy to learn and is supported by a growing community of passionate health IT experts.

Based on the myriad pages both ONC and CMS published on February 11th, it is here to stay. FHIR has few inherent limits on the development practices you use, and offers many benefits for data management and interoperability.  



When choosing technology stacks, development platforms, HIPAA hostings, EHR integration pathways, standards and terminologies, choices may not affect the immediate outcome, but long term consequences might be enormous.

Two solutions may equally address current business needs, but their fates may become very different. One solution will become obsolete quickly and the other will flourish for years. Making decisions that will give your solution a long lifecycle, you must predict what will happen to HIT in the coming years.

Population Health Management in a Value-Based system is an enormous challenge for any organization. No single solution can address this challenge alone, and there is a growing need to support an ecosystem of interoperable healthcare applications.

It was hard to envision such an ecosystem a few years ago because of the Wild West options available. There wasn’t an interoperability standard recognized and embraced by the industry. Fast Healthcare Interoperability Resources (FHIR) is the banner-bearer, and many vendors and provider organizations have already started their journeys to the new world of digital health platforms, open APIs and application marketplaces.

Choosing FHIR for your next project could be the most important choice in making your solution future-proof and ready for the next-generation health information ecosystem where data flows seamlessly between EHRs, patient-facing mobile apps, and medical devices.


FHIR in the Back 40

Developing your solution based on a FHIR backend doesn’t alter your development process. You will still need to complete a project discovery phase, formulate a project vision and a beginning scope. You can continue to use your favorite Agile Practices, Test Driven Development, DevOps and Continuous Integration.

FHIR applies no restrictions on your processes. A FHIR backend does not affect the choice of your technology stack either. Whether you prefer Java, Ruby, .NET, Swift or Clojure, you will find open source libraries that support the technology you choose. REST APIs and it’s like will work with your FHIR backend, but will not create any barriers for you to continue using your favorite tech stack.

The source data you choose is the key. Design data models and structures to store your data using the open FHIR data models available. This modeling may be different at first, but your modellers will catch up very quickly as FHIR has excellent documentation and is easy to learn.

FHIR documentation is freely available online at https://www.hl7.org/fhir/overview.html and is concise and easy to understand. The FHIR Community of interoperability experts is only one click away ;  https://chat.fhir.org/login/ .

Register, join and get all your questions answered in a matter of hours, if not minutes. Leverage this passionate community. If you do, you not only ensure that your use of the FHIR resources and their fields is correct but also provide valuable feedback about the standard and its documentation.



FHIR does bridge the Health Plan and the Health System, so vocabulary translation is key.

A good example of this is how FHIR represents patient diagnoses. You will learn that FHIR calls diagnoses ‘conditions’ ; A description of the condition resource is available in the FHIR specification. Although there are many fields in the condition resource, almost no fields are mandatory.

FHIR may remind you about important data elements that have slipped away from your attention and point you to the right terminologies. Those who are new to healthcare IT will learn about the SNOMED terminology when reading about the FHIR condition resource.

Start by choosing the fields you need and document the mapping you know. From there, you can store and manipulate the data about diagnoses in your FHIR backend.


Expanding FHIR

You will eventually come to a point where some of your data doesn’t fit into the FHIR format very well. Many data elements that are very common in your organization aren’t considered common by the FHIR community. Race, ethnicity, organ donor status, nationality, and religion are not part of the core Patient resource.

You should raise this kind of concern within the FHIR community so other members can assist and collaborate with this community driven standard. Create your example using FHIR extensions and share.

This Race extension example might look like this:

{ “url”: “http://hl7.org/fhir/StructureDefinition/us-core-race”,
“valueCodeableConcept”: {
“coding”: [ {
“system”: “http://hl7.org/fhir/v3/Race”,
“code”: “1096-7”

Working with extensions can add a burden on engineers and increase your time to market. But getting the discussion beyond your immediate need and into the community may help minimize the impact of future standardization within the standard.


Is a FHIR based solution for EHR systems just too many acronyms?

Your FHIR-based solution with EHRs may have a few shortcuts available.. If you are developing a SMART on FHIR application, you’ll receive EHR data in the FHIR natively, with minimal efforts to load your FHIR backend. SMART on FHIR is supported by several major EHR vendors.

Epic’s FHIR API https://open.epic.com/Interface/FHIR

Cerner’s FHIR API http://fhir.cerner.com/

For a legacy EHR data, integrating with a FHIR backend is still easier than with a custom solution. Most hospital system HL7 engines can easily translate legacy HL7 v.2 data to FHIR. There are also generally complete mappings for HL7 v.2, CCD and X12 data.

Building with a FHIR backend eases integration with EHR technologies, enabling plug and play connectivity in the FHIR ecosystem.