Stream: implementers
Topic: Context is everything
Eric Puster (Jul 27 2021 at 21:40):
I'm new to the channel, and jumping into the middle of a conversation that probably stretches back to the start of FHIR, but I had a question about the way that FHIR handles context (in structured documents). On the one hand, context for a composition is well-defined (confidentiality, subject, author, event, event period and encounter), which is fabulous. On the other hand, downstream resources which are part of the composition are all expected to explicitly define their own context ("There is no context flow model in FHIR" http://build.fhir.org/composition.html#cda), sometimes in ways that cause implementers to do things that seem counterintuitive. For example, in a Composition, Observation.code is sometimes the type of finding ("abdominal tenderness"), and sometimes part of the context of the Observation ("examination") forcing the finding type itself down into Observation.value, overloading it as well. (https://www.hl7.org/fhir/observation.html#guidance). I worry about fields that have multiple competing definitions - can't this result in unpredictable behavior? Or, as I hope, did I miss something important?
Lloyd McKenzie (Jul 27 2021 at 22:25):
It's certainly possible to do things 'badly'. You could have a Composition with a subject of a specific Patient and through a bunch of resources into the document that have nothing to do with that Patient. The choice of what to put in code vs. value is actually an orthogonal discussion to context conduction and there's a great deal of discussion about the tradeoffs in the notes section of the Observation page.
What we've learned about attempting to conduct context (which is what we did in HL7 v3) is that it's super tricky to get right and there are invariably exceptions that blow up the rules. With FHIR, we wanted to ensure that it was always possible to separate resources that had arrived packaged in a document and use them on their own. Eliminating context conduction means there's a degree of redundancy, but the meaning of each resource should be clear on its own.
Eric Puster (Jul 28 2021 at 13:27):
Explicit context definitions at the Resource level are not necessarily bad, though they reduce the readability and increase bloat, but I wonder if there is a way to define the context of the finding in a way other than overloading a field with a second definition. Per the definition, the context of a finding in a structured document has six elements, yet the Observation resource only appears to have fields for subject, author and encounter. Further, overloading Observation.code with the encounter type only seems to provide part of the encounter data, which has its own field already. If we want explicit and independent context definition in each Observation resource don't we need confidentiality, event and event period fields?
My concern isn't simply that some implementers will do things 'badly,' because that is inevitable. It is that inadequate structure might force them to do something badly. If there is no context flow, that's fine and even laudable, but then each resource must contain sufficient data to fully establish context.
Lloyd McKenzie (Jul 28 2021 at 13:52):
Confidentiality is there - see Resource.meta.security. Each resource captures timing information as appropriate (e.g. Observation.effective and Observation.issued. What context do you feel is missing?
Eric Puster (Jul 28 2021 at 14:13):
Thanks for the tip. My understanding of an "event" in FHIR incorporates far more than just a timestamp - in includes everything from whether the finding was coded by a licensed professional to what type of authorization was given (verbal, written, etc.) to generate the finding (e.g. the ActCode valueset). Where does this information go in an Observation, DiagnosticReport, MedicationAdministration, etc. other than context flowing from .partOf or .encounter?
Even more important: encounter, performer, subject - these all reference other Resources, and imply that context flows from them.
Eric Puster (Jul 28 2021 at 14:20):
My basic concern is that FHIR for seems to be built with a dichotomy: an expectation for at least some context to move through structured documents, and a policy that forbids it.
Lloyd McKenzie (Jul 28 2021 at 14:50):
For encounter, performer, subject, etc., the reference establishes the context. If you want the details about the Encounter, Practitioner, etc. you need to query for them, but the linkages are sufficient to establish context - and to be able to determine whether multiple resource instances share context or not. The key thing is that the context of the encounter, performer, etc. are not based on what document something is part of (or whether it's part of a document at all), but based on explicit references from the resource itself. That means that it's safe to extract a resource from a document and send it by itself without losing context. If you receive a bare Observation, you have all the information necessary to determine the demographics of the subject, the licensure of the performer, the modality of the Encounter, etc.
Eric Puster (Jul 28 2021 at 15:05):
Then perhaps it would be helpful to state that there is context flow only through references, rather than state there is no context flow (http://build.fhir.org/composition.html#cda), as well as adjust other recommendations, such as using recommending against partial context definitions through a SNOMED or LOINC code in an Observation, and instead recommend using .encounter for this purpose (https://www.hl7.org/fhir/observation.html#code-interop).
Lloyd McKenzie (Jul 28 2021 at 15:10):
It's not context flow. The Observation's subject is declared on the Observation - it doesn't flow from anywhere else. The subject of an encounter the Observation references is never presumed to be the subject of the Observation.
Lloyd McKenzie (Jul 28 2021 at 15:11):
In terms of pre-coordinating context into codes vs. sending as distinct elements, FHIR makes no recommendations - those choices are driven by choice of terminology as well as system behavior. Is body site part of the Observation.code or a separate element - answer="it depends".
Eric Puster (Jul 28 2021 at 15:45):
I don't understand what you mean. The demographic information flows from an outside resource, the Patient resource, into the context for the Observation resource. It is not contained explicitly within the Observation itself. It makes sense that a third-party resource would not be valid (a referenced encounter does not imply the subject of that encounter must be the subject of this resource), and that is easily computable.
As to the use of Observation.code (which as you noted is not exactly the same topic), the current guidance establishes two competing definitions for the field, not merely nuances attached to each code. As an absurd example, is bodySite a site on the body? or could it also be the location in which an Observation occurred? Having two competing definitions can produce unexpected behaviors. (The steroid injection is not covered by insurance because the "Left acromioclavicular joint" is not a valid facility for administering medical care)
In the same way, according to the authoring guidelines for FHIR, Observation.code and Observation.value must have orthogonal definitions. But depending on the case being followed, these two become interchangeable (does "Abdominal tenderness", the medical concept being observed, go in .code or .value?). Likewise, where does the examination context for the Observation come from? Does it flow from .encounter? Or does it come from .code?
Lloyd McKenzie (Jul 28 2021 at 16:00):
It doesn't 'flow'. It's referenced. That's different. Flow would mean "The subject of the Encounter flows to also be the subject of the Observation." We don't allow flow. We do support context by reference. We say "The patient for this is Patient/123" - if you want to know more about who/what that is, go look it up. But there's no flow. The subject is explicitly declared on each resource.
Lloyd McKenzie (Jul 28 2021 at 16:03):
I don't understand your example around bodySite - bodySite is clearly defined as "site on the body". No conformant system could send the location of the clinic or something like that. I don't understand what you mean by two competing definitions.
In terms of whether Abdominal tenderness going in code with a value of "present" or goes in value with a code of "finding", FHIR makes recommendations but doesn't force the issue because the reality is that different systems do different things and we can't standardize content that the world at large isn't ready to standardize. That's completely orthogonal to context flow between resources though.
Eric Puster (Jul 28 2021 at 16:09):
Thank you for clarifying the nuance between "flow" and "reference." It was not clear to me in the guidelines for structured documents.
As to the bodySite example, we can look at the definition of Observation.code: "Type of observation" and the referenced definition for observation: "Measurements and simple assertions made about a patient, device or other subject." Yet putting "Examination" in Observation.code neither measures anything, nor does it assert anything about a "patient, device or other subject." So we must add "Type or context of observation." Those are two competing definitions.
Just the same as if bodySite were defined: "Observed body part or location where observation was made"
Eric Puster (Jul 28 2021 at 16:42):
This circumstance creates a problem for implementers who want to specify context and type, who seem to have pushed type into .value. But then what if they also need to specify a measurement? Currently FHIR makes no recommendation, other than to use profiles.
I guess this is, unfortunately, a classic conflict between "what a standard meant to do," vs. "what users actually did with it." But without making a recommendation, I'm concerned that FHIR is sending the signal that the three fields are interchangeable.
Lloyd McKenzie (Jul 28 2021 at 22:22):
Observation is fundamentally a name-value pair and there are a variety of approaches to using it which are driven by terminological philosophy. If you've got one code that express the whole thing of "Finding of severe fracture of the left femur", then you might very well have an Observation.code that just says "assertion" and through your whole SNOMED code in Observation.value. On the other hand, there might be systems that take a questionnaire-type approach and would put "Fracture of the left femur" as the question and have an answer that says 'present'. The language here in the Observation resource gives guidance about what we believe to be 'good practice', but we can't force that guidance there are a wide variety of systems that capture observations and they capture them differently. It's not practical (or sometimes even possible) to make them map to a common approach.
Lloyd McKenzie (Jul 28 2021 at 22:24):
The fields are definitely not interchangeable. You can't put "severe fracture" in bodySite - bodySite can contain "left femur", but that's it. And code is always read as "what was the question" and value is "what was the answer". The variation is "how specific should the question be". The question could be as high level as "what did you find?" and could be as specific as "Did you see this super-qualified thing?" - and everything in between.
Eric Puster (Jul 29 2021 at 14:44):
Isn't every resource a name-value pair? Or a name-value group? The distinctions between them are driven by their definitions, not by the terminology. FHIR can choose to define the Observation resource as "what clinical finding was observed" paired with "what was observed about it", or it can define it as "any term in any terminology" with "something about that thing," but the current definition is the former.
I think that terminology can be used to align the resource to a standard rather than used as an excuse to allow any and all behavior. SNOMED has computable categories, and an Observation.code can be recommended to accept only Clinical Findings and Observable Entities, or LOINC codes. "Hey! I wanted to put [something not relevant] in an Observation!" some implementer will cry. Then FHIR can guide them to place that data in the resource that was built for it. Trying to force other data into an Observation will result in data loss and confusion. Titles, types, categories, attestors, event codes, sections . . . these are all required to make an Examination complete - which is why the Composition resource was created.
I feel that those inclined to use the "Examination"/"Abdominal tenderness" (or "Assertion"/"[What is being asserted]") pair in an Observation are in need of education, not validation. Or, alternatively, if it is felt that the Observation resource contains too little information, perhaps it should be expanded to include more information (perhaps through an extension). Then we could have {context: "Examination", code: "Abdominal tenderness", value: "Severe"}.
EDIT: As I review Observation, I find there is actually already a place for "Exam" in Observation.category. This makes it even more improper to put the category in Obs.code.
Eric Puster (Jul 29 2021 at 14:51):
As far as interchanging fields, the reference you mentioned describes 4 cases as valid implementations of an Observation. Cases 1 and 2 vs. 3 and 4 interchange the position of "Tenderness" but are said to have the same overall meaning. To use your example of an assertion in Obs.code, Obs.code = "Present" Obs.value = "Tenderness" and Obs.code = "Tenderness" Obs.value = "Present" would both be permissible uses of Observation.
Lloyd McKenzie (Jul 29 2021 at 17:00):
Few resources have name-value pairs. Obviously each element has a name and will have a value. But only Observation has two elements where the meaning of one element (the value) is defined by the meaning of another element (the code).
FHIR can't (and won't) mandate the use of SNOMED - or any other terminology. We must support systems that capture findings with SNOMED, ICD, and a wide variety of regional and local code systems.
It's absolutely not true that you need to have sections or document structure for data to be complete. An Observation, sent on its own, that simply says "on this date, this patient had a body temperature of X" is a complete statement. You don't need to know who made it. You don't need to know what encounter it was made as part of (if any). You don't need to know who attested to it. In some cases, those additional elements might be useful or even essential, but for basic purposes they're irrelevant. And, if needed, they can all be conveyed without ever bringing Composition into play. (And with FHIR, even if you do bring Composition into play, nothing declared on the composition can be inferred to apply to the entries in the composition.)
Jean Duteau (Jul 29 2021 at 17:34):
Just to jump in and jump out of this conversation, I thought I'd point out that I have IGs where we use Observations that are not about patients - obviously allowed by the Observation.subject - and I'm certainly not alone. Some of our observations about devices are not Clinical Findings or Observable Entities. Luckily, we have some vocabulary already defined in the NCI-Thesaurus which we use. This goes to Lloyd's point that making a specific binding recommendation for Observation.code (what the Observation is about) is hard to do. The resource does use LOINC as an example binding but I don't think we could do better than that. When I read the scope and usage of Observation, I do get a sense of what it is intended before, but I have been doing HL7 for years and Observations were essential in V2 and V3 and we've inherited that into FHIR, so I do have a base understanding of what it is supposed to be as well as how it is used in the wild.
Eric Puster (Aug 03 2021 at 14:04):
If each resource has a name and a value, isn't that a name-value pair? I agree that Observation is unique - it has a definition that no other resource has. But it is the definition of the resource that makes the resource what it is, not the terms that are chosen to go inside it. (And I thought the value refines the code rather than the code defining the value?)
I haven't suggested any mandates, only recommendations. And I apologize for not including some terminologies which are used for particular purposes. As mentioned earlier, the definition of the Observation resource includes observations of devices.
I agree completely that each resource has a specific meaning all on its own, even if without context it is not actionable. An Observation, on its own and disconnected from any other resource, cannot fully specify a patient in a structured fashion as far as I can see. It needs a Patient resource. And yes, you are absolutely correct, anything that would be part of a Composition can be conveyed individually or as a subgroup, but then it is only part of the data. Thus, complete in one sense, not complete in another. (Temp = 98.6 has meaning, but no clinical significance. Connect to a patient, now it has some clinical significance, but lacks context. Connect to a hospital visit where patient had high fevers in the past, and now has normal temperatures, as in a Composition, and now the temperature Observation has a much more complete meaning, even though the code and value have not changed.) Composition was chosen for convenience, but we could use any resource, each of which has been defined to efficiently group data for completeness, readability and therefore usability. Yes, you can convey a patient's age, gender, birthdate, etc. as a series of Observations, but FHIR offers a clear recommendation: "[The Observation resource] is not intended to be used for those specific contexts and use cases already covered by other FHIR resources." https://www.hl7.org/fhir/observation.html#bnr
I'm still curious about your thoughts on the interchangeability of the code and value fields. Do you think that recommendation will increase or decrease usage of FHIR over the long-term?
Rik Smithies (Aug 03 2021 at 14:08):
Re name-value pair, no, not for me.
name: value is not a name value pair.
Name-value pair usually refers to something like this:
name: the-real-concept-name-is-here
value: the-value-is-here
Eric Puster (Aug 03 2021 at 14:14):
@Rik Smithies Interesting! It must be my C++ training getting to me, key: value is a key-value pair. What discipline does this version come from?
Rik Smithies (Aug 03 2021 at 14:38):
not sure. I don't remember that from my C++ days :-)
Pretty sure it's just a general software thing. Wikipedia https://en.wikipedia.org/wiki/Name%E2%80%93value_pair
Lloyd McKenzie (Aug 03 2021 at 14:51):
Context doesn't require that the data be sent. If I have 20 Observations that all have the same Patient subject, I have the context that they're all for the same individual, and I have a unique identifier for that individual. I might not have their demographics, but I still know the unique entity - that's context. In FHIR we very much want you to not ever have to pass around groups of resources. You can by choice, but REST works best when you only have to manipulate one thing at a time and can go grab the bits you happen to care about.
The variation of approaches around what to put in code vs. value when both are coded didn't originate with FHIR. It's equally true in v2, CDA and many other standards. It certainly impacts interoperability, but not uptake. In the end, a standard can only standardize what implementations (and implementers) are willing to support. FHIR could dictate that the "code = assertion; value = all finding details" pattern was prohibited, but the implementer community would either ignore us or would take that as a reason to not use FHIR. Given that even with a degree of inconsistency around code/value, there's still significant benefits around everyone using FHIR, we don't impose a rule we can't get the community to agree on.
Note that while the base standard is quite loose about what can go in code vs. value, implementation guides can and do impose tighter rules - when they can get agreement in the narrower community covered by the guide.
Michele Mottini (Aug 03 2021 at 15:47):
(deleted)
Eric Puster (Aug 03 2021 at 19:53):
@Rik Smithies I'm still confused, the wikipedia article you cited said <attribute name, value> is an attribute/value aka name/value pair . . . https://en.wikipedia.org/wiki/Key%E2%80%93value_database
Eric Puster (Aug 03 2021 at 20:13):
@Lloyd McKenzie What I understand from our conversation is this: the FHIR standard cares very much about what goes into some fields, and merely acknowledges what implementers are doing for others. If enough implementers are doing a thing with the latter type of field, it becomes a de facto standard. With the former, woe betide those that want an 80 character ID . . .
Lloyd McKenzie (Aug 03 2021 at 20:26):
We standardize what we can get consensus on. The id size was discussed at length and was in draft versions of the specification for 7 years before it got locked down as normative. It's also something that is completely technical and for which workarounds can be found if you natively have something longer. On the other hand, the division between code and value often directly impacts on how user interfaces expose and capture data, so much harder to have workarounds - and often impossible to do computable transformation. The specification makes things tight when the community (i.e. the whole world, inpatient/outpatient, veterinary, you name it) can manage that, and keeps things loose when it can't, allowing further tightening by implementation guides.
Lloyd McKenzie (Aug 03 2021 at 20:28):
If there are places where you feel we're not being sufficiently tight and are confident that the community at large can handle something tighter, then change requests are welcome. Similarly, if there are places where you feel that the constraints in place will mean that some significant subset of implementers will be unable to comply with FHIR regardless of degree of effort, then by all means ask for something to be loosened.
John Silva (Aug 03 2021 at 21:04):
This shows the constant 'tension' between preciseness and flexibility to meet a wide variety of use cases. This is not new in the HL7 (or interoperability) space -- V2 had 'lots of optionality' (and Z-segs - the logical equivalent of FHIR extensions), V3 did too, and now FHIR. FHIR has a more precise way of defining this (profiles, conformance, IGs, etc.) and newer/better technology but the same concepts/concerns existed in V2 (and to some extent the mechanisms for addressing it started there).
Rik Smithies (Aug 04 2021 at 11:23):
@Eric Puster I don't really understand what you are confused about. Is the issue that you don't understand the explanation that I gave and how it relates to FHIR, or the article I posted, or that you disagree with what it says?
Last updated: Apr 12 2022 at 19:14 UTC
