As part of my work with the US VA, I have done an analysis of the HL7 FHIR ‘choice’ construct - choice is the little ‘[x]’ you see in a FHIR resource where there is a choice of data types (example: look for onset in AllergyIntolerance). There are various problems with choice in general (my discussion of this), and one of them is that different groups in HL7 create very similar but not identical lists of type choices, for what is probably the same semantic intent.
Anyway, my interest here is to look at one of the types of data element that creates a lot of choice structures in FHIR - timing. Now, timing is actually hard, and we don’t model it right in openEHR either, as we are discovering in Task Planning.
I have done some modelling in Task Planning to cover some of the timing semantics we need, but the above FHIR analysis was a catalyst for looking more closely at how to model various categories of time representation. You will see some UML diagrams at that link above for these.
I would like to propose a conversation on ‘modelling time’ and deriving a better solution that:
- includes some reference model level support;
- makes it clearer what would still need to be in archetypes;
- gets closer to a recommendation for HL7 on how to fix this bit of FHIR.
My current view is that there are the following categories of ‘timing’:
- Single specific point or interval in time of an event or state
- When an event occurred (past) - characterising multiple ‘occurrences’ / pattern of occurrence
- Age at which an event occurred (past)
- Scheduled time (future) - e.g. for orders, etc