
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 subsititutability 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)
Continue reading