Stream: implementers
Topic: Condtion Resource
saran (Dec 09 2021 at 18:07):
Hi guys,
I've a question regarding the Condition resources in the US-Core profile.
If the Clinical-Status and Verficatation-status is unknown,
what should be the value that needs to be added to the above attributes to be conformant with the US-Core Condition profile.
Thanks in Advance
Daniel Venton (Dec 09 2021 at 20:02):
According to HL7 a condition cannot exist without a known clinicalStatus (unless the verification status is entered-in-error).
Yunwei Wang (Dec 09 2021 at 20:27):
According to US Core General Guidance Missing Data:
For the following status elements no appropriate “unknown” concept code is available, therefore the element must be populated:
...
Condition.clinicalStatus
...
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.
Lloyd McKenzie (Dec 09 2021 at 20:27):
Sort of. Technically, you can still specify a "dataAbsentReason" or some other extension and still satisfy the cardinality - but you may find challenges with interoperability if doing that.
saran (Dec 09 2021 at 21:39):
Thanks everyone for these inputs.
So in the below case, what would be the ideal fit to be conformant without having much Interoperability Challenges?
To give a little bit background of the condition resource being implemented,
we get the data from the Medicaid claims - the primary & secondary diagnosis is being converted to the Condition Resource,
unfortunately we don't have a way to map the Clinical-Status or Verification-Status since that information is not present. (Would it be okay to deduce that the Clinical-Status was active and Verification-Status as confirmed for the Claims that are paid and adjudicated? - just a thought.)
Vassil Peytchev (Dec 09 2021 at 21:48):
Would it be okay to deduce that the Clinical-Status was active and Verification-Status as confirmed for the Claims that are paid and adjudicated?
I think it might depend on how the resource is going to be used. Maybe consult a lawyer?
Vassil Peytchev (Dec 09 2021 at 22:23):
For example, wouldn't a claim be paid and adjudicated for services that result in the condition being ruled out? Or is that information present in the claim?
Lloyd McKenzie (Dec 09 2021 at 23:51):
@Michelle (Moseman) Miller
Daniel Venton (Dec 10 2021 at 13:04):
We took the same stance, since claims don't state clinical status or verification status of the diagnosis elements. We said, since the patient received treatment for the diagnosis we can assume that it's active (could be resolved in some cases). You could also take CMS guidance and NOT derive conditions from claims, making them just claim data not condition data. (I don't have the reference handy.)
Michelle (Moseman) Miller (Dec 12 2021 at 22:46):
This was recently discussed in Patient Care as a result of https://chat.fhir.org/#narrow/stream/294552-Patient-Care.20WG/topic/US.20Core.20Condition.20Status
Specifically, Patient Care focused on the invariant that intentionally only required clinicalStatus for problem list items (not diagnoses). This invariant had the claim use case in mind when updated in the base spec.
con-3: Condition.clinicalStatus SHALL be present if verificationStatus is not entered-in-error and category is problem-list-item (: clinicalStatus.exists() or verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status' and code = 'entered-in-error').exists() or category.select($this='problem-list-item').empty())
As such, Patient Care felt that US Core should update their textual guidance (e.g. http://hl7.org/fhir/us/core/StructureDefinition-us-core-condition.html#mandatory-and-must-support-data-elements) to be more consistent with the underlying invariant.
The status element has the following constraints: SHALL be present if verification status is not entered-in-error and SHALL NOT be present if verification Status is entered-in-error.
Michelle (Moseman) Miller (Dec 12 2021 at 22:48):
In sum, Patient Care doesn't endorse defaulting or inserting values for clinicalStatus since the field should have cardinality 0..1 and con-3 invariant isn't applicable for non-problem list items, like encounter diagnoses.
saran (Dec 13 2021 at 20:21):
This really helps, Thank you for providing a clarity to this.
Eric Haas (Dec 13 2021 at 21:22):
Lloyd McKenzie said:
Sort of. Technically, you can still specify a "dataAbsentReason" or some other extension and still satisfy the cardinality - but you may find challenges with interoperability if doing that.
That is not how we understand it for this conditionally required binding and the guidance there is normative.
Eric Haas (Dec 13 2021 at 21:24):
@Michelle (Moseman) Miller can post ballot comment against US Core?
Michelle (Moseman) Miller (Dec 13 2021 at 22:45):
@Eric Haas Sure thing, logged as J#34468
Last updated: Apr 12 2022 at 19:14 UTC
