Stream: IPS
Topic: Condition Category Code
Peter Jordan (Sep 23 2020 at 23:37):
Why does the IPS Profile on the Condition Resource use an alternative ValueSet for the category - i.e. one that contains a single LOINC Code (75326-9 ), rather than 'problem-list-item' from http://hl7.org/fhir/ValueSet/condition-category? Is the later not considered to be a 'suitable code'? @Rob Hausam
Rob Hausam (Oct 19 2020 at 02:09):
That's actually a quite interesting question, @Peter Jordan - in a few respects. The basic idea for that decision I think was twofold. First, wherever and whenever possible we were attempting to specify recognized standard terminology, and at the time that we made the decision the base resource binding to the condition-category value set was only an example, with those codes appearing to be rather ad hoc and with no particular requirement or expectation for their use. And second, the reason that we chose to use a single LOINC code for "Problem" in the value set, but with an extensible binding to also allow other options if needed, was that this was for use in the IPS Problems Section and we felt there was not a good reason generally for items that were not considered to be a clinical problem to be included in the Problems section of a patient summary (restating that the IPS is not intended to be and will not necessarily represent the entire EHR).
But now comes the interesting wrinkle in this. As I said, the binding of Condition.category to the condition-category value set was example, and that was the case for the first 4 publications of R4 through 3.5a.0. But then in the final R4 release the binding was changed to extensible - and, even though I attend the Patient Care WG calls nearly every week, I don't recall having heard any discussion about that and somehow I completely missed that change until right now. And the upshot that I see of it is that with the binding now being extensible, the published IPS specification is technically non-conformant in this with the FHIR R4 release. That might mean that we need to add this to the IPS technical correction that we are working toward. But I also wonder if the change from an example to an extensible binding for a category element in the base standard was either intended by PCWG or is even technically correct? @Michelle (Moseman) Miller? @Giorgio Cangioli may have some further thoughts on all of this. And I guess we'll have to see how it further plays out.
Peter Jordan (Oct 19 2020 at 03:22):
Thanks for that comprehensive reply, @Rob Hausam . At present, placing that LOINC Condition.category code in the IPS results in the following warning from the FHIR Validator (and Inferno)...
Invalid Code None of the codes provided are in the value set http://hl7.org/fhir/ValueSet/condition-category (http://hl7.org/fhir/ValueSet/condition-category), and a code should come from this value set unless it has no suitable code)
BTW: there is a similar issue with the Codition.severity code, although the severity level is 'information'.
Rob Hausam (Oct 19 2020 at 05:19):
Yes. Interestingly, I don't recall seeing that particular warning on Condition.category while we were working to get IPS published - but the Validator and IG Publisher have been evolving rapidly! :) We certainly have to sort this issue out.
Giorgio Cangioli (Oct 19 2020 at 07:56):
Most of these differences come from the facts that the IPS has a CDA and FHIR representation and that the CDA has been the first guide developed. In most existing CDA IGs LOINC or SNOMED codes are used/recommended and this is the choice followed also in our IPS CDA guide. We tried then not to have different value sets for the two guides.
Rob Hausam (Oct 19 2020 at 13:24):
Thanks for adding that clarification, @Giorgio Cangioli. I wasn't recalling that aspect when I replied, but that's absolutely correct. We were following the principles that I described initially when we developed the CDA IG and then carried that into FHIR (because when we did that the example binding allowed us to do that without a problem).
Michelle (Moseman) Miller (Oct 19 2020 at 15:43):
Here is the JIRA that approved a change in the Condition.category binding strength: J#18833. More details in the JIRA, but it seems to boil down to the category binding strength was changed to extensible because the invariant (to require clinicalStatus) was only applicable to problems only. In order to know when the condition was a problem (for invariant), it needed an extensible binding strength.
(FYI: @Rob Hausam it was voted on during the Oct 2018 WGM)
Rob Hausam (Oct 19 2020 at 16:04):
I figured you would find that quickly (quicker than I would), @Michelle (Moseman) Miller. I'm still not recalling this discussion and decision, so I assume that I probably wasn't there (at least during the WGM session when it was decided). Do you have a link to the WGM minutes that you can post? This decision turns out to be problematic for IPS (which is sponsored by PCWG - although I think it may still have been sponsored by SDWG at that time), and I wonder if it doesn't also cause other issues? I also note some weirdness in the issue description, as it's about Condition.clinicalStatus but then it says that "It would mean that this allergyIntolerance cannot be communicated if the current status is unknown".
Michelle (Moseman) Miller (Oct 19 2020 at 22:55):
Discussion notes are captured within the JIRA itself, J#18833. The submitter was present during the discussion since the submitter made the motion, so I think the condition/allergy confusion was likely a typo since the JIRA comment outlining options were all focused on conditions.
Rob Hausam (Oct 20 2020 at 03:25):
Thanks, @Michelle (Moseman) Miller. The discussion in the Jira issue goes into considerable detail about the pros and cons of the sever options, but then (at least in my reading) seems to say apparently nothing about the rationale for narrowing those options to the decision that was actually made and then applied. Can we add it to a PC FHIR call agenda for further discussion, and figuring out how to deal with the issue that it raises for IPS?
Michelle (Moseman) Miller (Oct 22 2020 at 22:34):
Following the Patient Care discussion today:
- We recommend in R4 that IPS use both the CDA LOINC code + FHIR problem-list-item code (since category is a CodeableConcept)
- Going forward in R5, we are considering whether to edit the invariant to always require clinicalStatus (when not entered in error) regardless of category – since it is only a guideline, we don't need the category = problem-list-item part of the invariant
- Pros/cons of other options documented in the meeting minutes: https://confluence.hl7.org/display/PC/2020-10-22+Patient+Care+FHIR+Conference+Call
Peter Jordan (Oct 23 2020 at 02:16):
Thanks @Rob Hausam & @Michelle (Moseman) Miller . Presumably, IPS implementers can take the same, dual coding, approach for condition.severity (LOINC & FHIR in that case)? In both cases, the Validator is now happy!
Rob Hausam (Oct 23 2020 at 05:53):
Yes, at least for now, the dual coding approach will work in both cases. It isn't strictly necessary to do it for Condition.severity, as using the LOINC code alone is still conformant and the validation output for that is an Information message (not a Warning). For Condition.category the message is a Warning, and technically the instance is non-conformant without the additional condition-category problem-list-item code. So we need to add the problem-list-item code to our Condition profile and examples in the upcoming IPS technical correction (for the current R4-based IG). I'm not sure if we will want to add the SNOMED CT severity codes in the technical correction, as we intentionally did not use the SNOMED CT codes and instead chose LOINC (as it is universally available) - but we could discuss that. And yes, adding the additional codes in both cases does make the Validator happy and removes the warning and information messages.
Rob Hausam (Oct 23 2020 at 06:35):
Tracker J#29409 created.
Last updated: Apr 12 2022 at 19:14 UTC
