In this post I revisit the issues with the FHIR Resources described in the earlier post – A FHIR experience: models or just definitions? To summarise:

• FHIR has no semantic inheritance, only a generic structural inheritance of Resources from abstract Resources like DomainResource, Element and so on;
• Accordingly, the following symptoms appear in the models:
  • Resources representing closely related entity types, such as Person, Patient, Practitioner, etc contain numerous separately replicated copies of common attributes rather than re-using any common definition (this is true across the board, not just for Admin Resources);
  • There are no abstract supertypes available to use at the types of other attributes, and thus no useful type substitutability in software, other than for the generic supertypes mentioned above;
  • To compensate, FHIR uses nearly 200 ad hoc choice type definitions which do not constitute reliable semantic types (i.e. it’s unclear what the criteria for the type of a field like Observation.subject really are), or map properly to normal typed programming languages.
• As a consequence, the FHIR Resources:
  • are brittle, in the sense that unexpected impacts are likely when changes are made to the main Resources to adjust ad hoc typing;
  • do not support classic fine-grained software re-use, due to the replication approach;
  • are likely to limit rather than improve true interoperability, as developers make local variations to models to reduce implementation difficulty.

However, there are changes that can be made that will greatly improve these characteristics, making life much easier for developers and Resource maintainers alike, and extending the life of FHIR. There would be some impact on current profiling efforts, but not a great deal, and certainly worth considering with respect to the long run, which is the next 10+ years of FHIR adoption and implementation around the world.

Some FHIR purists may take exception to the proposal below; I would urge them to consider firstly the value of standard modelling techniques properly applied, and secondly to seriously consider the challenges in maintenance, evolution, implementation and data processing of the next 10 years and just ask the simple question: can we make FHIR significantly better than it is today, reducing costs and improving interoperability for everyone?

What follows is proposed not in the expectation that it will be implemented, but as a basis for thinking about what might be possible at this stage.

(Ed. note: RelatedPerson fixed 12-09-2019 17:40 BST)

Background and Tooling

In the version of FHIR presented here, the HL7 FHIR DSTU4 resources were converted to the openEHR formalism known as Basic Meta-Model (BMM), which is published as an open specification, and then modified as described below.

BMM is an object-oriented formalism, conceptually similar to UML (minus the diagramming), with a fully formal definition. It has been in use since 2009 within the openEHR ADL Workbench, since about 2011 in HL7 CIMI, and since about 2016 in openEHR Archie (ADL2/BMM libraries and tools) and commercial tools including Marand ADL-designer and Veratech LinkEHR.

The BMM file encoding the FHIR DSTU4 and also the modified form of Resources is available within the openEHR reference-models Git repo on Github. It compiles within the ADL Workbench, which allows similar views as an IDE or modelling tool. Views of the translated model shown in this post are from this tool.

Current State of FHIR (DSTU4+) Admin Resources

To show this in pictures. Firstly, the inheritance structure of (some of) the FHIR Admin Resources:

Note that within these types, we have things like Practitioner, representing a healthcare professional, and PractitionerRole, which is the same thing, but with the addition of one or more roles/responsibilities within a provider institution. This latter addition is an instance of a type being defined based on an accidental property that the parent type may have, in other words, an unnecessary type. FHIR contains other such Resource types, most or all of which could be removed.

Next, an example of the resulting ad hoc ‘choice’ typing, using the Reference() construct:

To give an idea of how pervasive this is, the patterns page in the FHIR latest build lists in great detail all occurrences of choice-typing and indicates patterns that are proposed to address them. Here is an excerpt of the main table:

In the above, it is the second column that states the patterns. ParticipantContactable is a variation on Participant that allows any kind of Admin entity, also Device and PractitionerRole, but not Location. Essentially, this approach assumes that every attribute that has a type of some kind of Admin entity (often called ‘party’) and/or some other types like Device, Substance etc which are considered to ‘participate’ in an interaction, is a special case.

An Improved Model

The first thing we can do to improve things is to introduce an abstract Resource I have called Entity, to collect some ubiquitous attributes from across the FHIR domain resources:

This removes replication of over 100 occurrences of ‘identifier’ and two other common attributes. A more careful analysis might reveal that other attributes could be moved here.

Next, we develop the Admin Resources as a demographic model, enabling abstract categories such as Party (an autonomous participant in an interaction, e.g. a process, contract etc), Actor (a real entity such as a person or organisation) and Role (a role played by a real entity, such as chief of surgery, patient etc) to be represented. The following shows the inheritance hierarchy.

The key abstract Resources are defined as follows, reverse-engineered from FHIR DSTU4.

