Stream: implementers
Topic: Capturing positive statements of absence in Observation
David Waters (Nov 15 2018 at 15:11):
We are looking at an implementation for clinical decision support, based on the ServiceDefinition/GuidanceResponse interactions, in the urgent & emergency care space, particularly for triage.
Within triage, a key element is the recording of negative information (e.g. Patient DOES NOT have diabeters, or Patient IS NOT suffering shortness of breath). In the Condition commentary (https://www.hl7.org/fhir/condition.html#9.2.3.5) there is a statement about using Observation to capture this kind of statement.
Does anyone have any examples of this being implemented that we can learn from?
Lloyd McKenzie (Nov 15 2018 at 15:29):
@Eric Haas ?
Vladimir Smirnov (Nov 15 2018 at 15:43):
If TermInfo in its latest rendition still applies to FHIR, there is a section on negation within Observations (2.2.10 on page 54).
Assertions of negative Observations (e.g. absence of a specified finding)
SHOULD be represented, as part of the SNOMED CT expression in the
Observation.value attribute, by including the appropriate explicit
408729009 | Finding context |
Thus you would encode this by a post-coordinated expression of the form <404684003 | Clinical
finding | : 408729009 | Finding context | = 410516002 | Known absent |
Eric Haas (Nov 15 2018 at 18:41):
for findings that are not found: there are terminology options as noted above or see this guidance in the specification.
pattern 3:
- code=[diabetes]
- value=[true|false]
Jay Lyle (Nov 15 2018 at 18:46):
@David Waters - To clarify, the use case is Triage, and a clinician is asking diagnostic or safety protocol questions? And if the answer is yes, diabetes, we expect to record a condition, but if it's no, an Observation is sufficient? (And if it's yes, shortness of breath, do you have any expectations about which way it would go?)
Vladimir Smirnov (Nov 15 2018 at 18:49):
@Eric Haas But isn't this pattern violating prior TermInfo recommendations? See section 2.2.3.1 (p. 33)
TermInfo recommends all observations to follow the pattern of code being an < Observable entity, and value being a < Finding, in order to normalize their interpretation when sharing.
Eric Haas (Nov 15 2018 at 18:52):
@Rob Hausam ? We took much of this from terminfo and it should be consistent (at least when we wrote it)
Vladimir Smirnov (Nov 15 2018 at 18:57):
"Pattern 4" in current draft spec is also deprecated in TermInfo:
To my understanding, isn't it the case when a Condition should be used instead? This is the case when we postulate the presence of a finding without any further value. In CDA RIM there's no Condition, so they introduced this pattern in TermInfo as a workaround. Wasn't Condition introduced in FHIR to represent just such statements?
Vladimir Smirnov (Nov 15 2018 at 19:18):
@Jay Lyle We are facing a similar question in our work. The answer depends on whether the absence of the problem is clinically relevant. As stated in the Condition spec, «generally, electronic records do not contain assertions of conditions that a patient does not have». If the whole purpose of the question is triggering further sub-questions, then the statement of non-presence may be of no value. If there is a requirement to save it for audit purposes, then I would choose the Observation, or keeping it in QuestionnaireResponse without conversion to structured data (if your screen forms are based on Questionnaires). As for Diabetes vs Shortness of breath, is there any difference? As long as they both fall under the Clinical Finding SNOMED hierarchy, both codes are safe to go in a Condition.
Eric Haas (Nov 15 2018 at 20:24):
I am not a fan of pattern 4 but it does reflect what implementers do.
Eric Haas (Nov 15 2018 at 22:25):
the terminfo thing is a red herring BTW. I mean how many implementers of FHIR are reading up on terminfo?
Rob Hausam (Nov 15 2018 at 22:50):
I appreciate @Vladimir Smirnov referencing the TermInfo guidance on this (Eric does have a fair point, which I hadn't seen when I first was writing this). The TermInfo guidance wasn't written with FHIR in mind, and the CDA/V3 standard that the guidance is based on has some differences from FHIR, like negationInd. So technically the TermInfo IG doesn't apply to FHIR, but where there is an appropriate alignment I would say that the principles do still apply and we should try to follow them and remain in sync where possible. And as @Eric Haas said, we did try to align with TermInfo in writing the guidance in 10.1.4.4.3. Oner key difference with the TermInfo guidance is that in FHIR we've explicitly recommended to not use the ASSERTION pattern (particularly because that tends to adversely impact searching) and we also did not include a "negation indicator" element in FHIR (largely to avoid the overlap and potential inconsistency issues that arise with that). And, as mentioned, in CDA/V3 we didn't have a class separate from Observation that would be equivalent to the Condition resource. So what should we do in FHIR in this particular case? There isn't only one correct answer (and maybe we need to try to get there), but I have some thoughts on what I would do in this case. If this is reflecting a typical set of questions that are asked of patients that present with similar presentations then I think I would use Questionnaire/Questionnaire with an appropriate set of questions and coded answers. If the questions are more directed by the clinician and are specific to the patient then I probably would use Observation pre-coordinated LOINC and/or SNOMED CT codes using a variety of pattern 1 or 2. Since the questions to be asked (especially that any subsequent decision support might be based on) should be known in advance, if the needed codes for the questions or answers aren't available in existing terminologies (standard terminologies, ideally) then they can be requested to be added.
Vladimir Smirnov (Nov 15 2018 at 23:46):
TermInfo for CDA is the most thorough guidance on use of SNOMED in information models that we have. It requires some mental adjustment to be applied to FHIR, but it can't be ignored. In particular, it is nearly fully applicable to Observations, since they are very similar between FHIR and RIM. And since patterns 3 & 4 were recommended against years ago, shouldn't it be appropriate to include this warning in FHIR documentation, if it derives from that? Of course legacy systems can use the best approach that fits, but new systems shouldn't!
Grahame Grieve (Nov 16 2018 at 08:14):
there's a key priority that wasn't considered for terminfo, which makes a real difference for FHIR. which is search. You will want the Observation.code to be as useful as possible so that searches are most efficient. In practice, this is mostly a comment on the use of Observation.code = "ASSERTION"
David Waters (Nov 16 2018 at 08:25):
@Jay Haas
@David Waters - To clarify, the use case is Triage, and a clinician is asking diagnostic or safety protocol questions? And if the answer is yes, diabetes, we expect to record a condition, but if it's no, an Observation is sufficient? (And if it's yes, shortness of breath, do you have any expectations about which way it would go?)
That's correct - if the answer is yes, diabetes, we expect to record as a condition. If it's no, I'm expecting an observation.
For shortness of breath, if the answer is yes, I'm also expecting to record this as an observation.
Note that when you say 'record' - our current clinical guidance is that these elements will only be recorded for the duration of the triage process - a patient telling you that they have diabetes may not have sufficient 'weight' to update a permanent medical record
David Waters (Nov 16 2018 at 08:33):
@Rob Hausam
... I think I would use Questionnaire/Questionnaire with an appropriate set of questions and coded answers.
We are using Questionnaire and QuestionnaireResponse to ask the actual questions, but we want to code the meaning behind that in an appropriate way so that different CDSS can interoperate in the same patient journey.
So, a triage journey may want to use two different CDSS (for a variety of reasons, including supporting different skill sets, different comms channels, different specialties, etc.). Both CDSS are aware that a patient suffering from shortness of breath is a key element to guide the decision support. However, one CDSS asks a question 'Are you suffering from shortness of breath?' (Yes, No, Maybe), while the other CDSS asks the question 'Is the patient having difficulty catching their breath, or are they finding that they are out of breath doing things that they used to be able to easily do?' - the meaning is the same in both cases, hence wanting to codify as an Observation, which can be shared (and hence the problem as stated)
David Waters (Nov 16 2018 at 08:44):
there's a key priority that wasn't considered for terminfo, which makes a real difference for FHIR. which is search. You will want the Observation.code to be as useful as possible so that searches are most efficient. In practice, this is mostly a comment on the use of Observation.code = "ASSERTION"
Yes, this is my thinking for this use case, as well - when the second CDSS receives a set of Observations from the first, it will make things simpler if it can just search for the relevant code (shortness of breath) and then check the value (true|false) to provide the guidance
Rob Hausam (Nov 16 2018 at 10:00):
@David Waters I still have some questions about the use of a "relevant" code and value (true|false), which is basically pattern 3. It's essentially treating 'value' as a de facto negation indicator, but it's even far less constrained than the CDA/V3 negation indicators were (at least without specific profiling), and I have some concern that we'll end up seeing similar issues using that approach. I think I would be more inclined to have the specificity (including negation or presence/absence) expressed in the 'code', which I think fits with Grahame's comment about usefulness for search. That can be done using pre-coordinated codes (as I mentioned earlier) or it could be with post-coordinated expressions (to the extent that you or anyone wants to and is able to support them). And either way that keeps the meaning in one place rather than distributing it with potentially divergent lines of division across two elements, which I think was the most useful and compelling point of the TermInfo guidance.
David Waters (Nov 16 2018 at 10:38):
@Rob Hausam Yes, pattern 3 is as you say. At the risk of reopening something which is well known - what were the issues from CDA/V3 that you are concerned about?
With regard to profiling, we are intending to profile the set of observations/similar that are relevant to the triage use case
Are your concerns/issues about the general advisability of pattern 3, or its specific applicability to the triage use case?
Last updated: Apr 12 2022 at 19:14 UTC
