Stream: terminology
Topic: ServiceRequest.reasonCode for "suspected" or "rule out"?
Josh Mandel (Jun 07 2019 at 14:22):
In the Argonaut PAMA project, we're using a ServiceRequest to convey an imaging order (e.g., cardiac MRI) and providing a .reasonCode to indicate the reason for the imaging study. Is it common/good practice to use a code meaning "Congenital heart disease" (rather than "Suspected congentital heart disease") to convey a reason?
Josh Mandel (Jun 07 2019 at 14:22):
@Gay Dolin FYI, since the example is yours and my initial thought was "wait, this patient doesn't necessarily have the disease".
Robert McClure (Jun 07 2019 at 15:08):
It is my opinion that expecting "suspected" or some such almost anywhere is very problematic. WRT this specific need in the reason code for a test (imaging study) it should not be expected for two reasons: 1) We should discourage implementers from attempting to convey such a complex and temporally fluid nuance in a single code in a single slot, particularly this slot; 2) the combinatorial explosion problem.
Josh Mandel (Jun 08 2019 at 03:45):
So @Robert McClure just to make sure I understand the conclusion, you'd recommend just using the code for "Congenital heart disease," and systems interpreting a .reasonCode need to know "sometimes the code found in this slot refers to actual issues and sometimes to suspected issues, depending on context"?
Grahame Grieve (Jun 08 2019 at 04:40):
we can code that kind of thing into the definition of the element, though we haven't actually done it anywhere yet
Josh Mandel (Jun 09 2019 at 01:38):
Meaning, documenting the definition to this element as "either a condition that is the reason for the service request, or a suspected condition (coded directly, without the suspected qualifier) that the service request is intended to evaluate"?
Robert McClure (Jun 09 2019 at 18:03):
@Josh Mandel @Grahame Grieve This situation is a basic aspect of what we call the information model-terminology intersection meaning that part of the knowledge exchanged is reflected by the model, and part is encoded within the instance terminology. What we create locks that stuff down and part of the dilemma is deciding how much is left to human interpretation of the combined model + terminology semantics. The amount of interpretation required is directly related to how tight the model is to a single interpretation. In your example if you must distinguish suspected from already confirmed conditions, then you are going to force data entry to either find model elements that differentiate among those two options (perhaps adding a condition status) or expect the terminology to carry all this information using pre or post coordination. No matter what, data entry consistency is always going to be an issue.
I suggest looking at this a bit differently. I think it is improper to assume that the time-sensitive nuance of confirmed, suspected, please rule this out, resolved, is there evidence of, etc., should be encoded in a test reasoncode. Instead that sort of information should be found elsewhere. Either in the associated condition resource, or in clinical narratives that the interested tester can retrieve and read. reasonCode is a small window into why the test is ordered - a very important one - but a window that does not carry all the nuance you are asking about.
Josh Mandel (Jun 09 2019 at 18:10):
This assessment makes sense-- but realistically we are talking about conveying a bit of information that a clinician typically provides with a single field at ordering time, if I understand correctly -- basically a pick list or a free text entry box. There is not a lot of detailed information entry happening, so it is not clear to me that it would be realistic to populate a detailed Condition resource, etc.
Rob Hausam (Jun 09 2019 at 18:41):
I agree with Josh on that. What Rob M. says I think is essentially correct technically, but I'm not sure if the conclusions drawn from it are entirely warranted or practical. The use of "reason for order" (coded or otherwise) is pretty much as Josh describes. And we have to acknowledge Rob's comment about the intersection of the information and terminology models - and my take from that is that if you populate a "reason" element that doesn't specify the additional semantic of "suspected" (or whatever one is desired) with a code or expression that also doesn't specify that additional semantic, then what you are saying is that the reason for the order is the presence of the actual condition as would normally be understood by specifying that code. It can't mean anything else, and if that's not your actual intended meaning then you shouldn't be trying to say it that way. On the other hand, I think it's very common and very legitimate and likely quite necessary to be able to say that a "suspected" (or "rule out") condition is the reason for an order. So, given what we've said, I think that gets us back to the place that we either (1) need to use single codes or expressions that convey this "suspected" or other semantic, or (2) we need specialized model elements that provide that semantic when populated with otherwise unqualified condition codes, or (3) we are then in a position where we would have to say that you can't code these kinds of reasons at all and would have to require (somehow) that they be recorded using only free text. If there are other viable alternatives, I must have missed them. Of those options, I think that #1, using codes or expressions for the "suspected" conditions, may actually end up being the least bad choice in many or most cases.
Robert McClure (Jun 09 2019 at 22:34):
@Rob Hausam Not sure how you disagree with my assessment then lay out the same options. But, I strongly disagree that the "least bad choice" is to create 1000's of new pre-coordinated codes for all the possible condition+status ideas that will need to be communicated. And then are you confident that everyone will always communicate the universally understood correct condition+status? Remember tests are used to investigate all sorts of conditions to determine all sorts of disease states and investigative states. Why force everyone to enter this level of detail? Sure if it's an available code and it currently fits, use it, but I think "the least bad choice" is to leave the code to communicate a condition that could include the current disease status/state, but likely will not and not push to add even more pre-coordinated status+condition codes that will not be reliably used anyway.
@Josh Mandel I'm not saying you need to also reference a current condition resource, I'm just saying use it if it's there so the tester can find it to do a bit more investigating if possible.
Josh Mandel (Jun 09 2019 at 22:52):
The other practical note here is that these pre-coordinated codes do not really exis for most conceptst. I want to provide some guidance on using standard coding systems like SNOMED CT, and that means working with releases as they actually exist today.
Josh Mandel (Jun 09 2019 at 22:53):
Even if I was going to model this using a condition resource, I am not totally clear on how to convey a suspected status. http://build.fhir.org/valueset-condition-ver-status.html clued's the concept of unconfirmed, but this is quite different from suspected -- and farther from "rule out" (which really requires the context of a diagnostic procedure to make any sense).
Josh Mandel (Jun 09 2019 at 22:54):
Maybe "provisional" or"differential" is the closest thing.
Josh Mandel (Jun 09 2019 at 22:58):
Bottom line, I wouldn't mind explicitly updating the information model in reasonCode to also include a flag for "suspected"/provisional -- but practically speaking, just leaving the semantics blurrier per @Grahame Grieve is probably more realistic. (Still, ambiguity is exactly what gets people into situations like @Dave deBronkart , where suspected-conditions appear to be documented as conditions)
Lloyd McKenzie (Jun 09 2019 at 23:04):
My leaning is that if you just specify a code as a reason, then it exists only in the context of the thing it's the reason for - and is somewhat fuzzy. If you want to specifically assert a Condition (suspected or not), then that should be a separate resource instance. And there, I'd expect non-fuzziness.
Grahame Grieve (Jun 09 2019 at 23:35):
having once worked in a lab, I witness that "suspected X" (or "X?")is very different to "treatment of X" but we did get just plain "X" in the clinical notes. Still I thought of that different to X?
Robert McClure (Jun 09 2019 at 23:43):
@Lloyd McKenzie has it right. A treatment request is not where a clinician documents the status of a condition. No one should be pulling a reasonCode off a treatment request and using that as some sort of condition statement. It exists solely within the context of the request and no one should use that as a document of actual patient conditions. It is a context-bound piece of hopefully helpful information.
Grahame Grieve (Jun 10 2019 at 12:16):
but equally, it can be treated as a statement of truth by the service provider. E.g. if you tell me that the patient is HIV+, I'll behave as if the patient is
Lloyd McKenzie (Jun 10 2019 at 16:09):
I'd phrase it as "if you say you did something because the patient is HIV+, I'll behave as if the patient might be" - or at least that's what I think should be the case. We should probably clarify some descriptions to make those assertions clearer though.
Michael Lawley (Jun 10 2019 at 16:15):
My general guidance for @Josh Mandel on using SNOMED CT for cases like this is that you avoid the Situation With Explicit Context (SWEC) hierarchy if at all possible; qualifiers of suspected, negation, etc really belong in the information model (ie the context provided by the Resource itself), and SWEC concepts should only be used when you absolutely have to pack all the context into a single code.
Rob Hausam (Jun 10 2019 at 16:33):
I think that approach may be fine, and it may very well be better - as long as we don't get a proliferation on the other side of too many specialized information model elements that are intended to do essentially the same thing, but with a specialized semantic. It's a tradeoff, and I don't think there's necessarily a clear or absolute right and wrong.
Grahame Grieve (Jun 10 2019 at 17:34):
Michael's advice implies that we should have investigationOf and inThePresenceOf instead of reasonCode
Rob Hausam (Jun 10 2019 at 17:41):
I'm not real excited about those names - they don't seem very obvious - but the idea should work (particularly if those are the only ones that we would need).
Gay Dolin (Jun 10 2019 at 18:40):
HI. I basically agree with what @Robert McClure is saying here that the workflow of ordering that is not where all the nuances of the Condition (or possible condition) can be expected to be found .. I also agree with what @Josh Mandel states, there are relatively few precoordinated "suspected xx" (huge combinatorial explosion.. If more the detail information is needed then ConditionResource with the correct verificationStatus would be conveyed. I like the idea that @Grahame Grieve states for investigationOf in the model ... EHRs probably capture that in various ways during the ordering process... (This is like a "Planned Procedure" with a Contained RSON "Indication" template in C-CDA :-)
Grahame Grieve (Jun 10 2019 at 18:47):
I'm not tied to the names, just that this is the basic emerging idea here
Josh Mandel (Jun 10 2019 at 21:07):
Agreed -- naming aside, would be nice to have the "suspected" semantics represented in the equivalent of an investigationOf[CodeableConcept] element.
Robert McClure (Jun 11 2019 at 14:18):
I'm unconvinced that we need "investigationOf" or any such detail. As a clinician I'm absolutely in support of including what condition is triggering the request, but details of if it's confirming, following the progress of, assessing stage of therapy, or any other aspect is something that is very rarely something that is easily conveyed in a single phrase. It is also rarely I believe, of importance to the test-doer. When it is, something more expansive should be provided - a condition resource, a text note, a call! If the test-doer is independently interested in the patient's condition - look at the record - that is what we have done, is it so different in FHIRlandia? I'm particularly concerned about what the name of this special context element would be because I see this causing all sorts of confusion - telephone game-like. Where do I put what ever gets chosen to represent hip replacement (or osteoarthritis) when ordering a bleeding time if I'm using heparin to anticoagulant during the post-surgical period? How about PSA level after prostate surgery - is that investigating recurrence or confirming status?? I'm strongly suggesting you are not in the 80% here!
Eric Haas (Jun 12 2019 at 15:31):
changing element names is big deal and breaks everthing, I don't think this discussion has convinced me that its worth it, clarify in the definiitions, add aliases but leave the element names stable.
Richard Townley-O'Neill (Jun 14 2019 at 04:42):
Idea: Add an extension called natureOfReason that qualifies reasonCode with an extensible binding to a ValueSet that includes the values "investigation of" and "in presence of".
Grahame Grieve (Jun 18 2019 at 00:13):
having worked in a lab, I can assure that ?[disease] is absolutely in the 80% for diagnostic orders. As is just the bald statement "[disease]"
Last updated: Apr 12 2022 at 19:14 UTC
