Stream: argonaut
Topic: Problems vs. Concerns
Josh Mandel (May 12 2016 at 12:00):
In http://argonautwiki.hl7.org/index.php?title=Problems we suggest using category=problem to identify "problems" in the MU3 sense. This seems okay, but then we say that the data should have a coding like:
system: http://hl7.org/fhir/condition-category code: problem
and that's an issue because http://hl7.org/fhir/condition-category doesn't include problem as a code. There's no reason we need to bind to http://hl7.org/fhir/condition-category, but we can't pretend it contains codes that it lacks.
Josh Mandel (May 12 2016 at 12:23):
@Michael Donnelly @Isaac Vetter https://open.epic.com/Clinical/Condition# describes (and indeed, open-epic's server responds to) a parameter called clinicalStatus -- but this should be clinicalstatus (all lower case). In general, FHIR search params are always all lower case (sometimes they have dashes; I'm not sure why this one doesn't, to be honest. Will ask on the implementers chat.)
cc @Erik Wiffin
Grahame Grieve (May 12 2016 at 12:47):
i think that's an ooops - should we resolve by adding to the hl7 code system or picking a different code system>
Josh Mandel (May 12 2016 at 13:03):
Adding to HL7 is "easier" for us, but I'm really not sure what the heck the difference is between complaint, symptom, finding, diagnosis, problem — and in particular, I think they should all be included in an MU3 "problem list".
Josh Mandel (May 12 2016 at 13:04):
Actually I wonder if argonaut can "combine" the "problem" and "concern" data categories into a single response (GET /Condition?patient=123) the same way we combine 6 "categories" of name, birth sex, birthdate, race, ethnicty, preferred language into a single response (GET /Patient/123)
Josh Mandel (May 12 2016 at 13:04):
Sure would make things easier, and I don't see why it should be disallowed in the EHR certification/testing process.
Michael Donnelly (May 12 2016 at 13:08):
I'll write a QA note for Epic's bug.
Michael Donnelly (May 12 2016 at 13:22):
Ah - it isn't our resource, it's just the web page. If you hit the raw URL instead of curling it from the page, it works.
Michael Donnelly (May 12 2016 at 13:22):
Michael Donnelly (May 12 2016 at 13:22):
(We'll fix the page)
Josh Mandel (May 12 2016 at 13:24):
Cool! Yeah, I tried the lowercase in the web page and it defensively prevented me. BTW, the error (~"read our docs") could be better ("parameter clinicalstatus does not exist").
Michael Donnelly (May 12 2016 at 13:24):
Agreed.
Josh Mandel (May 12 2016 at 13:24):
;-)
Michael Donnelly (May 12 2016 at 13:24):
In partial defense, that's a problem with the open.epic web site and not the FHIR implementation.
Josh Mandel (May 12 2016 at 13:25):
Oh, totally. And also in your defense, SMART's server basically barfs anytime it sees anything slightly imperfect.
Michael Donnelly (May 12 2016 at 13:25):
Hit https://open-ic.epic.com/FHIR/api/FHIR/DSTU2/Condition?patient=Tbt3KuCY0B5PSrJvCu2j-PlK.aiHsu2xUjUM8bWpetXoB&category=diagnosis&clinicalstatus=inactive&foo=bar and it ignores the bad parameter.
Michael Donnelly (May 12 2016 at 13:25):
:)
Josh Mandel (May 12 2016 at 13:25):
Um, when I hit your link I see
The resource request contained an invalid parameter.
Josh Mandel (May 12 2016 at 13:27):
But the message ("Invalid Value: INACTIVE") is helpful
Josh Mandel (May 12 2016 at 13:30):
Just an example bug -- active is a valid code and inactive isn't, per http://hl7-fhir.github.io/valueset-condition-clinical.html
Michael Donnelly (May 12 2016 at 13:30):
Ah, I was talking about the inclusion of a bogus parameter (foo=bar).
Josh Mandel (May 12 2016 at 13:30):
Yup
Josh Mandel (May 12 2016 at 13:30):
It sure was a confusing way to prove your point though :p
Michael Donnelly (May 12 2016 at 13:30):
Michael Donnelly (May 12 2016 at 13:30):
True
Josh Mandel (May 12 2016 at 13:30):
That's better.
Josh Mandel (May 12 2016 at 13:43):
Actually it's entirely clear from https://www.healthit.gov/sites/default/files/2015Ed_CCG_g8-Application-access-data-category-request.pdf that we are free to group "problem" and "concern" in a single API call:
• The Common Clinical Data Set (CCDS) definition lists a set of data. It does not, however, specify a set of “data categories” or prescribe a predefined grouping for API responses as may be implied by the regulatory text.
• Consistent with the intent expressed for this functionality in the proposed rule [80 FR16861], which conveyed that we intended to “allow for but not require, health IT developers to implement the Fast Health Interoperability Resource (FHIR®)” and which we carried forward with the final rule, a health IT developer is permitted and has the flexibility to group the data specified in the CCDS in its API responses in a manner that it sees fit. This could be in manner
Jenni Syed (May 12 2016 at 15:16):
@Josh Mandel I know @Michelle (Moseman) Miller has always said concern is a superset of problem and diagnosis. If you don't pass any category into our server, you would get all. For MU3, we'll mark them all as different categories.
Jenni Syed (May 12 2016 at 15:17):
As to adding to the valueSet (problem and concern?) vs rolling our own: adding to the core works for STU3, but it wouldn't affect DSTU2 - correct?
Josh Mandel (May 12 2016 at 15:17):
For MU3, we'll mark them all as different categories.
Yes, that's just right. And when you get certified, you can show just one API call.
Michelle (Moseman) Miller (May 12 2016 at 22:18):
Part of the intent behind the expanded Condition.category value set stemmed from an Argonaut discussion around Condition.code value sets. Typically, the category = diagnosis would have an ICD-X value set, category = problem would have a SNOMED value set, and category = (additional/patient) concern often results in freetext only (Condition.code.text). Thus, having these categories allowed us to be more prescriptive about Condition.code value sets depending on the context and use case. Definitions were proposed https://github.com/argonautproject/implementation-program/issues/35#issuecomment-216083706, such that in this Argonaut IG context, concern was defined as the non-provider concerns.
Last updated: Apr 12 2022 at 19:14 UTC