Party – a contactable Entity with relationships with other Parties, represented via PartyRelationship. Note that in DSTU4, there is quite a lot of variation and inconsistency in how ‘contacts’ and addresses are represented. Here, List<Contact> is used as the standard type for all contact information; address is inside the type ContactPoint. However, address could reasonably be moved out to a separate attribute if preferred. Either way, this single standard representation replaces numerous variants in more concrete Resources, making life easier for developers.

Actor – a kind of Party representing a real entity such as a person, organisation etc, independent of any participations; may have a name, means of communication (e.g. languages), and photo.

Role – a kind of Party representing a role performed by an Actor within some kind of Participation, for some Period, and potentially qualified by certain Capabilities.

Since they are so common, Roles whose performers are respectively Person and Organization have been defined as separate types PersonRole and OrganizationRole.

PartyRelationship – a kind of Entity representing a relationship from one Party to one or more others (targets), for a Period, and classified via type.

Now we can remodel the existing FHIR types Person, Organization and (arguably) Group as kinds of Actor (i.e. real entities), taking advantage of these new types.

Person – a kind of Actor representing a real person. Note that attributes such as birthDate, deceasedXX and maritalStatus are currently only found on Patient. This is another instance of the simple and easily fixable modelling error of creating a type based on the presence of accidental characteristics of the supertype (i.e. birthDate, deceasedXX etc are all characteristics of a Person, regardless of whether currently a Patient in a care situation). In this model, it will just be the case that birthDate, deceasedXX and so on are often Void in FHIR instances – but this is true of most attributes of most resources, most of the time. If it really were preferred to have a simpler variant and a more sophisticated one that included these attributes, the Person type shown here could be converted into two types named something like BasicPersonDescription and CompletePersonDescription, where the latter inherits from the former, and includes the extra attributes.

Note also that Actor.name has been redefined to be of type HumanName from Name – another simple but useful advantage of standard typing.

Organization – a kind of Actor representing a real organization such as a company, government department, institution etc, that may have internal structure (partOf) and a location of business.

Group – depending on what really is intended by ‘Group’ in FHIR, Group is probably an Actor in the current model, as shown here. In this approach, a Group is represented as a List of GroupMember relationships (a subtype of PartyRelationship).

GroupMember – a kind of PartyRelationship whose targets are other Partys. Note: this differs from Group in FHIR DSTU4, which allows members to be Substance, Medication, Device etc. I could not find any utility in this, and it brings numerous complications, so I have avoided it.

Patient – a kind of PersonRole, with characteristics specific to being a patient, currently just generalPractitioner. The details here can be improved, but the main thing is to see that the vast majority of FHIR’s Patient data items are now in Person, i.e. the real person who is the ‘performer’ of the Patient role. This approach allows a single real Person to be a Patient in multiple places, but only need one instance of the person data such as birthDate, maritalStatus etc. It also has the effect of properly separating data elements that arise and may disappear, due to person becoming a patient at an institution, and later leaving, from those that relate to the person as a private individual regardless of care provision relationships.

Practitioner – a kind of PersonRole with potential qualifications and ‘posts‘. The latter covers the extra attributes of the FHIR PractitionerRole Resource, which is no longer needed – simplifying quite a few Reference() attributes elsewhere.

Qualification – same as FHIR DSTU4.

Employment – the attributes from FHIR’s PractionerRole Resource that relate to the practitioner’s working relationship at Organizations. There may be better names for this Resource.

HeathcareService – a kind of OrganizationRole (i.e. Role performed by an Organization) that documents the service capabilities, availability etc – derived directly from the DSTU4 resource.

RelatedPerson – a kind of PersonRole (Role played by a Person) that has PersonalRelationships.

PersonalRelationship – a kind of PartyRelationship whose target is a Person, and having type PersonRelationshipType, e.g. ‘mother’, ‘brother’, ‘friend’, ‘guardian’ etc.

Team – a kind of Party constituted by relationships of type TeamMember, and possibly with capabilities.

TeamMember – a kind of PartyRelationship with a specific type, and coverage.

CareTeam – a kind of Team that has a subject (of care), etc.

A remaining question is: what is a ‘Device’? In the demographic sense, I believe it is meant to cover autonomous devices and/or software entities that essentially replace Practitioners for certain functions, but not measuring or prosthetic devices that cannot act as contactable Partys. I have not included Device above, but it should most likely appear as a subtype of Actor, and possibly be named AutonomousAgent, to distinguish it from the kinds of machine normally meant by the word ‘device’.

More Sophisticated Patterns

In the Party type, the relationships attribute may contain any list of PartyRelationship instances, while it has been specialised for various Party subtypes to be of just one subtype of PartyRelationship. This may be too restrictive, and a more flexible pattern, which allows instances of multiple subtypes of PartyRelationship, while also enabling the presence of some particular types to be asserted is the following (using RelatedPerson as an example):

