ConductScience Digital Health


Launch your SMART on FHIR App with Conduct Science FHIR Launch

FHIR Launch

Using the Qolty App Builder, launch your app to iOS, Android, and FHIR, and thus compatible with your EMR

Exceptionally Easy

White Label your app, exactly to your needs. Whether its a clinical decision tool or rounding assistance. Drag and drop components from our Qolty Private Labeled app builder.



Fast Healthcare Interoperability Resources (FHIR) is a standard in health care for exchanging clinical information electronically. It was developed by the health care IT standards body- Health Level Seven International (HL7).  The Health Level Seven International is an American National Standards Institute (ANSI) –accredited organization. It is a not-for-profit organization that is dedicated to coming up with a framework and standards for sharing, exchanging, retrieving, and integration of electronic health information.

By incorporating the HL7 experiences with the previous v2 and v3 models, FHIR seeks to facilitate the exchange of healthcare data elements with medics, research IT systems, other healthcare vendors & providers as well as with other metadata systems on a wide array of electronic devices. It was necessary to develop accessible healthcare standards that can be broadly supported by a wide variety of devices (cell phones, tablets, and computers), in the modern age of rapid technological change. FHIR is superior as compared to the previous HL7v2 and v3 standards that were more complex, not royalty free, and less familiar thereby making them more expensive and reducing their adoption.

The main challenge for healthcare standards at the present moment concerns how to handle variability that is brought about by different healthcare processes. As more options and fields are added to the specification, it ends up becoming more complex and gradually adding the costs involved. The alternative to this is to rely on custom extensions, but often this results in other implementation problems.

The FHIR standard is the solution to this as it describes a simple framework for adapting and extending the existing resources. It does not matter how a system is developed, it can readily read these extensions. With this standard also, extension definitions can be recovered via the same structure as retrieving other resources. With this also, each resource conveys a readable text representation using HTML as a reserve expression option for clinical security. This is crucial in cases of complicated clinical data whereby systems take a simple document or textual-based approach.   


The FHIR-based processing is a next-generation standards framework that seeks to facilitate third-party application developers to come up with new medical Apps that can be integrated into the existing systems. Some of the ongoing projects that seek to facilitate the adoption of FHIR include the Argonaut Project, the Clinical Information Modeling Initiative as well as the Data Access Framework project. As compared to the previous HL7 v2 and v3 standards, the Clinical Document Architecture (CDA), and the Reference Information Model, FHIR is a modern and improved standard that leverages the latest web standards. It’s built on emerging industry approaches and predominantly uses a compositional approach with data organized by making use of a combination of building blocks called resources. Furthermore, FHIR specifies a RESTful application programming interface (API) to access resources (Wagholikar et al. ocw079).  


With FHIR it’s possible to exchange well-defined, very specific pieces of information as opposed to entire documents. Such specific details can be as simple as a person’s marital status or gender. This is a big contrast to the common standard that is based on CDA that transfers entire documents instead of a simple list or specific pieces of data. The current standard often needs to transfer multiple documents so as to meet a simple request. With this standard, a physician often has to search through many pages of information to locate the specific piece of information needed; thereby making the standard inefficient. With FHIR it’s possible to receive only, and specifically, the information needed. The standard also allows access to granular data elements that may not always be in some clinical documents. This is a strategic departure from a document-centric view to data-level access via APIs (application programming interfaces).

The FHIR specification provides a simplified abstraction of a medical record with normalized data elements that app developers can understand. FHIR specifications are freely available and easy to understand and develop (Wagholikar et al. ocw079).

FHIR also has the potential to spur innovation as it is much easier for software developers to work with. It would be feasible to set up a plug-and-play platform that can be similar to the Apple app store on account of the technical capabilities availed by this standard.  Developers can now come up with innovative and new apps by sticking to the well-defined set of rules and by making use of Public APIs. In this view, the interface takes a true app store view in regard to interoperability and healthcare data.

Another advantage of this approach is that the EHR system is not overloaded by research operations, allowing the EHR to focus on clinical operations. The FHIR cell builds on this approach, providing an alternate channel to access the Integrating Biology and the Bedside (i2b2) data, which can be used to supplement clinical operations through the use of apps (Wagholikar et al. ocw079).

