Stream: implementers
Topic: Implementing DEQM
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!
Lloyd McKenzie (Feb 20 2020 at 16:02):
@Bryn Rhodes
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
Brett Marquard (Feb 20 2020 at 16:09):
Only adds
Brett Marquard (Feb 20 2020 at 16:10):
qicore also constrains, but no 'subtractions'
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?
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.
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!
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!
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!
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
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.
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.
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.
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
Christopher Vitale (Feb 21 2020 at 02:34):
Thank you, @Bryn Rhodes!
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?
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.
Bryn Rhodes (Feb 21 2020 at 19:27):
@Christopher Vitale , yes, that's correct
Last updated: Apr 12 2022 at 19:14 UTC