Stream: implementers
Topic: Extension for raw data
Mikael Rinnetmäki (Feb 26 2019 at 08:06):
I'm modeling a mechanism for storing the raw data captured by a device into an observation. The use case is that all the essential information is to be described in the Observation itself according to suitable profiles, but in addition to the widely relevant data we'd like also to store the raw data, as it contains data that only very specialized software may be interested in. There may be many details in the raw data describing how the data was captured, details of the device or the environment it was used in, etc., and we just don't feel describing all of that in well described FHIR profiles is worth the effort at this time. So we'd like to just store the raw data and allow software that's able to parse it to work with it, and think of perhaps extending the profiles to cover more of that data in the future. But for now, just storing the raw data with the Observation seems sensible.
Currently an extension to the Observation seems the most logical solution for this.
I then thought that surely this is not the first case where something like this has come up, and tried to search the internet (Zulip, Simplifier, Google, ...) for extensions for raw data, or original data. I wasn't able to find any. Am I just missing the correct term that's being used for "raw data"?
Jens Villadsen (Feb 26 2019 at 08:07):
@Jacob Andersen - aint that your turf?
Jacob Andersen (Feb 26 2019 at 13:36):
Not really. My approach (more or less successful so far) has been to try to model even the specialized details as either related Observations or Observation components in a meaningful way. In the cases I have been involved in, this included a data model based on the IEEE 11073-20601 Domain Information Model (possibly with user-defined MDC codes when no relevant MDC code already existed) and a Personal Health Device FHIR IG-based mapping (http://hl7.org/fhir/uv/phd/ ) to FHIR.
But if the raw data is only intended for a single recipient (specialized software), it may not make sense to do all this work. In that case and extension would probably be a better match.
Lloyd McKenzie (Feb 26 2019 at 15:08):
How big is the raw data likely to be?
Eric Haas (Feb 26 2019 at 15:12):
this sounds like a DocumentReference and pointed to from the derivedFrom element.
Eric Haas (Feb 26 2019 at 15:14):
docref as a container for binary data. I am assuming this raw data is not the observation itself. If it is then I’ll like to know more about the use case since we are mulling over bringing back a valueAttachment element to capture binary as the observation value
Mikael Rinnetmäki (Feb 26 2019 at 16:04):
@Lloyd McKenzie typically a simple JSON object with 2-10 fields.
Mikael Rinnetmäki (Feb 26 2019 at 16:16):
@Eric Haas the data is the Observation itself. For instance a measurement from a Continuous Glucose Monitor:
{
"_id": "5c690e9755418687ac3bbd2a",
"device": "xDrip-LimiTTer",
"date": 1550388885861,
"dateString": "2019-02-17T09:34:45.861+0200",
"sgv": 97,
"delta": -3.347,
"direction": "Flat",
"type": "sgv",
"filtered": 119999.991,
"unfiltered": 119999.991,
"rssi": 100,
"noise": 1,
"sysTime": "2019-02-17T09:34:45.861+0200"
}
or even a MedicationAdministration entry from a bolus calculator or an automated insulin delivery system:
{
"_id": "5c53461681556a386830f067",
"eventType": "Temp Basal",
"duration": 15,
"percent": 10,
"rate": 0.715,
"created_at": "2019-01-31T19:01:42Z",
"enteredBy": "openaps://AndroidAPS",
"NSCLIENT_ID": 1548961302122,
"carbs": null,
"insulin": null
}
But the point is that we want to capture the relevant data as FHIR, for instance in the valueQuantity for the observation. But in addition to that, store the original raw data to parties that are interested in it. So I wouldn't be storing that CGM data as the valueAttachment. I could consider storing it as a DocumentReference.
Eric Haas (Feb 26 2019 at 17:25):
It sounds to me that what you are describing is the observation is derivedFrom the raw data so capturing as binary using DocRef and link to Observation using the derivedFrom element is what I recommend
Last updated: Apr 12 2022 at 19:14 UTC
