Stream: implementers
Topic: Observation or extension
Jay Lyle (Jun 17 2020 at 19:23):
We have several patient attributes that could be considered observations, but which are recorded in the legacy system as as part of the patient file. They are administrative, not clinical, though they are related to clinical data (e.g., Was the veteran patient judged to have seen combat?).
In the interest of interoperability, we could expose these attributes as observations; however, they would not have ids. It would be easier to create extensions. What other criteria should we apply to this decision?
Jim Steel (Jun 17 2020 at 19:24):
Would they need to be searchable?
Jim Steel (Jun 17 2020 at 19:25):
You would get some search functions "for free" if they were in Observations that might be more intuitive than if they were in extensions?
Lloyd McKenzie (Jun 17 2020 at 19:25):
How would they be used? Could different authors have different opinions on the answer?
Jay Lyle (Jun 17 2020 at 19:26):
Searchable: Not this iteration.
Jay Lyle (Jun 17 2020 at 19:26):
Differing opinions: no.
Jay Lyle (Jun 17 2020 at 19:27):
This iteration: for pharmacists to view patient record when processing med orders.
Lloyd McKenzie (Jun 17 2020 at 19:58):
Seems like this is closer to marital status than blood type, so I'd probably go with extensions on Patient
Lee Surprenant (Jun 18 2020 at 11:52):
This one sounded familiar to me for some reason, so I went and found what I was thinking of: http://hl7.org/fhir/us/odh/StructureDefinition-odh-CombatZonePeriod.html
They use Observation for that, but I guess its a little different than your use case.
Jay Lyle (Jun 18 2020 at 11:56):
The ODH structure is independent of Patient; to use extension they'd have had to make some fundamental changes, maybe limiting its appeal. Most of the signs seem to point to extension. Thanks.
Ioana Singureanu (Jun 18 2020 at 15:49):
Hi @Jay Lyle , we've leveraged the ODH approach to create extensions similar to HL7 V2 Z-segment for Employment Service History and Status ()https://confluence.hl7.org/display/CGP/Military+Service+History+and+Status+FHIR+Profiles+Project+Page). We reused one ODH profile as a base profile and created a base/constrainable profile for Employment History Episode that leveraged the ODH pattern for PastOrPresentJob (i.e. Observation with coded components for extensibility). The approach worked for Military Service and we hope to apply it to Disability and other VA APIs that use custom REST APIs. Please joine @Craig Newman , @Sean Muir , Genny, Lori, and I on the weekly project call on Tuesdays at 11 am EST (https://zoom.us/j/98656497049 ) if you have any questions or add your comments to the Confluence page.
Military-Service-History-and-Status-Profiles-0.2.docx
Armin Griebler (Jun 23 2020 at 08:54):
Hello everyone, I have got a question about observations and extensions:
How to decide whether to use an observation or an extension for a specific value?
For example, you measure your sleep, and within your main sleep you also measure different sleep stages like light sleep, deep sleep and so on. But in addition to that I also would like to measure or at least give a value for the total main sleep efficiency. So would it be better to use a main sleep observation with an "efficiency" extension or should I use separate observations for all values that would be measured during the main sleep?
René Spronk (Jun 23 2020 at 09:09):
An observation has 'components', it looks like you could use one single Observation resource and express the various values/aspects as component values.
Armin Griebler (Jun 23 2020 at 09:50):
René Spronk said:
An observation has 'components', it looks like you could use one single Observation resource and express the various values/aspects as component values.
Thank you for your answer! A component requires the usage of a codable concept. What if there is for example no Loinc or Snomed Code for the particular value? Then, do I have to use an extension?
René Spronk (Jun 23 2020 at 09:54):
No. You just use a code from a different coding system (if that's allowed by whatever implementation guide(s), if any, that you're trying to adhere to). If you're not using an implementation guide you can use any coding system you want, even if it's your own coding system.
Lloyd McKenzie (Jun 23 2020 at 14:36):
If you're capturing information about something observed or qualifying something observed, it'll be either an Observation.value or an Observation.component.value if it doesn't obviously fit in one of the existing Observation elements (e.g. method). Extensions on Observation would be for other purposes (e.g. data enterer, relationship to research study, etc.)
Daniel Vreeman (Jun 24 2020 at 01:42):
Side note...just because there isn't (yet) a code for the measurement concept in a standard terminology like LOINC doesn't mean there shouldn't be. Terminologies extend their coverage based on user requests. If this is a measurement from a wearable sensor, for example, I'd recommend making a submission for new concepts to LOINC: https://loinc.org/submissions/
Jay Lyle (Aug 07 2020 at 22:25):
FYI, we went with Observation to align with ODH. It's semantically a little different but close enough that leverage seemed like the best path.
Last updated: Apr 12 2022 at 19:14 UTC