In summary, some of the many improvements that FHIR has in contrast to the previous standards include:

  • Concise and easily understood specifications.
  • The FHIR cell can promote the adoption of SMART apps.
  • An added structure to access and search se the i2b2 repository
  • A strong focus on implementation. It is easy and fast to implement.
  • The serialization scheme is easily readable by developers.
  • FHIR has a firm foundation in Web standards such as OAuth XML, HTTP JSON, etc.
  • The specification is free and has no restrictions.
  • Multiple implementation libraries are accessible to facilitate development.
  • Has a strong ontology-based analysis that has a diligent formal mapping for accuracy.
  • As compared to the previous standards, FHIR can leverage and co-exist with each other.
  • Interoperability resources can be used independently or be adapted to suit  local requirements
  • Service-based architectures, seamless exchange of information via documents or messages and supports RESTful architectures.
  • Data from legacy EHR systems that are normally duplicated with the sidecar approach into Informatics for Integrating Biology and the Bedside (i2b2) instances can be migrated into new FHIR-enabled EHRs.


The FHIR server is made of two important elements: the code that operates the capture of FHIR resources from the EHR and the API management layer.

Node.js (an asynchronous event-driven JavaScript runtime) is used to write the FHIR server. Node is renowned for its stability and efficiency in building fast and scalable network applications. Such network applications can facilitate appropriate logging & auditing as required as well as a real-time rate limiting on a per-app basis. Depending on the needs of an individual, FHIR resources can be captured from Epic in any of the following ways:  

Epic Web Services.

In this method, data elements can be retrieved and then revealed through the FHIR interface by use of the provided Epic web services. One of the merits of this method is that any required logging and auditing is handled by these web services. They are also efficient and fast when retrieving data from Chronicles. They also retrieve data in real-time from Epic’s clinical database making sure that data is always up to date. The only thing to note about this method is that the data or metadata provided by the web service may not be sufficient to meet the requirements of a particular FHIR resource. For this reason, it is recommended to use another method in combination with the web service: which increases the maintenance and the complexity overhead.


The thing to note about this relational database is that it is normally updated once or twice daily with the data from the production clinical database. It is ideal in cases where there happens to be no web service available for a given data type. It may not be recommended for data elements that need up-to-the-minute accuracy. It is however important for prototyping FHIR resources with little effort in a proof-of-concept environment.


Chronicles is an Epic database that makes use of the Cache database management system. It is ideal for use when there’s no available web service, yet access to data elements is needed immediately. This method requires more diligence since it does not take care of the appropriate logging and auditing. It however provides timely and fast access to clinical data.

Summary and Key Points

Technology standardization and the internet have been important drivers of innovation in other large industries such as air travel and finance over the past couple of years in the modern era of rapid technological change. Adoption of open standards like FHIR has the potential to transform healthcare in the modern era.

FHIR solves queries from a set of modular elements called “Resources”. These modular components are assembled easily into working systems that help solve real administrative and clinical problems and at a cheaper price as compared to the existing alternatives. FHIR is ideal in a wide variety of contexts- server communication in large healthcare providers, cloud communications, mobile phone apps, and EHR-based data sharing.

The prior standards: clinical document architecture (CDA), HL7 v2, and HL7 v3, were not open source, were not designed using the latest web standards, and before 2013 required licensing fees. In the words of HL7, “FHIR combines the best features of HL7s v2, HL7 v3, and CDA product lines while leveraging the latest web standards and applying a tight focus on implementability.”

With the adoption of FHIR, the next venture would be to ensure that Apps are compatible with a variety of electronic health record (EHR) systems. The Argonaut Project seeks to achieve this which would help innovations in healthcare to reach the widest possible audience. The Argonaut Project is a joint effort between HL7, academic medical centers, major EHR vendors, the SMART team, and other partners which seeks to promote the wider use of FHIR resources and speed up the adoption of the SMART API within EHR products.

The major EHR vendors have all supported this project by either implementing a version of the SMART on the FHIR standard or by providing feedback on the upcoming versions of their products. These efforts have helped align the standard and have played a key role in ensuring that it’s implemented broadly in a way that ultimately benefits the patients and the healthcare providers.


  1. Wagholikar, Kavishwar B et al. “SMART-On-FHIR Implemented Over I2b2”. Journal of the American Medical Informatics Association (2016): ocw079. Web. 29 Apr. 2017.
  2. Bloomfield, R., Polo-Wood, F., Mandel, J., & Mandl, K. (2016). Opening the Duke electronic health record to apps: Implementing SMART on FHIRInternational Journal of Medical Informatics. Retrieved 29 April 2017, from
  3. Cole, G. (2016). Blog Retrieved 29 April 2017, from

Learn more about

ConductScience Digital Health

Let's work together!

Have questions? Ask anything!