FHIR Chat · Adding new codes as children to a deprecated code · terminology

Stream: terminology

Topic: Adding new codes as children to a deprecated code


view this post on Zulip Robert McClure (Sep 24 2021 at 18:04):

I have an interesting situation under consideration. tl:dr - I would like to add two new codes as children to a current code that I want to deprecate to encourage use of the two more specific codes while maintaining backwards compatibility to data using the old "parent" code. The intention would be that if/when EXPERIENCE is ever retired, the two new codes would be promoted to level 1 codes. Do we think this is acceptable?

The specifics involve ObservationValue code system, the _ObservationMeasureType hierarchy that was created, and is used by the quality measure community. There is a need to separate out (and clarify) using two new codes for each of PATIENT EXPERIENCE and PATIENT ENGAGEMENT distinct types of measures instead of using EXPERIENCE for either. But the EXPERIENCE concept has been in use and actually aligns with other documentation (in the US, the CMS blueprint) that will continue. By deprecating EXPERIENCE we signal to not use it anymore but we keep it available as a non-retired code for those that must use it.

I'm interested in comments on this approach. Also wonder if non CMS eCQM users (@Keith Boone SANER?) or @Virginia Lorenzi Patient Engagement have issues.

view this post on Zulip Rob Hausam (Sep 24 2021 at 18:23):

@Robert McClure I think it might be best to keep the parent code (not deprecate or eventually retire it?), for the historical data reason that you mentioned and maybe also for other potential use as a grouper, but mark it as http://hl7.org/fhir/concept-properties#notSelectable (i.e. "abstract"). In that case (assuming the terminology server supports it), it should show up in the value set expansion as expansion.contains.abstract = 'true' - which of course means that it shouldn't be used as the code in any new instances, and one of the child codes that you've added should be selected instead.

view this post on Zulip Robert McClure (Sep 24 2021 at 19:05):

@Rob Hausam Interesting suggestion. My primary concern is the frequency that "notSelectable" is ignored whereas Deprecated is a clear status - that admittedly can also be ignored. Still, that is a good suggestion.

view this post on Zulip Lloyd McKenzie (Sep 24 2021 at 19:37):

Note that you can yank a code from a value set without deprecating it in the code system.

view this post on Zulip Robert McClure (Sep 26 2021 at 14:33):

@Lloyd McKenzie good point, but the broader context of use for the CMS users includes generalizing to EXPERIENCE so best we keep it "in view" within the value set. I'm thinking Rob's suggestion is actually best - to make it abstract. Then perhaps once it's not used in the Blueprint, we remove it from the value set.

view this post on Zulip Michael Lawley (Sep 30 2021 at 02:59):

you could mark it as both deprecated AND abstract; then $expand calls with excludeInactive=true will ignore it

view this post on Zulip Virginia Lorenzi (Oct 04 2021 at 04:02):

You should ask quality @Floyd Eisenberg At NYP we have an entire division on Patient Experience and it doesn't mean the same as engagement or empowerment. My impression is in the US we have several programs that measure experience.

view this post on Zulip Floyd Eisenberg (Jan 31 2022 at 18:44):

Sorry for the delay in following up. We were waiting for further input. The measureType value set is incorporated into the ObservationValue code system, managed by Orders and Observations. So the change will require approval by CQI and OO. Discussion at the January 2022 WGM suggested that the current definition of Experience covers both patient experience and patient engagement. Experience definition: "A measure related to the level of patient engagement or patient experience of care." [https://terminology.hl7.org/CodeSystem-v3-ObservationValue.html#v3-ObservationValue-_ObservationMeasureType]. So the suggested approach is to make "patientExperience" and "patientEngagement" children of "Experience" and set "experience" as non-selectable; I.e., only the children should be selectable. Moreover, the definitions of the two new items need clarification. Suggestions: (1) Patient experience: "Patient experience encompasses the range of interactions that patients have with the health care system, including their care from health plans, and from doctors, nurses, and staff in hospitals, physician practices, and other health care facilities. As an integral component of health care quality, patient experience includes several aspects of health care delivery that patients value highly when they seek and receive care, such as getting timely appointments, easy access to information, and good communication with health care providers." (Reference:
https://www.ahrq.gov/cahps/about-cahps/patient-experience/index.html); and (2) PatientEngagement, "a broad concept that combines patient activation with interventions designed to increase activation and promote positive patient behavior, such as obtaining preventive care or exercising regularly." (Reference: https://www.healthaffairs.org/do/10.1377/hpb20130214.898775/full/). Please comment on (A). Appropriateness of creating 2 children for "Experience" as noted and making "Experience" non-selectable; and (B) the new suggested definitions of patientExperience and patientEngagement. Thank you.

view this post on Zulip Abdullah Rafiqi (Jan 31 2022 at 20:25):

@Rob Hausam @Robert McClure

view this post on Zulip Robert McClure (Feb 07 2022 at 17:17):

@Floyd Eisenberg Makes sense to me. I like the definitions except I'd like to not use the word "measure" in the Experience concept definition. Either "Representation of patient engagement..." or "Assessment of patient engagement..." I'm fine with making Experience "Nonselectable" and the two concepts as children. I agree the two definitions are sufficiently distinct and are both types of experience, and we'd want one or the other.

view this post on Zulip Floyd Eisenberg (Feb 07 2022 at 17:38):

@Robert McClure I agree with your assessment of the Experience definition. My understanding was that we would be challenged trying to change the definition of an existing item (I.e., experience). One suggestion had been to change the definition of experience to remove the reference to engagement but the decision was changing the meaning of the existing term would be poor vocabulary practice. Can we remove the word "measure" from the existing definition?

view this post on Zulip Robert McClure (Feb 07 2022 at 17:58):

I don't remember the original definition but the new one does not change the meaning from what I'd assume it was intended to be. You can clarify but you should not change. And the gray area situations intend to align with current usage even if that is not perfectly aligned with the stated definition.


Last updated: Apr 12 2022 at 19:14 UTC