Stream: implementers
Topic: Related Observations/Conditions
Simone Heckmann (Apr 07 2016 at 09:08):
We (the german fhir user group) are about to enter a change request affecting the Observation and Condition resource.
Our proposal aims to
# Harmonize the way Observations and Conditions express relationships to other resources
# Offer an extensible ValuSet of relationship types, that may not all be in the 80% but cover a range of relationships that occur in realms such as cancer registries (It should be up to the int. community to decide which types are in the 80%)
# offer mechanisms that - in the spirit of extensible ValueSets - cover most people's use cases, but can also be extended to cover an even wider spectrum without fringing out into different extensions, that are all identical in shape (or, at least, should be!) but differ in semantic nouances.
Here's the full text of our proposal: http://wiki.hl7.de/index.php?title=FHIR-Kritzelblock_CRQ_Verlinkte_Diagnosen
Before we submit to GForge, we'd like to hear a couple of opinions from the community.
Pascal Pfiffner (Apr 07 2016 at 09:22):
I'm not currently working on these issues so have little of substance to contribute. But I want to throw in another type of relationship that we've used in a pilot project (currently on hold) that might become more important in the future:
We have a Condition expressing a cancer diagnosis, and 1 or more Observation resources that describe gene expressions in samples of said cancer. We're using a http://.../gene-expression-in modifierExtension on the _Observation_ in this case. Short of not having a proposed code, the proposal looks like it could support such a relationship, except maybe for the timing restriction.
Lloyd McKenzie (Apr 07 2016 at 16:00):
We had evaluated the notion of generic relationship + vocabulary for Condition relationships - in fact, we started out with that. However, we decided that it didn't really offer significantly different behavior (or act much lighter weight) than just using specific extensions. And extensions give you easier control when profiling and are more easily discoverable than people creating custom relationship types.
Simone Heckmann (Apr 07 2016 at 18:50):
What was the rationale to keep the generic approach in Observations?
Eric Haas (Apr 07 2016 at 19:30):
It looks like the proposal only would change the way Condition relates to other resources. We never discussed an alternative approach. OO vs PC thing and I'm usually on the PC call but don't remember that. Additionally the type list is really contextual to what is being referenced. In fact you would need a matrix of resource and type if you referenced more than single resource
Eric Haas (Apr 07 2016 at 19:32):
(deleted)
Lloyd McKenzie (Apr 07 2016 at 21:05):
@Simone Heckmann Different group of people responsible for the resource - so there was no discussion from an OO perspective. As well, I suspect the 80% evaluation would have been a bit different. Certainly "component" would fall within the 80% for Observation.
Stefan Lang (Apr 08 2016 at 11:15):
If there is consense that at least some types of relations (like the mentioned "component" or Condition.evidence) are within the 80% and as such part of the base standard, I would consider it highly inconsistent to force other types of relations into extensions.
From an implementer's view, this would mean two completely different representations of the same technical mechanism ("X is related to Y") while the difference is only in semantics.
Lloyd McKenzie (Apr 08 2016 at 13:31):
Not really. Some relationships would have a specific name - e.g. "component" or "fulfills" and be part of core. Others would be extensions instead. That's no different than how we treat "subject" or "author" as opposed to "data enterer" or "supervisor". Having coded relationships is a little odd in FHIR. We needed to do it in v3 because we needed to allow for everything. With FHIR, it only really makes sense when you've got a structure more complex than"code + relationship"
Stefan Lang (Apr 08 2016 at 15:01):
I see the point.
Following the paradigma of not coding relationship types it would be more appropriate to propose new elements (e.g. "causedBy" or "manifestationOf"), followed by an evaluation whether they are in the 80%, right?
Has that evaluation been done earlier, especially for equivalents of V3 CAUS, MFST and SPRT?
To refine Simone's question: what was the rationale to keep Observation.related, given the above paradigma is global for FHIR?
Correct me if I'm wrong, but shouldn't that better be transformed into a set of separate elements and/or extensions then?
Lloyd McKenzie (Apr 08 2016 at 18:01):
@Stefan Lang I don't think there is a "global paradigm" for FHIR yet. There was an assertion in a change request (which I think I might have originated) that was discussed and agreed within the Patient Care work group but which didn't propagate to Orders & Observations. I think it's probably a good idea to have a policy here and would welcome a change request pointing out the inconsistency (and perhaps identifying other places where this appears). I'd also welcome viewpoints here as to whether there's agreement on aiming for distinct relationship elements (and extensions) vs. having generic (and potentially extensible) coded relationship types.
Eric Haas (Apr 09 2016 at 07:31):
I agree with Lloyd.
Stefan Lang (Apr 09 2016 at 09:47):
I think that's exactly why we put the current state of the proposal for discussion here.
It already contains the intention to clean up the inconsistency and (naturally) chose one of the existing ways to add the type of relations we are currently missing. If it turns out that the "distinct elements" variant is the way to go, it would be pointless to propose the "generic" variant.
Stefan Lang (Apr 09 2016 at 11:41):
I just did a quick check for further inconsistencies. Except for Observation.related, every other relation I found within the clinical context uses distinct elements.
The generic way is more common when it comes to roles, as with Contract.agent, Contract.signer, AuditEvent.agent, Appointment.participant and AppointmentResponse. These might be out of the scope of the proposal but worth a review.
A different type of inconsistency seems to be Immunization.reaction, which points forward in time while I remember someone (I believe it was @Lloyd McKenzie ) stating that relations should always point to the past.
Lloyd McKenzie (Apr 09 2016 at 14:44):
Roles tend to be more open-ended and larger in terms of the allowed values. There's a lot less need for interoperability there. So I think I'm comfortable with a difference in how we model things. Immunization does indeed violate the guideline. However, industry convention is to update the Immunization record with an explicit link. And in this case, you can think of the reference as a "potential causality" assertion - which would logically happen after the existence of the reaction was recorded. We might raise the question with the PHER group, but unless there's significant pushback from the implementer community, I'm comfortable with it as it is.
Eric Haas (Apr 09 2016 at 17:12):
Funny thing about Immunization it is a hybrid of Immunization and ImmunizationStatement so it could be referring to something that has already occurred.
Eric Haas (Apr 09 2016 at 17:15):
I would not be inclined to reverse that reference.
Grahame Grieve (Apr 11 2016 at 05:12):
Observation related observations are a tricky beast. You absolutely need component and panel (member). I don't have a strong feeling for the others
Eric Haas (Apr 11 2016 at 06:23):
...Then the others could be extensions.
Last updated: Apr 12 2022 at 19:14 UTC
