Stream: implementers
Topic: Condition.clinicalStatus
Jason Teeple (Sep 24 2020 at 16:19):
In the situation when a source system does not have a status for Condition.clinicalStatus the USCore IG states: If one of these a status code is missing, a 404 http error code and an OperationOutcome SHALL be returned in response to a query for the resource.
Should the Condition resource even be populated in your data store and subsequently the API? The above says no. So if requests for:
baseURL/Condition/abc123
baseUrl/Patient/1234/Condition
baseURL/Condition?patient=1234
All requests throw a 404 and OperationOutcome, correct?
*And would the same apply to ePDX?
Daniel Venton (Sep 24 2020 at 17:33):
We have the same essentially the same question, particularly around the search operation returning a Bundle. The server finds multiple Conditions (say 20) but 1 of them doesn't have a clinicalStatus. The server is supposed to return a 404, no data because 1 resource can't be valid? Meaning that we refuse to return 19 good resources because there is one bad one.
I understand it for a read operation, there are no valid resources for that id-404. What if I had a List of Condition references. Should the list exclude the condition reference because it can't be hydrated or should the List return a 404 because one item in the list can't be filled? What about Compositions, does this invalid status item get used there? What if it's in the narrative but not a discrete resource?
I realize it's hard to dictate how EHR's handle their data internally. But wouldn't it be better served to return all the data that is in the chart, regardless of status and let it be a schematron error, resource missing required data "status" than try to cover all the situations of 404 here, but not here unless this then 404 except when .....
Lloyd McKenzie (Sep 24 2020 at 19:16):
@Brett Marquard @Eric Haas
Brett Marquard (Sep 24 2020 at 19:35):
Are you seeing 404 for clinicalStatus? My understanding is this missing is an error condition on the server -- @Drew Torres @Danielle Friend can comment on their support.
Danielle Friend (Sep 24 2020 at 21:24):
We should always have a clinicalStatus for US Core conditions. From looking at the code I don't see a way we would ever wind up in a spot without a status. But, if something somehow went wrong that we didn't have a status for a condition, we do not throw an error, we would return the resource without clinicalStatus populated. For what its worth - the 5+ years we've supported Condition, we haven't had this issue come up.
Danielle Friend (Sep 24 2020 at 21:26):
Would a data absent reason be a valid alternative here? Say if we did have this issue came up and we needed to log an error for an empty clinicalStatus.
Jason Teeple (Sep 25 2020 at 11:06):
Danielle Friend said:
We should always have a clinicalStatus for US Core conditions. From looking at the code I don't see a way we would ever wind up in a spot without a status. But, if something somehow went wrong that we didn't have a status for a condition, we do not throw an error, we would return the resource without clinicalStatus populated. For what its worth - the 5+ years we've supported Condition, we haven't had this issue come up.
I suspect missing clinicalStatus would happen more with Payers pulling clinical data out of UM/CM systems. We may know you have a condition and may not know the status of the condition. This is problematic for a Payer when following the USCore IG.
Jason Teeple (Oct 08 2020 at 17:17):
Jason Teeple said:
Danielle Friend said:
We should always have a clinicalStatus for US Core conditions. From looking at the code I don't see a way we would ever wind up in a spot without a status. But, if something somehow went wrong that we didn't have a status for a condition, we do not throw an error, we would return the resource without clinicalStatus populated. For what its worth - the 5+ years we've supported Condition, we haven't had this issue come up.
I suspect missing clinicalStatus would happen more with Payers pulling clinical data out of UM/CM systems. We may know you have a condition and may not know the status of the condition. This is problematic for a Payer when following the USCore IG.
@Eric Haas @Brett Marquard Do you know if other Payers have raised similar questions?
Brett Marquard (Oct 08 2020 at 18:29):
UM/CM systems? How do those systems receive clinical information?
Eric Haas (Oct 08 2020 at 18:45):
What is the issue with US Core? the invariant constraints for clinicalStatus are inherited from FHIR Core. So "This is problematic for a Payer when following the FHIR specification." is more accurate
Jason Teeple (Oct 08 2020 at 18:51):
Brett Marquard said:
UM/CM systems? How do those systems receive clinical information?
A payer generates clinical data in their Utilization and Case Management systems. For example, a Payer could be coaching a member on a diabetes management. Another potential stream is data in support of a prior auth request.
Jason Teeple (Oct 08 2020 at 18:53):
Eric Haas said:
What is the issue with US Core? the invariant constraints for
clinicalStatusare inherited from FHIR Core. So "This is problematic for a Payer when following the FHIR specification." is more accurate
Yes, that is probably a more accurate statement.
Brett Marquard (Oct 08 2020 at 19:13):
maybe the UM/CM should capture the Status :)
Jason Teeple (Oct 08 2020 at 19:22):
Brett Marquard said:
maybe the UM/CM should capture the Status :)
That would help. :)
In situations when we are the receiver of data or condition is created out of a prior auth request, it is difficult to determine status.
Eric Haas (Oct 08 2020 at 22:25):
This is interesting and useful background. I am going to use this use case in a guide I am authoring!
Jason Teeple (Oct 09 2020 at 11:29):
Jason Teeple said:
In the situation when a source system does not have a status for Condition.clinicalStatus the USCore IG states: If one of these a status code is missing, a 404 http error code and an OperationOutcome SHALL be returned in response to a query for the resource.
Should the Condition resource even be populated in your data store and subsequently the API? The above says no. So if requests for:
baseURL/Condition/abc123
baseUrl/Patient/1234/Condition
baseURL/Condition?patient=1234
All requests throw a 404 and OperationOutcome, correct?
*And would the same apply to ePDX?
@Pat Taylor @Amol Vyas @josh lamb Any idea how other payers are supporting clinicalStatus in USCore or ePDX? (sorry for bringing you into a non-CARIN 4BB topic)
My thought is that we do not return a clinicalStatus if one does not exist for AllergyIntolerance, Condition, DocumentReference, Immunization, or Goal.
Michele Mottini (Oct 09 2020 at 12:44):
At the moment being we (=Anthem) are ignoring that US core requirement and so sometimes return no clinical status. We are planning to add a flag to our server so that we can generate fully compliant output for the end points / clients that require it (at the cost of not exposing all the data)
Daniel Venton (Oct 09 2020 at 13:50):
I'm working for a payer as well (UHC). We are flipping between... Option 1: Always setting the status to "active" because if it wasn't active then why was treatment provided? Option 2: Not providing Condition resources at all, because we've been told we don't need to expose clinical data that is derived from claims (CMS). We will provide the claim itself.
Jason Teeple (Oct 09 2020 at 17:39):
Depends on the source of your data. If you are sourcing clinical data from claims, you can assume the condition is active. However, if you source data from authorizations, you cannot definitively state active or not unless you see a claim. Because an authorization request can be made, but the patient may never act on it.
Daniel Venton (Oct 12 2020 at 13:49):
You could assume that the condition was active at the time of the claim. But if the claim was for the cure, then you'd have to assume that the condition was resolved right? This is the problem with assumptions, there's always a case where the blanket assumption is wrong.
Last updated: Apr 12 2022 at 19:14 UTC
