The Structure of FHIR Resources
Posted on September 19, 2016
Let’s begin by reviewing some basic facts about Fast Health Interoperability Resources (FHIR). A FHIR resource is a representation of one of the objects managed by Electronic Health Record (EHR) systems. The word “object” shouldn’t be taken too literally, though. A FHIR resource may represent a person, as is the case with Patient and Provider, an event such as an Encounter, or something more abstract, such as BodySite.But FHIR resources are not merely concepts. A resource will contain a number of properties (such as demographics for a patient) and relationships with other resources. Resources may be divided into a number of categories:
Of these, the first four groups are of the most direct interests to clinicians. The others generally have to do with implementation issues. But under Conformance we find resources such as ConceptMap and ValueSet that will be familiar. Similarly, under Infrastructure, we find resources such as Provenance that will be of interest to health care providers. On the other hand, there are low level resources such as DataElement and SearchParameter that make the most sense in the context of implementations. In their excellent clinical introduction, HL7 suggests that instances of resources can be thought of as completed forms, and I find this a useful model (for developers, too).
So, if a resource is a form, what are the fields or boxes on that form? Each resource will consist of a number of fields. As you might expect, the Encounter resource includes fields for patient, location, indication (procedure or diagnosis), referral, and so forth. It’s not exactly an encounter form because this resource is used for inpatient treatment as well as outpatient encounters, but other than that, it is not unlike the familiar form.
Delving a bit deeper, each resource can be represented by a sequence of fields or keys, each of which may or may not be required, and many of which allow multiple values. For example, a Patient or an Organization may have many addresses, each with a different use. Most fields are optional if it makes any sense to omit them. The reason for this is that FHIR is meant to be used in a variety of contexts, and by a variety of systems, so its designers have tried not to impose accidental restrictions that would impair its usefulness in a given situation. Adopters should develop profiles that further restrict FHIR in a way that is appropriate to their use case and technology. Adopters may introduce extensions, which are essentially additional fields needed by a given application, and locally defined vocabularies (for example, for specialized uses for e-mail addresses or telephone numbers).
Now, what about the values associated with the fields in aa resource? Many of them will have basic (or primitive) data types such as integer, string, dateTime, or URI. Others will have complex data types such as Timing, Address, HumanName, or Signature. Each of these is itself composed of other fields, and they are comparable to record or structure data types in many programming languages. Next, a field may take as its value a code or CodeableConcept. As you might expect, codeable concepts are things such as procedures, diagnoses, body sites, medications, outcomes, and so forth. A single codeable concept bay be represented by multiple codes (e.g., ICD-10-CM and SNOMED CT). Finally, a resource may contain references to other resources. For example, in the Encounter resource, patient is a reference to a Patient resource. Resources can be handled in one of two ways: as embedded resources (meaning the details of the referenced resource are stored entirely within the given resource), or as external references. In the case of external references, all that is stored is an identifier, and the referenced resource must be retrieved separately.