FHIR Chat · Implementing DEQM · implementers

Stream: implementers

Topic: Implementing DEQM


view this post on Zulip Christopher Vitale (Feb 20 2020 at 15:22):

Hello FHIR Community. I have a few questions re: implementation of DEQM.

The implementation guide states: The implementation guides in this landscape are currently focused on FHIR STU3, with the plan to produce R4 versions once the US Core and QI Core profiles have been updated to R4.

My questions for the community are:

1) Is anyone actually trying to implement any of the DEQM profiles yet?

2) If so, are you building profiles as currently specified (i.e., based on R3)? Or are you making assumptions on what the profiles may look like once aligned w/ R4?

For example, if we consider the CQFM Library profile, (which currently builds from the R3 Library resource) there is an element called "contributor" of type "Contributor" (where the Contributor profile requires terminology binding to ContributorType codes). For the R4 Library resource, the "contributor" element was removed (and as such, there is no terminology binding requirement). In this case, if an implementer builds from the DEQM IG in its current state (i.e., builds from the R3 Library resource), there is a risk of building out terminology bindings that are likely to not be necessary in the near future (i.e., once the DEQM implementation guide is aligned with R4).

Any feedback would be much appreciated, especially from implementers and the DaVinic community. Thank you!

view this post on Zulip Lloyd McKenzie (Feb 20 2020 at 16:02):

@Bryn Rhodes

view this post on Zulip Christopher Marchand (Feb 20 2020 at 16:08):

I work with Chris Vitale on this same analysis- is it always that QI Core ADDS to US Core profiles? Are there any subtractions? CC: @Brett Marquard

view this post on Zulip Brett Marquard (Feb 20 2020 at 16:09):

Only adds

view this post on Zulip Brett Marquard (Feb 20 2020 at 16:10):

qicore also constrains, but no 'subtractions'

view this post on Zulip Christopher Vitale (Feb 20 2020 at 16:11):

Thank you for the quick reply, @Brett Marquard ! Would you be able to also comment on my original question?

view this post on Zulip Bryn Rhodes (Feb 20 2020 at 16:24):

Hi @Christopher Vitale , the R4 versions of the guides (QM and DEQM) were balloted in the February cycle and we are in the process of reconciliation now. Whether you implement STU3 or R4 versions depends largely on the systems you are likely to receive data from for quality reporting. There are systems implementing both versions at this point. Regarding "contributor" specifically, it was replaced by role-specific elements as part of a general change between STU3 and R4, so an author in R4 was represented in STU3 as a contributor with a type of author.

view this post on Zulip Christopher Vitale (Feb 20 2020 at 16:53):

Thank you, @Lloyd McKenzie for point me to Bryn! And thank you, @Bryn Rhodes , this is very helpful!

view this post on Zulip Christopher Vitale (Feb 20 2020 at 20:20):

@Bryn Rhodes & @Brett Marquard, can I please ask another question?

I am looking at QICore-Condition, here: http://hl7.org/fhir/us/qicore/STU32/StructureDefinition-qicore-condition.html. Re: element "condition-dueTo".

1) I see that the type is CodableConcept, Reference. Does this imply that this field can be populated with either a CoadableConcept or a Reference to another profile? If so, is there a preference as to which is used?

2) And if Reference is used, the reference range is specified as as: Condition | Procedure | MedicationAdministration | Immunization. In this case, would the reference actually be to QICore-Condition, QICore-Procedure, QICore-MedicationAdministration, QICore-Immunization? In other words, should a QICore profile reference other QICore profiles when available?

Thanks again for any guidance you can give!

view this post on Zulip Christopher Vitale (Feb 20 2020 at 20:42):

And a similar question related to US Core...

I am looking at US Core Condition, here: http://hl7.org/fhir/us/core/STU3/StructureDefinition-us-core-condition.html

For element subject, reference range is US Core Patient Profile. But for element encounter, reference range is Encounter (R4). I would expect that the later would have a reference range of US Core Encounter. How should this be interpreted? Thanks!

view this post on Zulip Eric Haas (Feb 20 2020 at 21:06):

for US Core see this: http://hl7.org/fhir/us/core/STU3/general-guidance.html#referencing-us-core-profiles

view this post on Zulip Eric Haas (Feb 20 2020 at 21:10):

With the goal of keeping the differential profiles as light as possible in lieu of adding every possible US Core reference to the differentials we provide this general guidance.

view this post on Zulip Christopher Vitale (Feb 20 2020 at 21:37):

Thank you, @Eric Haas! I suspected this was in the documentation somewhere, I just have not stumbled upon it yet.

view this post on Zulip Bryn Rhodes (Feb 20 2020 at 21:44):

The same is true of QI Core, though we do specify it in many places explicitly, you've found one of the places that we don't.

view this post on Zulip Bryn Rhodes (Feb 20 2020 at 21:45):

Here's the relevant guidance in QI-Core: http://hl7.org/fhir/us/qicore/STU32/index.html#references

view this post on Zulip Christopher Vitale (Feb 21 2020 at 02:34):

Thank you, @Bryn Rhodes!

view this post on Zulip Christopher Vitale (Feb 21 2020 at 03:23):

@Bryn Rhodes, here is a follow-up question...

I am looking at QICore-Procedure, here: http://hl7.org/fhir/us/qicore/STU32/StructureDefinition-qicore-procedure.html

Re: element basedOn, where reference range includes CarePlan. There is no QICore-CarePlan, so should this point to US Core Care Plan?

view this post on Zulip Christopher Vitale (Feb 21 2020 at 03:46):

I think yes, based on: In the U.S. Realm, applications SHALL be simultaneously compliant with QI-Core profiles and US Core profiles.

view this post on Zulip Bryn Rhodes (Feb 21 2020 at 19:27):

@Christopher Vitale , yes, that's correct


Last updated: Apr 12 2022 at 19:14 UTC