As I 've said above my work does not normally include anything for which I feel a great need for a GENERIC_ENTRY class as I rarely work on ‘pure’ integrations but within that there are 2 areas that cause me grief when trying to integrate external data (or fit with a national ‘schema’ as per in Finland, which I suspect are pretty universal.
- Demographics entities which need to be carried in the EHR space. I’ll make some suggestions in a separate thread but briefly -
- PARTY_PROXY as a datatype, so that it can be added as an ELEMENT.
- other_details ‘slot’ in PARTY_PROXY allowing item_xx or cluster
- add ‘role’ to PARTY_IDENTIFIED.
These changes would go a long way to making it easier to integrate with messages and systems and where there it is not possible or practical to properly normalise/reconcile these entities into a demographics server.
- 'Observable elements. ’
There is a big push to move Observation the information around vital signs, patient wearables etc. I am seeing a lot of this being done at Element level (not exclusively via FHIR Observations) but with a similar single-element value - basically a name (often loinc-coded) , a value and a unit. We can argue that our approach of chunking these things up into Observation classes is a better long-term approach but finding a scalable solution to importing these values is difficult. We generally have no control over which data are sent. This is the exact use-case in Finland (not using FHIR but similar loinc-coded name-value pairs and UK GP systems will do something very simialr.
My immediate solution was to create physical measurements observation archetype, which is not dissimilar to the lab approach where the individual observable is expected to be coded (LOINC or SNOMED) and therefore queried that way.
This works fine for the pure integration phase but there will be a point where some systems are providing e.g properly modelled 'pule rates (using the Pulse observation archetype) whilst others are still populating the generic structure. I want to be able to query both directly via the associated code on the ‘observable’.
What needs to happen next is that we can do a CONTAINS OBSERVATION CONTAINS ELEMENT el … WHERE el/code MATCHES loinc xyz.
I appreciate that this may be tricky to make preformant but it might be possible to tag certain elements being observables, and therefore carrying codes and a target for better indexing.