This page is part of the FHIR Specification (v1.0.0: DSTU 2 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

1.8.2 FHIR Overview - Clinicians

FHIR Infrastructure Work Group

Maturity Level: N/A

Ballot Status: DSTU 2

FHIR (Fast Health Interoperability Resources) is designed to enable the exchange of healthcare-related information. This includes clinical data as well as healthcare-related administration, public health and research. It covers both human and veterinary medicine and is intended to be useable world-wide in a wide variety of contexts - in-patient, ambulatory care, long-term care, community care, allied health, etc.

FHIR is a specification targeted to those who write software and architect interoperable solutions. That's who must actually create the systems that will use FHIR. The FHIR specification does not attempt to define good or best clinical practice, nor does it provide guidance on user interfaces or workflows. Guidance in these areas may be useful but is outside FHIR's scope.

Because of FHIR's implementation focus, many aspects of this specification deal with the technical underpinings of the exchange of clinical information between electronic systems. This section provides an introduction to what FHIR provides and tries to highlight the portions of the specification that are likely to be of most interest to the clinical community and skipping over some of the technical drudgery of interoperability. However, if technical drudgery is your thing, feel free to dig right in wherever you wish.

1.8.2.1 Resources

From a clinical perspective, the important part of the FHIR specification to understand is the resources. Think of resources as "forms" reflecting different types of clinical and administrative information that can be captured and shared. The FHIR specification defines a generic "form template" for each type of clinical information - so one for allergies, one for prescriptions, one for referrals, etc.

FHIR data consists of repositories of completed forms - resource instances. The resource instances will describe patient information (demographics, health conditions, procedures, etc.) as well as administrative information (practitioners, organizations, locations). Some resources are infrastructure components used to support the technical exchange of information - describing what systems can do, defining allowed sets of codes, etc. FHIR repositories might be elecronic health record (EHR) systems, pharmacy systems, hospital information systems (HISs), etc. Some systems, such as clinical decision support engines, may expose FHIR interfaces even though they don't actually store any information.

Each resource contains a small amount of highly-focused data. A single resource doesn't say much, but a lot of very small resources together create a useful clinical record. Information systems map the actions that a user takes (look up patient records, make a note in their history, etc) to operations on the relevant resources.

1.8.2.2 Extensibility and Profiling

The forms in FHIR are generic. They have to be useable in different countries, by different types of clinicians in different contexts (human care, veterinary care, public health, research, etc). FHIR recognizes that one size fits all is not appropriate in a healthcare space, so it provides the ability to adjust the forms to be able to handle the needs of different implementation spaces - adding additional "extensions" as well as enforcing constraints. For example, a "prescription" form might have extension elements added to support tracking of restricted medications while also constraining what codes can be used to communicate types of drugs to a particular national standard. However, the forms are designed in such a way that these changes can be made without changing how systems pass forms around. Thus any system can consume completed forms even if they have "extra" elements added - and even if those particular extra elements aren't used by the receiving system.

To keep the base forms that everyone uses from being overly complex, FHIR has a rule that, in most cases, a resource will only include data elements if there's an expectation that most implementations will use that particular data element. That doesn't mean the data must always exist. For example, most systems in the world are capable of tracking "deceased date" for patient, even though that element will be blank for many patient records. On the other hand, not so many systems track hair color, so hair color would be omitted from the base form and those systems that need it (perhaps in some esoteric clinical research setting?) would be able to use extensions to capture it if needed.

To keep the number of resources reasonable, some of them are fairly broad. The Observation resource is used for vital signs, lab results, psychological assessments and a variety of other things. To set rules for more narrow areas (e.g. "What should I send if I want to share a blood pressure?"), FHIR allows the creation of profiles. There will be a great deal of clinical work involved in forming consensus around how different types of detailed clinical information should be captured and shared in particular settings. Tooling to support the creation of profiles directly by clinicians is part of the plan for FHIR, but is still in the very early stages.

1.8.2.3 Narrative

FHIR is intended as a system for sharing discrete data between healthcare systems in a manner that supports computer interoperability - decision support, rules triggering, trend analysis, etc. However, not every system is the same and not all systems will recognize all discrete data. As well, there is still considerable value in data exchange in circumstances where very little of that data is captured in a discrete manner. For this reason, FHIR resources support sharing not only discrete information for computation but also a human-readable view so that the humans on each end of a healthcare information exchange can still get a full picture of what's going on.

Narrative is expected to exist for most resource instances, though it can be omitted in a few limited circumstances. In some cases the narrative will be generated from discrete information. For example the narrative for a patient might look like this:

In other cases, the narrative might be generated directly by a practitioner. Examples might include referral letters, pathology reports, etc. Certain pieces of the narrative would later be exposed as discrete data.

1.8.2.4 Interfaces

In addition to defining the "forms" for data exchange (resources), FHIR also defines a set of interfaces by which systems actually share that information . There are four primary mechanisms or "paradigms" of exchange supported by FHIR: REST, Documents, Messaging and Services.

1.8.2.4.1 REST

REST is the simplest exchange mechanism. Continuing the "form" metaphor, a RESTful server can be thought of as a room full of filing cabinets. Within the room is a cabinet for each "type" of form it supports. The cabinet contains folders where each folder has a unique number and represents one particular real-world thing - one patient, one encounter one medication, etc. Each folder (resource instance) contains multiple pieces of paper, where each piece of paper represents a "version" of that real world thing. Every time someone updates a record, a new piece of paper is added to the top that file folder. To see the history of a resource, you just flip through the pieces of paper in the folder.

Note that a typical medical record is generally a big folder-of-folders with all the different types of 'form' or 'report' gathered together. This is convenient for someone who wants to review the whole record, but inconvenient for updating bits of it - there's always contention for access to it to update the right parts. In IT, the record will be deconstructed to it's smallest components for management purpose, and a computer will (well, should), assemble the right bits as required, by following the references from one piece of information to the next.

Now picture a clerk at the front door of that room. You can pass the clerk a requisition to have them do something with the information in those file cabinets. The "clerk" and set of requisition forms make up the FHIR restful API. With that API, you can do the following things:

• search: Search through the folders for ones that meet a set of search criteria
• read: Get a copy of the top piece of paper (most recent, aka current) of from a specific folder in one of the cabinets
• create: Add a new folder to the appropriate cabinet (with a new number)
• update: Add a new page (version) to the contents of a specific folder
• delete: Remove a folder from the cabinet (or more accurately, put a sticker on it saying "do not open")
• history: Look at all the pages in a single folder (or in some cases a particular file cabinet or even the whole room - though that's more for technical purposes than clinical purposes)
• transaction: Give the server a bunch of folders all at once to update
• operation: Ask the server to carry out some kind of procedure on the set of records it has

EHR and other systems may present a more sophisticated interface to their end users, but behind the scenes, they are all making the same sort of requisitions to the same file clerk.

1.8.2.4.2 Documents

Documents are a familiar mechanism for sharing information in the healthcare space. They are useful whenever there's a desire to guide how a consumer of information will navigate it and there's a need to have a "frozen" view of information that can be reliably retrieved even years in the future. Examples of document-like things in healthcare include discharge summaries and lab reports.

In FHIR, there's a special resource called Composition that acts as the "cover page" for a document. It identifies the title, author date, relevant patient and the table of contents. A FHIR document can be thought of as a set of sheets (resource instances) stacked together with a title page on top that is stapled together. That stapled collection can then be stored or passed around, conveying a whole set of information at once.

1.8.2.4.3 Messaging

Much healthcare information exchange happens using a messaging paradigm. In messaging, a collection of information is sent from one system to another with an explicit request to "do something". A message might request that a lab order be fulfilled or that two patient records be merged or notify a system that a patient has been transferred from one bed to another. Messaging is similar to documents in that it collects resources together. However, in this case, the cover page is a MessageHeader that acts as a requisition. And rather than a staple, the resources are joined together with a paper-clip. There's no expectation that the receiving system will store the data exactly as received.

1.8.2.4.4 Services

Services can be thought of as a light-weight way of doing messaging. Rather than a full cover page, a small sticky note is attached to the front of a resource. And sometimes rather than sending a full piece of paper, the relevant pieces are cut out and sent as fragments. The response to a requisition is a similarly paper-clipped bundle of resource instances. Services are likely to be used for things like decision support. E.g. "Is there a problem with prescribing medication X for patient Y?", "What's the recommended care plan for a patient with conditions A, B and C?"

1.8.2.5 Approaching the specification

A FHIR-based system's capabilities are defined by what the resources can say. From a clinical perspective, then, these things define the clinical record:

• the kinds of resources that are defined
• their data contents, rules about the data including what terminology codes
• how they link to each other
• how you can search for information

This information can all be found in the resource definition pages. The resources most likely to be of interest can be found on the Clinical and Administrative pages. Instructions on how to interpret the information found on the resource pages can be found here. The Logical table or UML views are likely to be easiest to understand. Also, don't forget to look at the examples tab for an idea of what kind of information can be expressed. Seeing how elements are used to convey real data is often more useful than just looking at definitions. Also, look at the Profiles tab to see examples of how different resources can be constrained for use in particular contexts.

Clinician and other domain expertise and feedback is always welcome as we continue refining the FHIR specification. At the top of each resource page is a link to the home page for the work group responsible for that particular resource. If you have feedback on resource design, consider getting involved.