Stream: implementers
Topic: The subject of an Observation
Mark Kramer (Nov 30 2017 at 00:41):
The subject of an observation is ref(Patient|Group|Device|Location). This seems relatively arbitrary. For example, if there is a need for Observations about Locations, then why not Observations about Organizations? If we have the need for Observations about Devices, why not Observations about Specimens? In my view, you can't do many types of useful observations: observations about medication treatment, observations about conditions, observations about behaviors, observations about encounters. Why not an Observation about a Procedure? In summary: why is Observation.subject not broader? Why not ref(Any)?
Grahame Grieve (Nov 30 2017 at 01:37):
technically, in RIM terms, Observation is an act, and subject is a participation. Acts cannot participate in an act. It would be possible to say that an observation can be about any role, though we haven't created the machinery for that (and most implementers would find RIM-speak jarring in this regard, if it surfaced to them). But OO would have to decide about whether that was a value proposition or not
Eric Haas (Nov 30 2017 at 01:45):
I won't pretend to understand " Acts cannot participate in an act. It would be possible to say that an observation can be about any role" which on the surface sounds contradictory. But I am concerned about greatly expanding the scope of Observation in lieu of some other existing (Clinical Impression) or new resource (Clinical notes).
Lloyd McKenzie (Nov 30 2017 at 01:49):
Actually, in RIM terms it's possible to have a "subject" ActRelationship - so you can indeed have Observations that describe other Acts. It's quite common in fact.
Lloyd McKenzie (Nov 30 2017 at 01:50):
I actually share Mark's concern - I think it's possible to make Observations about absolutely anything and I've never really understood the point of constraining the subject to such a limited set.
Eric Haas (Nov 30 2017 at 01:52):
I need to be convinced because I can't think of any examples. An impression about an encounter as an observation. The encounter has a subject why not use that?
Grahame Grieve (Nov 30 2017 at 01:53):
" in RIM terms it's possible to have a "subject" ActRelationship " - indeed, but subjecti presently defined as a participation.
Eric Haas (Nov 30 2017 at 01:54):
Condition is a kind of observation and we struggle with those boundaries so use condition.
Lloyd McKenzie (Nov 30 2017 at 01:56):
Grahame, I don't think we drive what's allowed vs. not by RIM mappings - we figure out what we want Observation to do and update the RIM mappings accordingly. Observations can be made about Organizations - e.g. hiring statistics, training statistics, etc. You can have statistics about pretty much anything imaginable. Even Accounts.
Eric Haas (Nov 30 2017 at 02:00):
I can accept those as valid examples but the tendency to use Observation for everything is at the doorstep. ie "this Condition is grade x."
Mark Kramer (Nov 30 2017 at 20:18):
I consider the RIM argument spurious and agree with Lloyd that you can make Observations about almost anything. I arrived at this need not in theory but from concrete examples in the oncology domain where I need to make observations about the safety and effectiveness of specific drug treatments, as well as observations about the progression of the disease. There are also observations about the various tumors (which are literally observations about a specific tumor, not observations about a body site). I'm kind of against introducing ClinicalImpression into the mix if that makes it more difficult to navigate the gray area between Observation, Condition, and Clinical Impression. Subject: Reference(Any) is my recommendation.
Lloyd McKenzie (Nov 30 2017 at 20:22):
Right. So the question is how do you allow Observations about everything while still making sure that they're true Observations, not data elements that should be sent as properties or extensions on the subject.
Lloyd McKenzie (Nov 30 2017 at 20:22):
I'd say the general rule is that it's data you wouldn't typically expect to see when looking at the subject resource and that wouldn't be maintained as part of maintaining the subject resource.
Eric Haas (Nov 30 2017 at 20:54):
-
The observation about the tumor is attached to a patient? besides the bodyStructure is not just a location anymore and can be about a specific tumor is referenced by Observation.
-
Observations about the progression of the disease = sound like clinical note check with Patient Care on that one.
-
Safety and effectiveness of specific drug treatments = ? is it a grade or like described above. Check in with Pharmacy on this use case. I suspect a patient or group of patients are involved here.
-
Stats on a hospital or organization sounds more administrative measures than clinical measurements and maybe a profile could be carved out for that. I'
Mark Kramer (Nov 30 2017 at 22:38):
@Eric Haas how do you persist a bodyStructure ? I want to refer to the same structure at different times (not just the same bodySite).
Lloyd McKenzie (Dec 01 2017 at 03:59):
BodySite resource
Mark Kramer (Dec 01 2017 at 17:36):
Ah, it has be promoted to a resource. I think I already knew that.
Travis Stenerson (Dec 04 2017 at 15:11):
So three of the mentioned Observations are the same classes of concepts I have had the most trouble with FHIR representation for.
Observations on the tumor - I'm now using the BodySite/Struct resource for this, which I think is a pretty good solution.
Disease progression: feels a lot like an overall interpretation of a set of Observations and methods of observation. I was looking at the RECIST criteria recently and ClinicalImpression came to mind above all other clinical resources. But I felt like the 'prognosis' attribute didn't really fit what was being done. It's not a prognosis I want but an overall interpretation of these observations. I wondered why this element wasn't called "impression".
My representation of disease progression is an Observation, referencing the disease with event-reasonReference, and using the valueCodeable field to hold the 'CR/PR/SD' response values. Not an ideal representation.
'Safety and effectiveness of a particular drug of treatment' I found tricky in two ways. One in the 'did happen' sense, the other in the 'what will happen' sense. On the did-happen side was "Endocrine refractory status of disease" following a particular treatment regimen. Again I used Observation with a code like 'drug resistance status' and a value of 'hormone resistant/responsive cancer'. Is this an observation? Again it feels like a clinical judgement call.
In the what-will-happen side, the most common one is 'tumor operability' or 'definitive therapy possible'. Again, we're using Observation but it didn't quite feel right. What resource would best represent a surgeon's presurgical evaluation in which the surgeon says "I think I will be able to excise this thing via this operation'? My issue with ClinicalImpression here is that technically the surgery request resource wouldn't exist yet, so I can't encode the type of procedure that the impression would be about (ie lumpectomy). (if the request existed, I could reference it with action)
Lloyd McKenzie (Dec 04 2017 at 15:52):
@Michelle (Moseman) Miller ?
Eric Haas (Dec 05 2017 at 03:41):
I agree those are more A's than O's in SOAP. You can put anything into an observation with an appropriate name value pair. But, at least during my tenure, Observation was not scoped to address these kinds of use cases. But I would like to know how most systems are currently handling this and hope to see more work on the Assessment resource (aka poorly named ClinicalImpression) to hammer this out.
Last updated: Apr 12 2022 at 19:14 UTC
