FHIR Chat · Consent Scope Codes

Why has the concept for Advance Care Directives (adr) that's required for Advance Directives in the IPS IG and available here...
http://terminology.hl7.org/CodeSystem/consentscope
been removed from this version...
http://hl7.org/fhir/R4/codesystem-consent-scope.html (used by the FHIR Validator).
Also - as the binding strength is extensible (http://hl7.org/fhir/R4/consent.html) - I think that the FHIR Validator should return a Severity Level of 'Warning' rather than 'Error' for the code 'adr'.

David Pyke (Apr 12 2021 at 12:41):

The Advance Directives scope has been removed from the Consent resource. If you are using it for a treatment based consent (such as DNR), it is better to put it as a deny based treatment consent, rather than using it for ADR. If you are using a different type of ADR, you may be interested in the PACIO ADR FHIR IG being created

Julian Sass (Apr 12 2021 at 16:24):

I'm confused by this too. When I check the ValueSet on Consent.scope in the core spec, 'adr' is included in the expansion. The CodeSystem description here: http://hl7.org/fhir/R4/codesystem-consent-scope.html still mentions four codes (and should probably say codesystem instead of value set).

Peter Jordan (Apr 12 2021 at 20:54):

David Pyke said:

The Advance Directives scope has been removed from the Consent resource. If you are using it for a treatment based consent (such as DNR), it is better to put it as a deny based treatment consent, rather than using it for ADR. If you are using a different type of ADR, you may be interested in the PACIO ADR FHIR IG being created

As that cannot be applied retrospectively, that Advance Directives Scope remains for R4 and R4B and therefore the Validator should not be returning errors or warnings when it's used in Consent Resources contained IPS instances based on those versions of FHIR. @Grahame Grieve @Rob Hausam

Richard Townley-O'Neill (Mar 31 2022 at 01:28):

HL7 AU also has this problem.
An issue as raised in November 2011 by @David Pyke to address this UP-255 but there has been no progress.
What is the way forward to representing advance care directives in R4?
@Grahame Grieve @Rob Hausam

Richard Townley-O'Neill (Mar 31 2022 at 01:30):

We want to use this in a national specification soon.

John Moehrke (Mar 31 2022 at 12:55):

@David Pyke ?

David Pyke (Mar 31 2022 at 12:56):

I have been pushing to find out next steps to fix it. Messaging lots of people, so far, no response

Rob Hausam (Mar 31 2022 at 15:47):

Do we need to move UP-255 ahead? If so, the first thing to do is move it from "Environment Setup" to "Proposal Draft". Nothing will happen until that is done. Then you can look for people to review and vote on it.

Marc Duteau (Mar 31 2022 at 19:48):

Looking at the submitter permissions list, I see you're not on there. If you've already requested submitter permissions via the confluence form and it just hasn't gone through, my apologies as we've been having issues getting the notifications forwarded to me. Whether you have made the request or not I've added you as a submitter.

The next steps can be found here https://confluence.hl7.org/display/VMAH/Create+a+Proposal at step 12.

For actually making the changes whoever is doing that (presumably you @David Pyke?) will need to make sure they've got Sourcetree installed (instructions are on this page https://confluence.hl7.org/pages/viewpage.action?pageId=91995484) and then make the changes in the xml files. Unfortunately we don't have a user friendly interface for doing that right now, but obviously the documentation here helps make it slightly less painful: https://confluence.hl7.org/display/VMAH/Specifying+the+Details+Inside+the+Proposal.

If you have any questions, concerns, or just need to vent about the process being frustrating feel free to reach out to me here in Zulip or at Marc@hl7.org.

David Pyke (Mar 31 2022 at 19:53):

Thank you! I'll see about doing the next steps!

Grahame Grieve (Mar 31 2022 at 22:39):

As that cannot be applied retrospectively, that Advance Directives Scope remains for R4 and R4B and therefore the Validator should not be returning errors or warnings when it's used in Consent Resources contained IPS instances based on those versions of FHIR.

@Peter Jordan that's an interesting question. This is probably my fault, but I don't have an easy way to resolve it. A terminology in THO overrides any same definition in the base spec - that's how we set it up in order to get THO out without breaking changes. Only it turns out that this particular breaking change is allowed.

Grahame Grieve (Mar 31 2022 at 22:45):

where a code was removed from the code system in THO after it was balloted into use in R4. UTG should fast track this

Robert McClure (Apr 01 2022 at 14:53):

@David Pyke Pinging again on this. Like all UTG proposals, this does not go anywhere unless someone does all the work of creating the content changes in GIT for a change in THO. Given this was an error I agree it needs to be done more quickly - but per HL7, that means a volunteer.

Also, given that it seems that adr is still intended to be retired for current use this highlights a number of the current failings in our versioning and publishing. Technically what needs to be supported is to properly version the Consent Scope code system with adr in the code system as ACTIVE and that version of the code system needs to be used for the value set referenced in R4/R4B.

Then, we need to have a "newer" version of the code system - in THO - that retires adr it should not just disappear!. Here is where I get to point out that the publisher does not display code status in rendering value sets, and a value set that is "all codes" in the code system will expand to include retired codes. So a value set version that uses "latest" version of the code system, such as those for R5/CI will still show adr in the expansion - it just will be retired and you will not be able to tell.
@Marc Duteau @Rob Hausam

David Pyke (Apr 01 2022 at 15:05):

I'm happy to volunteer to put in the fix, I just didn't know how to get enabled to make the change. I can do it over the next few days

Rob Hausam (Apr 01 2022 at 15:10):

@David Pyke Let any of us know if you run into any issues or have questions with navigating through the process.

David Pyke (Apr 01 2022 at 15:16):

Thank you, will do

Grahame Grieve (Apr 01 2022 at 20:10):

the publisher does not display code status in rendering value sets

This is true. It does display that when rendering code systems. So, @Robert McClure you think that it should? Do others think so? That implies (for me, at least) that the status properties go in the expansion. And we don't really have a standard status property...

Robert McClure (Apr 01 2022 at 20:25):

Grahame Grieve said:

the publisher does not display code status in rendering value sets

This is true. It does display that when rendering code systems. So, Robert McClure you think that it should? Do others think so? That implies (for me, at least) that the status properties go in the expansion. And we don't really have a standard status property...

In short, yes. Especially because we have determined that in general expansions yield concepts independent of status unless specified and the default is "all statuses". This is become an issue for in eCQMs because in part, we are fixing "goofs" or improving understanding and concepts are being retired but the change is not evident in the expansion.

Michael Lawley (Apr 01 2022 at 20:42):

Yes, I am with Rob on this - the code needs to be retired not removed

Michael Lawley (Apr 01 2022 at 23:54):

http://hl7.org/fhir/R4/codesystem.html#status attempts to define a standard status property, but then the associates codesystem goes in a different direction, not defining the status code http://hl7.org/fhir/concept-properties#status and instead defining inactive and deprecated properties (the latter should be deprecationDate)

Grahame Grieve (Apr 02 2022 at 11:48):

yes this part is a mess

David Pyke (Apr 04 2022 at 15:23):

I have submitted a pull request against UTG, following the published procedure

Marc Duteau (Apr 04 2022 at 18:07):