Stream: implementers
Topic: Related Observations
Simone Heckmann (Mar 08 2016 at 14:27):
How do I express two Observations of which one is the reason or the manifestation of the other. e.g. pneumonia brought on by HIV, retinopatia due to diabetes, rash as manifestation of syphilis etc.
Josh Mandel (Mar 08 2016 at 14:42):
The closest thing I see is Observation.related with type sequel-to
Simone Heckmann (Mar 08 2016 at 14:55):
Sounds a bit far fetched to me. What was the rationale of dropping the V3 codes reason-of and manifestation-of?
Josh Mandel (Mar 08 2016 at 15:04):
I don't see much relevant discussion with this gforge search (requires sign-in to gforge), and it looks like this valueset has been stable since DSTU1.
Lloyd McKenzie (Mar 08 2016 at 15:39):
I'm surprised there's no "reason" on Observation the way there is on many other resources, but it could be they felt it wasn't in the 80%. Reasonable to at least request a standard extension
Grahame Grieve (Mar 08 2016 at 19:00):
This sounds like a condition, not an observation. and you'll find this on condition
Simone Heckmann (Mar 08 2016 at 21:52):
Right, it's a Condition not an Observation. But still: How do I express "Pneumonia brought on by AIDS" with Conditions?
Grahame Grieve (Mar 08 2016 at 22:11):
oh. it used to have relatedItem property. see http://hl7.org/fhir/DSTU1/condition.html. I presume the idea is to use linkage. http://hl7-fhir.github.io/linkage.html but it doesn't have the right types. maybe @Lloyd McKenzie can comment from a PC perspective
Lloyd McKenzie (Mar 08 2016 at 22:20):
relatedItem got moved to a set of extensions. This one is now http://www.hl7.org/fhir/extension-condition-dueto.html
Lloyd McKenzie (Mar 08 2016 at 22:21):
Linkage is about equivalence of resources
Simone Heckmann (Mar 08 2016 at 22:22):
Ah, ok. Now I get it :) Thanks!
Stefan Lang (Mar 10 2016 at 13:21):
@Lloyd McKenzie Since you are talking about a set of extensions I assume that "dueTo" corresponds directly to the reason. Is there also an extension that expresses "manifestation of"?
Stefan Lang (Mar 10 2016 at 13:24):
Or rather, is there an overview of that set of extensions somewhere?
Stefan Lang (Mar 10 2016 at 16:30):
We have an ongoing discussion here in Germany about Simone's initial question and the implications that follow. Basically there are the following questions that have come up:
Stefan Lang (Mar 10 2016 at 16:31):
A) How do we express all of the relationships that are possible in V3 (http://art-decor.org/art-decor/decor-valuesets--ad2bbr-?id=2.16.840.1.113883.1.11.19447)
Stefan Lang (Mar 10 2016 at 16:32):
B) How does Condition.evidence fit in here?
Stefan Lang (Mar 10 2016 at 16:33):
C) Why are relations defined as extensions rather than keeping or improving relatedItem from DSTU1?
Grahame Grieve (Mar 10 2016 at 19:51):
in what context do you want to express all the act relationships? What's the actual problem?
Grahame Grieve (Mar 10 2016 at 19:52):
evidence is why you think the patient has a the condition - not why they have the condition
Grahame Grieve (Mar 10 2016 at 19:53):
I don't know why they were made into extensions. Typically that means no one was using them. and there were definitional problems with them, so we removed them until further input from implementers arose.
Lloyd McKenzie (Mar 10 2016 at 23:32):
@Stefan Lang The current list is here: http://hl7-fhir.github.io/condition-extensions.html. Manifestation isn't covered yet.
Lloyd McKenzie (Mar 10 2016 at 23:33):
Ditching related item was due to a couple of considerations: Having a name/value pair was essentially duplicating what the extension mechanism already does and it also wasn't clear that most systems support asserting these sorts of relationships.
Grahame Grieve (Mar 10 2016 at 23:48):
"duplicating what the extension mechanism" - except with constrained semantics. That's a pretty big deal as compared to extensions
Lloyd McKenzie (Mar 11 2016 at 05:10):
Defined extensions have constrained semantics too. The reality was there were a wide number of possible relationships that could be supported. Few if any were common. Conformance options are much more easily defined for explicit elements (i.e. extensions) than they are for vocabulary (relationship types). So it seemed cleaner to just use an explicit extension for each desired type of relationship - and it wasn't significantly different in terms of instance size.
Stephen Royce (Mar 11 2016 at 05:15):
Isn't a receiving system allowed to ignore extensions whereas an explicit element not so?
Lloyd McKenzie (Mar 11 2016 at 05:16):
Receiving systems are allowed to ignore anything - core or extension
Lloyd McKenzie (Mar 11 2016 at 05:17):
We just expect fewer systems to ignore core things, on the grounds that ~80%+ of systems presumably support the core elements and some lesser number of systems support extensions
Josh Mandel (Mar 11 2016 at 05:17):
Keeping in mind that core elements (like extensions) can be isModifier
Josh Mandel (Mar 11 2016 at 05:17):
Those presumably need understanding
Stephen Royce (Mar 11 2016 at 05:18):
Okay, I thought that might be the case. What I meant was really that a receiving system is more likely to ignore extensions and isn't there an associated clinical risk with something like this?
Stephen Royce (Mar 11 2016 at 05:18):
Oh right. That would cover it.
Simone Heckmann (Mar 11 2016 at 06:49):
What I gather from the discussion in the german user group is that there's a requirement to express at least relationships such as "manifestation of", "reason of" and "evidence of". A Condition.related attribute with a type-code and a reference could cover all of these cases and would at the same time be perfectly aligned with Observation.related.
Stefan Lang (Mar 11 2016 at 07:45):
I agree with Simone. When an observation can be related in the base standard, why can't a condition be?
Stefan Lang (Mar 11 2016 at 07:48):
Also I don't see the advantage in defining a set of extensions while a "related" mechanism already exists elsewhere in the base standard
Lloyd McKenzie (Mar 11 2016 at 14:53):
There is certainly inconsistency between Condition and Observation, so raising a change request asking both work groups to harmonize approaches would certainly be in order.
Ewout Kramer (Mar 14 2016 at 09:21):
I just looked at "condition-outcome", it seems to point "forward" in time, so the older condition is referencing a newer resource. Isn't that against the design principle that resources point backwards in time (so, no need to change historical data to make this reference work)?
Lloyd McKenzie (Mar 14 2016 at 11:53):
In this case, it makes sense the update would be to the Condition though. It's an assessment made against the Condition.
Simone Heckmann (May 08 2016 at 16:10):
@Lloyd McKenzie : Is there going to be a discussion about this topic at the WGM? If so: when & where?
Lloyd McKenzie (May 08 2016 at 16:25):
I'm not sure. @Eric Haas @Rob Hausam do you know?
Rob Hausam (May 08 2016 at 16:31):
I'm thinking the answer is probably yes - but Eric will probably know which session(s) it may be scheduled for. And if it's not on the agenda anywhere, we can look at finding a time for it.
Eric Haas (May 08 2016 at 17:56):
the answer is no - it was not on our agenda. Would be best to put on the pc -oo joint. @Michelle M Miller @Riki Merrick when are those? I am in favor of the inline approach like in Condition. flattening makes it easier to understand. But this is structural pattern question that touches all resources so need to address this at a couple of levels. So would be nice to know where to start. PC-OO or FHIR-I.
Michelle (Moseman) Miller (May 08 2016 at 20:19):
I don't see an existing agenda topic for this topic, but here are a few quarters with PC/OO together...including notes about what topic was on the agenda:
- Mon Q3/Q4 -- workflow
- Tues Q2 -- Health Concern -- might include Observation/Condition boundaries
- Tues Q4 -- negation
- Wed Q3 -- adverse events & care plan/order sets
Eric Haas (May 09 2016 at 14:18):
sigh.... "Observation/Condition boundaries" This is a well worn path. What tracker is that?
Simone Heckmann (May 09 2016 at 14:23):
Hi, I haven't created a tracker item yet, since we don't know yet, what to propose... ;-)
Simone Heckmann (May 09 2016 at 14:24):
But I can create an item to request the alignment of Observation and Condition...
Eric Haas (May 09 2016 at 14:30):
Spoke with Lloyd re related issue and seems to be MNM topic for the actual guidelines on structural approach. So lets touch on this topic before creating a tracker. i won't be around Tue Q4 . Wed Q3?
Eric Haas (May 09 2016 at 14:32):
@Simone Heckmann I not opposed to a tracker just want to gather any other options or opinions to add to the tracker
Simone Heckmann (May 09 2016 at 14:34):
Here's the item:
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9970
Simone Heckmann (May 09 2016 at 14:48):
Please note that there has been another zulip discussion around this right here:
https://chat.fhir.org/#narrow/stream/implementers/topic/Related.20Observations.2FConditions
Michelle (Moseman) Miller (May 09 2016 at 18:25):
There was an existing gForge that started the condition/observation boundaries discussion, per http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=8872.
This also had a PC/OO/FHIR listserv discussion as well: http://lists.hl7.org/read/messages?id=290763
Simone Heckmann (May 09 2016 at 19:11):
Hi, just to prevent misunderstandings: the issue we raised is about how a Condition relates to another Condition (e.g. "Pneumonia due to HIV" or "Retinopathia due to DIabetes") and that these references should be structurally aligned with the way Observations reference other Observations.
I guess the "boundaries"-Discussion is something different altogether, if I understand that right.
Simone Heckmann (May 09 2016 at 19:13):
The "Boundaries" discussion is about "do I use Condition or Observation to record X ?" ...right?
Michelle (Moseman) Miller (May 09 2016 at 19:47):
Correct, the condition/observation boundaries gForge 8872 is about when to use condition or observation, which was mentioned in this discussion thread, but not a duplicate of your newly logged gForge 9970 (thanks for the clarity). I would still conclude that this might still be discussed during the PC/OO Health Concern topic as Linkage is part of the Tues Q2 agenda. While Linkage is currently scoped to link the same type of resources (e.g. linking one condition to another condition), I question whether Health Concern will expand Linkage scope to include linking condition and observation (since both could be considered observations...hence, the debate over the boundaries)
Eric Haas (Aug 21 2017 at 01:47):
Resurrecting this chat stream to discuss GF#10118 which we have discussed and deferred a couple of times.
Would like to know if implementers are using the type codes
- replaces
- qualified-by
-
interfered-by
or -
ignoring the type code altogether (if this is the case, what do you mean by the related reference?)
Mounika (Sep 06 2017 at 11:23):
Hi all, I am creating a profile AlcoholUse using Observation resource. In alcohol use profile we have group of observations. I want to add them in Observation.related element. Shall I slice the related element or just add all the profiles in related element. Thank you
Lloyd McKenzie (Sep 06 2017 at 13:12):
If you slice, you'll be slicing by profile. Slicing gives you control of how many of each profile you get. Just listing the profiles will say "anything that looks like any of these". It would also prevent anything else from being present, which may be too restrictive. So slicing is probably best.
Mounika (Sep 07 2017 at 05:58):
Thank you @Lloyd McKenzie
Bret H (Oct 31 2017 at 15:54):
What happens to the slices compared to the enumerated related observations? That is, if a server only supports Observation would the server be able to 'understand' the related observations or slices? or would both be ignored?
Lloyd McKenzie (Nov 01 2017 at 02:57):
Slices are mechanisms for validating - they have no effect on the interpretation of instances. If a server supports Observation and understands Observation.related, then it will understand instances that have that property filled in
Last updated: Apr 12 2022 at 19:14 UTC
