Stream: implementers
Topic: Observation References Challenge
Will Jones (Mar 08 2017 at 11:44):
Hi,
First time I have posted on this group. But I have been around interoperability for over 15 years now and I am the lead on FHIR for CSC (soon to become DXC Technology when it merges with HPE at the end of the month). I am also on the curation team for InterOpen.
Today I need to take opinion and advice from the community on a challenge we have for implementation of FHIR for Lorenzo.
How are systems of record dealing with references to observations where the observation utilisation is different?
What I mean is the following challenge in diagnosticReport that references out to an observation to represent a result item. The result items are represented in a different database table to pure observations such as a blood pressure. How do we differentiate between them in an observation? Is it with the Observation.Category attribute or something else?
Then when we make a reference to an observation for example, in a Diagnostic report how is that reference constructed?
..\observation\123456
Can we qualify a reference further with say category and have it paramitised such that the reference is:
..\observation\id='123456'&category='laboratory'
(not sure we can even do this, as all references seem to be an ID)
We need to do this so we can differentiate what table in Lorenzo to go to because of the different utilisation of the observation resource. In this case to represent a result item and a standard observation.
Or do we have to respect the reference structure of referencing out to a single resource with a unique ID? We do a concatenation of id+category. Such that:
..\observation\123456laboratory
Or is there another technique or new idea from this forum that can be used?
Does this make any sense? Looking forward to your feed back and pearls of wisdom.
Lloyd McKenzie (Mar 08 2017 at 16:24):
So your issue is that observations don't have unique identifiers across tables?
Lloyd McKenzie (Mar 08 2017 at 16:25):
Concatenation would be the typical approach - though I'd probably put the prefix at the start for efficiency reasons. E.g. Observation/lab123456 vs Observation/vit123456
Grahame Grieve (Mar 09 2017 at 03:41):
the id is opaque, but must be maintained correctly. in many cases, the id is a composite key - your's would be a classic case; Observation/1-2345 where '1' refers to which table.
Last updated: Apr 12 2022 at 19:14 UTC
