Stream: implementers
Topic: Proposal to make Observation Subject Reference(any)
Eric Haas (Feb 13 2018 at 18:30):
In the Orders and Observation workgroup we have been discussing several related tracker proposals to expand the Observation.subject type to Reference(any). It is currently limited to Patient, Location, Device,Group. This would represents a significant change in the Obervation's scope. For example, it would allow an Observation about another Observation, Condition, MedicationAdministration - i.e. an interpretation or evaluation or assessment. The Obvious benefit would be to allow greater flexibility to represent Observations to just about anything. The obvious pitfall with this change would be potential for overlapping scope with many other resources. We are seeking feedback from implementers on:
- General support or opposition for this proposal
- Whether this change would align with their system's structure. I.e., Is there separation between observations on patients and observations about other things like other observations or are these treated separately since, from a clinical perspective, they can be considered a observation vs an interpretation/evaluation/assessment?
Eric Haas (Feb 13 2018 at 18:36):
See trackers GF#14863, GF#15262, GF#14443
Lloyd McKenzie (Feb 13 2018 at 19:25):
Examples include making an Observation about a variant (which is an Observation) to indicate if the variant is considered to be benign or pathogenic; Capturing observations (e.g. statistics) about Practitioners, Organizations, etc. If the decision is to not use Observation for this, how would systems capture this sort of information?
Travis Stenerson (Feb 13 2018 at 23:26):
I am working with oncology guidelines and I have run into a few observations would require this sort of reference if I want to be able to interpret the Observation without following a reference graph or pre-coordinating a concept. Some examples are:
- 'Response to treatment of a target or non-target lesion' and other tumor-focused observations. To specify the lesion I have used 'bodyStructure-instance' or 'body-site instance' extensions. There are also many 'observation' like data elements in these guidelines that say 'Progressive disease' or 'stable disease', which are more like a subjective clinical assessment/impression than a strict question-answer observation. However if I could focus the observation on the Condition, than Observation fits these cases.
- TNM-Staging. These are point in time assessments of disease stage, so I have used 'event-reasonReference' to reference the cancer condition. They come from a number of other Observations(tumor size, lymph nodes involved, etc). So they are sort of like an assessment however clinical impression doesn't quite fit the individual components of T, N and M.
Allowing a different Observation focus would fit these oncology use cases well. But I see some crossover with the official extensions to BodyStructure as well as the specimen field, which would be the focus for observations on tumors that have already been excised. If it is the subject field that is altered, would that mean that the patient with the disease being observed could only be determined by following the reference Observation -> Condition -> Patient?
The main oncology specific use case that was discussed a bit at the connectathon was TNM staging. An Assessment type resource, maybe ClinicalImpression with changes, could potentially address this. This change would make it a lot easier to put these types of data elements into FHIR, though I'm not certain the qualify as Observations.
I'm in support of the change unless guidance can be provided for these 'Observations'
Heres a quick example of what goes into TNM staging:
- Lung imaging shows 4 cm lung tumor in the left lung apex. Tumor has extended to the vertebral body. These observations lead to a T category
- Bronchoscopic biopsy of the left mediastinal lymph nodes was positive for malignancy. This observation leads to an N category
- No clinical evidence of disease outside the thorax on imaging or exam. -> M category.
- The medical oncologist in charge asserts that this is a T4N2M0 disease by the AJCC 7th edition staging system. This corresponds to Stage IIIB. I feel like an Observation with code: T-category and value T4 can't really be understood without knowing the cancer that it is talking about.
Eric Haas (Feb 13 2018 at 23:32):
"I'm in support of the change unless guidance can be provided for these 'Observations'"
it sounds like you are not in support. can you clarify is this a typo?
Travis Stenerson (Feb 14 2018 at 00:45):
This change would make it easier to put these Observations that are about the patient's condition in FHIR, and so I support it.
However, maybe a Condition isn't observed, but assessed, and there is a better resource for this type of data element.
Bob Milius (Feb 14 2018 at 18:30):
I'm in favor of this. It would for example, allow an Observation about a BiologicallyDerivedProduct
Mark Kramer (Feb 14 2018 at 19:00):
I made originated this suggestion and also had a ballot comment about this. After some case studies, I believe the proposed solution of changing Observation.subject to ref(Any) might not be the best approach. I believe two attributes are needed. I believe in most cases, Subject should be the Patient. This is who the observation is associated with. We shouldn't lose this information or make it harder to find. Instead, I suggest adding a new optional attribute representing the "focus" of the observation. As discussed above, this can be something more specific than the entire patient, such as a condition of the patient, the patient's environment, diet, or behavior, or intervention. Currently, we have a special case where BodySite can act as the focus of an observation in the sense described here. Another special case is when the subject is a device, where the Subject is replaced by the device, and then then patient associated with the observation can only be determined by referring to the patient in the device resource. It would be more consistent if the Subject were typically the patient, and then the focus could identify specifically what the observation was about, which could be reference(Any) -- a body site, device, condition, allergy, location, environment, intervention, encounter, behavior, etc. The option that the Subject could be an implanted Device would also be removed replaced by the "focus" attribute.
Grahame Grieve (Feb 14 2018 at 19:02):
we already have an extension for this then?
Grahame Grieve (Feb 14 2018 at 19:02):
I personally think it should be core - it has a variety of use cases. The challenge is probably that it doesn't really exist in v2 or CDA, so it's not really common
Eric Haas (Feb 14 2018 at 21:25):
Still have not heard from systems harboring all this data....
Elliot Silver (Feb 15 2018 at 12:56):
If an observation can be about anything, does that mean we need to rethink basedOn, context , performer, partOf, derivedFrom, etc.?
Eric Haas (Feb 15 2018 at 17:25):
@Elliot Silver i.e., start from scratch
Lloyd McKenzie (Feb 15 2018 at 17:49):
I don't see why any of those attributes would change. They still mean the same thing regardless of what the focus of the Observation is.
Eric Haas (Feb 16 2018 at 18:16):
So in this chat. I'v seen a lot interest in adding an accelerator but no mention of how to put the brakes on. Whether on subject or focal subject Reference(any) would still create a hammer for every nail. If we went this way, I think we need to rewrite the scope and boundaries of Observation to reflect the fact that Observations can be made about anything. And I think no matter what guidance we provide like "if an element exists in a Resource X use that instead" that folks will use a series of Observations instead. Nothing in this chat has persuaded me otherwise
Lloyd McKenzie (Feb 16 2018 at 18:23):
I'd include the following language:
At its core, Observation allows expressing a name-value pair or structured collection of name-value pairs. As such, it can support conveying any type of information desired. However, that is not its intent. Observation is intended for capturing measurements and subjective point-in-time assessments. It is not intended to be used to capture information that is designed to be captured by other resources (e.g. allergies, procedures, care plans, etc.). There will however be situations of overlap. For example, a response to a question of "have you ever taken illicit drugs" could in principle be represented using MedicationStatement, but most systems would treat such an assertion as an Observation. Adhering to such convention is an appropriate use of Observation. If implementers are uncertain whether a proposed use of Observation is appropriate, they're encouraged to consult with implementers on [[chat.fhir.org implementer's stream]]
Eric Haas (Feb 16 2018 at 18:44):
Like I said Nothing in this chat has persuaded me otherwise :-) (call me cynical and thanks for suggestion Lloyd)
John Moehrke (Feb 19 2018 at 16:23):
I don't think that I support this change to Observation.subject. I fail to understand why this is necessary. If the change was done, then we would have a mess with overlap with basedOn, context , performer, partOf, derivedFrom, etc. This overlap would hinder interoperability. We need to make the FHIR model with holistic perspective. To focus too tightly on esoteric use-cases can cause us to accept inappropriate holistic perspective modeling.
John Moehrke (Feb 19 2018 at 16:33):
With Privacy/Security hat on my head -- Major concern that I have that I can express is that by moving subject to <any> we can have observations about the patient that are not directly understood as about that patient. Thus they are not found by a search on observations about the patient. This has additional ramifications related to Consent and other Access Control rules on the Observation. As it will be hard to know the access control rules (including Consents) that would need to be considered when someone requests to access that Observation. This also is problematic relative to AuditEvent, and the various access reports that are necessary from a Privacy and business-rules post processing.
Lloyd McKenzie (Feb 19 2018 at 16:59):
I don't understand your objection @John Moehrke. If I've made one Observation (Patient has genetic variant XYZ) and a year later someone wants to say "That variant is pathogenic for disease A", how else is that to be done? I don't see any need to mess with basedOn, context, performer, etc.
Lloyd McKenzie (Feb 19 2018 at 17:00):
I think the proposal is to allow the "focalSubject" to be anything. The subject would still be Patient
John Moehrke (Feb 19 2018 at 17:56):
I am very confused.... you indicate that subject will be anything, then say subject would be Patient... which is it?
Eric Haas (Feb 19 2018 at 18:17):
To summarized this conversation:
- Leaning away from O.subject= Reference(any)
- looking at extension focal-subject with Reference(any)
- looking at promoting this extension to core
- Questioning how the heck we are going to rescope and stop rampant overuse us Observation instead of [your favorite resource here]
- Asking but not getting input from implementers whose systems harboring all this data and to be blunt most if not all on this chat are seeking a way to use Observation for there profiling convenience which bring us back to bullet 4.
I would really like to see an fully fleshed out instance or 3 with the focal subject used in this fashion. I would really really like some of my concerrns either thoroughly refuted or confirmed as well.
Eric Haas (Feb 19 2018 at 18:18):
.. within the next day or so....
Grahame Grieve (Feb 19 2018 at 19:51):
I liked points 1-3. Known uses of focal subject:
- observation on fetus in womb
- observation about family relations in mental health context
- observations & genomic reports on tumours
- observations on patient-embedded devices
Grahame Grieve (Feb 19 2018 at 19:51):
you want actual examples of them?
Eric Haas (Feb 19 2018 at 19:55):
Thanks Grahame but Those are existing focal-subject targets and I am not concerned care about them .... My Angst and concersn are when start talking about focal-subject = Observation, Condition, Medication where it starts to become more an evaluation than an observatino and then the overlap with other resource elements becomes a problem.
Daniel Rutz (Feb 19 2018 at 23:32):
To summarized this conversation:
- Leaning away from O.subject= Reference(any)
- looking at extension focal-subject with Reference(any)
- looking at promoting this extension to core
- Questioning how the heck we are going to rescope and stop rampant overuse us Observation instead of [your favorite resource here]
- Asking but not getting input from implementers whose systems harboring all this data and to be blunt most if not all on this chat are seeking a way to use Observation for there profiling convenience which bring us back to bullet 4.
I would really like to see an fully fleshed out instance or 3 with the focal subject used in this fashion. I would really really like some of my concerrns either thoroughly refuted or confirmed as well.
Agreed with bullets 1-3 there.
- With an OO hat, we need to put more boundaries around Observation and have it focus on being things relevant to the patient (or other clinically relevant subject). Allowing Observation to be used for anything, basically unbounded (even in scope within a Patient, because you can say practically anything like "Patient Sex" is still an observation) is unhelpful and leaves OO holding a mess of a resource which will be nigh impossible to thoroughly documented & maintain.
- With an Implementer hat, there are a wide number of things which get stored internally in relatively generic data structures for convenience or historical reasons, but still should be presented in FHIR (or application UIs, CDAs, analytic universes, etc.) as a more strongly typed attribute. So even in day-to-day life I wouldn't find it helpful to have Observations everywhere in place of other use-case-specific attributes.
Bullet 4: Observation seems like overkill for simply a key/value pair attribute, though it can obviously be used for that. So per the need to restrain it in a more focused direction,
- Personal recommendation: I suggest a new "thing" which is used more generally for these and that it be owned by FHIR-I. I don't have really strong feelings if it's handled as a new resource (GeneralAttribute), a complex data type, some new flavor of backbone, or whatever. But since we all agree on the need to have many arbitrary attributes (# of beds in a hospital, who the hospital's accrediting organization(s) should be, etc. as well as other previous examples), it needs to be very simple, rather small, and owned with the broadest perspective across the whole spec.
Grahame Grieve (Feb 19 2018 at 23:38):
sounds like an extension?
Lloyd McKenzie (Feb 20 2018 at 01:07):
Where do systems currently capture statistical observations about organizations, practitioners, encounters, etc?
Eric Haas (Feb 20 2018 at 02:24):
@Lloyd McKenzie that is another issue. What I am concerned about is observations on observations
Eric Haas (Feb 20 2018 at 02:25):
and the like.
Grahame Grieve (Feb 20 2018 at 02:45):
Lloyd - measure report
Eric Haas (Feb 20 2018 at 02:48):
Could add Organizations and encounters there as well?
Lloyd McKenzie (Feb 20 2018 at 03:45):
Observations on Observations works if we extend focal-subject. No need to extend Subject there.
Eric Haas (Feb 20 2018 at 04:22):
Whether reference(any) as a subject or focal subject doesnt change my concerns
Lloyd McKenzie (Feb 20 2018 at 06:14):
Whether we support it through Observation or another resource, in the end, it'll be necessary to make "Observation thingies" about Observations, Conditions, etc. Whether it's a separate resource or we re-use Observation won't lessen the possibility of abuse. So I don't really understand the concern.
John Moehrke (Feb 20 2018 at 14:31):
Isn't an Observation about an Observation still about the subject? So the subject would still be the same ~patient~ but I do understand that it would be good to have an element to related the Observation about an Observation. Is this a new element that you are referring to as focal-subject? If so, then I missed that clarification, and I would be fine with that as the base subject still is clear.
Travis Stenerson (Feb 20 2018 at 15:54):
Whats an example of Observation about an Observation? That sounds a bit like a component or a derivedFrom reference?
Lloyd McKenzie (Feb 20 2018 at 17:29):
Observation A (patient has variant X) is subject of Observation B (variation is pathogenic). It can't be component because it's done at a different time. And it's not derived from because it's not a stand-alone statement about the patient - it's qualifying the variant directly.
Elliot Silver (Feb 20 2018 at 20:34):
I thought we already supported observations about observations using derivedFrom? That would cover "from X we determined Y", or is there some other kind of observation on observation? Peer review (an observation that another observation is unfounded, incorrect, etc.)?
What I'm worried about is an Observation on an Organization or ValueSet, or otherwise devoid of a patient context. I've never been at ease with the "an Observation is a way to hold any measurement/conclusion" school of thought. I think it needs to relate to a patient (or group of patients). If you want to hold departmental performance stats, look elsewhere. In part, this is what my earlier comment, and I think @John Moehrke 's about context, basedOn, etc. was about -- the context can't be limited to an episode of care or encounter if if the scope is meant to include "departmental wait times over the past 3 months"?
Changes to better support observations about groups of patients, fetuses, etc. make sense. But we should avoid allowing Observation to become a hold-all bag for key-value pairs related to anything.
Lloyd McKenzie (Feb 20 2018 at 20:53):
Derived from lets you say "because your blood work said X, I've decided that Y is true about you". In both cases, the "subject" is the Patient. However if I want to say "this variant is pathologic", the subject is the variant. It wouldn't be correct to say "Patient has variant X, therefore Patient is pathologic". The thing being described - the subject - is the variant, not the patient. (Though the "record target" would be the Patient for both)
Eric Haas (Feb 20 2018 at 21:10):
??? The specimen is blood but we infer the results are about the patient. this is no different. this observation is about the patient. the interpretation is about the patient. I don't think that focal-subject would change that.
Daniel Rutz (Feb 20 2018 at 21:48):
@Lloyd McKenzie the example about a genome variant and then the statement that it's pathogenic - that seems to be 100% the domain of the Observation.interpretation element because the existing concepts in that list are equivalent in the equivalent lab diagnostic areas (chemistry: Abnormal, Critical Abnormal, etc.; microbiology: Sensitive, Resistant, etc.).
Do we just need to add a standard set of genomic interpretations to the Observation.interpretation value set (https://www.hl7.org/fhir/valueset-observation-interpretation.html)? That seems like it's clearly a good thing to do for your particular example, at the very least, even if it doesn't completely settle the boundary discussion. @Joseph Kane, thoughts on this?
Lloyd McKenzie (Feb 20 2018 at 23:28):
@Daniel Rutz The challenge is that the interpretation can happen 2 years after the Observation is made - by someone different than who recorded the Observation (and possibly even from a different Organization).
Travis Stenerson (Feb 21 2018 at 03:12):
If some genetic variant is deemed pathologic long after the initial sequencing, that sort of seems like the A in SOAP, O being the initial observation and whatever else caused it to be seen as pathological. Why did they deem it pathologic? It could also be a Condition with evidence reference to the initial observation, if it is now confirmed to be causing disease.
Daniel Rutz (Feb 21 2018 at 03:49):
A much later interpretation (pathological vs. unknown significance) is definitely possible, especially in the CG space yes. But I think that's NOT the original observation, and especially in that space we really need a way to add secondary analysis as a specific workflow. That's not common to most other situations, CG is one of just a few where there's a much later secondary post analysis and I'm confident that any pathologist signing off on that report would expect there to be a NET NEW report as a whole, not just one observation referencing another.
Lloyd McKenzie (Feb 21 2018 at 04:22):
I agree it's NOT the original observation - but it's about the original observation. The whole point is that they don't want to run the sequencing again. They want to re-analyze all of the variants previously identified and assess whether there's anything new to assert based on "current" knowledge.
Lloyd McKenzie (Feb 21 2018 at 04:22):
The question is how do we properly capture the assertion about a variant - which is itself an Observation made previously.
Eric Haas (Feb 21 2018 at 22:40):
OK I am going to present a couple of options to the OO WG either tomorrow or next Thursday which leaves everyone unhappy:
- Option 1: keep focal-subject as an extension with Reference(Any) and add a bunch text saying basicaly not use this if there is a perfectly good resource that does the job. ( maybe provide an example or two) and the caveat that in the future will look at possibility of a new resource to handle these types observation that are really truly assessments ( OpenEHR Evaluation archetype or a slimmed down ClnicalAssessment or overloaded MeasureReport)
- Option 2: promote focal-subject inline with Reference(Any) as a DSTU element and add a bunch text saying basically not use this if there is a perfectly good resource that does the job. ( maybe provide an example or two) and the caveat that in the future will look at possibility of a new resource to handle these types of assessments ( OpenEHR Evaluation archetype or a slimmed down ClnicalAssessment)
BTW this will cover these trackers: GF#14863, GF#14443, GF#15162
Grahame Grieve (Feb 22 2018 at 06:17):
I prefer #2 but like "add a bunch text saying basicaly not use this if there is a perfectly good resource that does the job". (because I like spitting into the wind...)
Eric Haas (Feb 28 2018 at 03:01):
OK we voted on option 2 and I am applying it - I need three things, a RIM mapping, and V2 mapping, and a simple example or two with enough details ( codes, codesystems, references types, etc) that I can add to the build.
Lloyd McKenzie (Feb 28 2018 at 03:26):
I can get you a full example, but it won't happen until during the QA period.
Lloyd McKenzie (Feb 28 2018 at 03:26):
RIM mapping provided by PM
Eric Haas (Feb 28 2018 at 03:29):
ty and truthfully I can do the V2 mapping
Eric Haas (Feb 28 2018 at 18:07):
@Lloyd McKenzie @Grahame Grieve @Mark Kramer @Rick Geimer Applied this change. Check it out and if there are any minor tweaks to the wording let me know. edited Boundaries text and Notes text too. Note there is still a focal-subject-code extension, since we did not talk about that it is staying put for now.
Mark Kramer (Feb 28 2018 at 20:03):
Thank you @Eric Haas @Lloyd McKenzie @Grahame Grieve @Travis Stenerson @Rick Geimer and everyone who contributed to this very long thread. Several suggestions:
1) We might want to avoid the word "subject" in the name of this attribute. Observation.focus might suffice, while minimizing the confusion with Observation.subject.
2) Wordsmithing:
Definition: The focus is the point of attention when the observation concerns a specific aspect of the subject, or something associated with the subject. The focus of an observation could be an existing condition, an intervention, the subject’s diet, behavior, environment, a body structure such as a implanted device, or a body structure such as a tumor. The focus could also be a spouse, parent, fetus, or donor. An example use case would be using the Observation resource to capture whether the mother is trained to change her child's trachestomy tube. In this example, the child is the patient of record and the mother is the focal subject.
Eric Haas (Feb 28 2018 at 20:30):
OK made the change to focus and modified the description some.
Vassil Peytchev (Feb 28 2018 at 21:09):
Maybe the last sentence in the revised description should read "In this example, the child is the subject of the observation (as the patient of record) and the mother is the focus of the observation."
Eric Haas (Feb 28 2018 at 23:06):
yes already did
Last updated: Apr 12 2022 at 19:14 UTC
