This is a second instalment of a technical review of the HL7 FHIR resources. As described in the previous post, this review is the result of an element-by-element transcription of the FHIR DSTU4 resources to the openEHR BMM (Basic-meta Model) format for the purpose of model analysis and archetyping. Here I look at the Administrative domain.

One of the most surprising things about the FHIR resources is that there is no inheritance between them; the only inheritance that exists is between each resource and some generic classes, as shown below in the ADL workbench view of the transcribed FHIR resource Endpoint, which inherits from DomainResource, which in turn inherits from Resource: The Administrative domain is one in which one would expect to see normal modelling practices at work. In FHIR, there is a flat set of unrelated definitions.

Administrative entities, often known as demographic entities consist of People, Places, Organisations and similar real-world entities that need to be tracked in healthcare systems. Demographic modelling is well understood, and indeed there are many books dedicated to it (see e.g. Martin Fowler: Analysis patterns, 1996; Len Silverston: The Data Model Resource Book, 2001). However in FHIR, there is no demographic or administrative ‘model’ to speak of, just a set of unrelated resources:

The total number of classes is actually quite a bit more than in the above view which does not show subordinate components, as can be seen in this ADL Workbench view:

(NB: the view above does show some inheritance, which I inserted; see below.)

In a typical model of demographic entities, such as the example shown at the top of this post, concrete classes such as Person are descendants from abstract categories such as Actor and Party. Clearly all kinds of different types and relationships could be defined; the above really is just an example to illustrate the principle.

In the FHIR Administrative resources, there are no abstract classes or inheritance relations. But why? The reason demographic models have inheritance like that shown at the top of the post is precisely because there is commonality in reality, and abstract classes are a good way to capture it. They are particularly helpful in modelling ‘party’ entities, accountability and so on. Stranger still, is that with no changes to the Resources as they stand, significant commonality does in fact exist, and can be separated out, as shown by the following representation of the resources in the BMM form to which some inheritance and abstract classes have been added (the ones in light blue on the left):

This very rough initial refactoring does not of course account for issues such as:

• the difference between Practitioner and PractitionerRole which routinely turn up as type choices in Reference() elements;
• the fact that Organization does not have a ‘communication’ element, even though most organizations (e.g. clinics) do state means of communication;
• the fact that communication isn’t defined in the same way across Administrative resources;
• the lack of a common parent of Patient and Group, even though both are intended to be possible subjects of care.

One very obvious result of the lack of abstract classes is that demographic entities are routinely connected to other entities by the ‘Reference()’ construct, containing an ad hoc list of classes, e.g. in this extract of the Encounter resource: Here, the ‘individual’ element has the type Reference (Practitioner | PractionerRole | RelatedPerson), defined as ‘persons involved in the encounter other than the patient’. This is an attempt to limit the reference to kinds of person other than the subject, i.e. the Patient. For some reason, the list does not include the Person resource (documented as an ‘advanced’ feature), nor Group, nor other kinds of actors (e.g. a robot other other machine), and it is not clear to me at least why the particular list of 3 types is definitive. A more usual way to model this kind of thing is to use a construct like Reference (Party) or Reference (Person), where Party and Person are abstract parent classes of the other demographic types. If there is a need to then constrain the types in particular situations, this can be done as a constraint, in a separate model layer (in FHIR, a profile).

The list of types used for ReasonReference is even more ad hoc, and it’s hard to imagine it is guaranteed to be truly definitive; it would also benefit from the same kind of remodelling. The last highlighted element, destination: Reference (Location | Organization) should probably be remodelled as something like Reference (CareLocation), with CareLocation defined as a type along the following lines:

class CareLocation {
    location: Location[1];
    type: CodeableConcept; // Snomed discharge location code or similar
    organization: Organization[0..1]; // if there is a HC org
}

There is a more insidious problem with using fixed choice lists of resource names throughout the resources: it is a brittle construct. Consider that in the future, if new resources are added, and/or resources are retired, all of those lists will need to be revisited and some changed. This will almost certainly break software built on these original assumptions. Managing this will required special tools and tracking files. Indeed, Fhir has a special regex to use as a template for such references, something which will have to be continually updated.

A related, and equally insidious problem is that the ability to simply make a list of any concrete types means that resource defining committees will do so, and in some cases may assume that ‘anything goes’. However, in normal typed modelling (i.e. using inheritance and abstract classes), modellers have to think carefully about what each element actually means in order to determine its correct (single) type. If they can’t find a common type, e.g. something like ‘subject of care’, they have to do the appropriate modelling to represent it.

The brittleness problem is due to the use of a construct very like the ‘choice’ meta-type in XML schema, which is a subtractive (i.e. constraint) construct (see here), but which does not map well to OO formalisms or programming languages. I will deal with this in more detail in a following post.

A lot more could be said about the many other classes in the Adminsitrative domain, but some obvious steps could be taken to improve things, starting with a global review of these resources looking for commonalities, and which differences are real. This would allow the introduction of some abstract classes (Entity, Party etc). Next, a through re-appraisal of the use of the Reference() construct with respect to Administrative entities (not to mention all other resources). This would greatly simplify software implementations of these resources, while improving reuse, and reducing software maintenance costs. It just needs a little design.