class RelatedPerson inherit Role {
    // extract PartyRelationships of dynamic type
    // PersonalRelationship
    List<PersonalRelationship> personalRelationships() {}

    invariant
         not personalRelationships().isEmpty();
}

Can ‘Modelling’ solve Everything?

The model above might give the impression that all requirements can be met just with orthodox models. This is fundamentally untrue in at least two ways. Firstly, there is a question of variable domain level semantics versus invariant semantics. Ideally, an information model, which is what much of the FHIR Resources, is limited to the invariant types for the domain. We have done this rigorously in openEHR since 2000, and the approach we use there – complete separation of domain and information models – is achieved by a technical information model (the Reference Model), a constraint language for expressing variable domain models (the Archetype formalism), and a library of around 9,000 clinical data points represented as Archetypes (Clinical Knowledge Manager). Our 20 years’ experience there show unequivocally that trying to model everything in a single layer information model in a vastly complex domain like healthcare has no hope of success.

FHIR is less rigorous on this – the Resources include a number of highly variable clinical entities – however, it does have the capability to express a separate layer of constraint models based on the Resources, known as Profiles in FHIR.

The second reason a single universal model doesn’t solve all needs is due to the other source of variability – localisation. Local contexts generate different variant requirements in such a way that any common underlying information model needs to represent broad ‘possible’ requirements, while local constraining reduces the possibilities to those known to be relevant in a particular situation.

In openEHR this is achieved by a combination of archetype specialisation and ‘templates’, which enable use-case specific data-sets to be defined. In FHIR, Profiles can be specialised at a local level, and templating approximately achieved informally via Implementation Guides.

The basic lesson here is that no-one should expect even an ideal reworked FHIR ‘model’ to express all the requirements currently extant. Instead, the Resource level, in the form of a typed information model can express ontologically correct possibilities, with further constraints due to domain specifics and local needs expressed in, respectively, a core set of normative Profiles, and then private local Profiles based on the normative ones.

An example of where information modelling does not quite do what is needed is the following pattern that occurs throughout FHIR:

• subject: Reference (Patient | Group)

The intent here is that a subject (of care) can be an individual Patient and also a group of individuals, e.g. a family or a couple. According to the model above, there is no supertype of Patient and Group, nor even of Person and Group, and nor should there be, since the notion of ‘subject of care’ is a contextual one, not a definitional one. If the question of whether a group is really a subject of care, as opposed to its individual members who happen to receive some care in a group situation, were discussed carefully, I suspect the distinction would fall away (to my knowledge there is no such thing as a ‘group’ EHR in most systems), and we would only require subject: Reference (Patient). However, assuming the requirement remains, the solution at the Resource level is simply:

• subject: Reference (Role)

The constraining to Patient (meaning individual patient) or ‘group patient’ (for which a new Resource type would be needed) would be done in Profiles, not in the Resources. This is an example of where the information model layer has to leave a wider type than is probably intended in any particular use scenario, and it’s one of the reasons we need a constraint layer of more specific models.

Simplifications in the Rest of FHIR

With a number of new types and clearer semantics now available from the above model, we can simplify many attributes elsewhere in the FHIR Resources that are currently typed as Reference (A | B | C | …) where A, B and C are other Resource types, mostly Admin, but sometimes mixed in with Device, Substance and other non-demographic types. The following is a simple example – the annotation element that occurs in numerous Resources is defined as follows:

In the revised model, the highlighted set of choices above is just replaced with Party:

As per above, all instances of subject: Reference (Patient | Group) can be replaced with Reference (Role).

We can now consider some of the items on the patterns page, to see how they can be simplified.

CommunicationRequest.recipient: Reference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | Group | CareTeam | HealthcareService)

This can be now replaced with Reference (Party) (on the assumption that Device is modelled as described earlier). The same can be done for quite a number of other entries in the table.

Contract.term.action.performer :
Reference(RelatedPerson | Patient | Practitioner | PractitionerRole | CareTeam | Device | Substance | Organization | Location)

The definition of this is: Indicates who or what is being asked to perform (or not perform) the [a]ction. How a ‘location’ or ‘substance’ or non-autonomous device could perform actions related to a contract is unclear; I suspect there are errors here. Ignoring those, types, once again, Party can be used on its own.

Nearly all of the entries in the patterns page table can be resolved simply with Reference(Party). This greatly simplifies things for both FHIR Resource maintainers, who can now avoid lengthy debates about whether a Patient could do X, but not a RelatedPerson and so on, as well as implementers, who can benefit from orthodox typing rather than getting instances of unrelated types as per the current model.

The above model is certainly not complete, and probably not even completely correct, since there may be definitional semantics I have missed. Nevertheless, most architects, modellers and developers would recognise it as a reasonable way to model demographic semantics for the kinds of uses required by HL7.

Hopefully it can serve as a useful basis for further discussion.