DSTU2 Ballot Source
This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
In April 2015, this FHIR Implementation Guide will undergo a DSTU ballot. The focus of the ballot is limited in scope to the IG, the profiles, operations, value sets and conformance statements it defines, although comments on the underlying resources will also be accepted. This Implementation Guide will be balloted separately from the FHIR specification itself. A non-normative, but useful, summary of classes and attributes defined by this IG can be found here.
This Implementation Guide is prepared as a U.S. Realm Specification with support from the Clinical Quality Framework (CQF) initiative, which is a public-private partnership sponsored by the Centers for Medicare & Medicaid Services (CMS) and the U.S. Office of the National Coordinator (ONC) to harmonize standards for clinical decision support and electronic clinical quality measurement. While this Implementation Guide is for electronic clinical quality improvement, the Quality Improvement Core (QICore) is intended to be usable for multiple use cases across domains, and much of the content is likely to be usable outside the U.S. Realm.
The QICore model defines a set of FHIR profiles that provide a physical implementation of the Quality Information and Clinical Knowledge (QUICK) logical model. Authors of future quality measures and clinical decision support artifacts may use QUICK, together with the Clinical Quality Language (CQL), to create interoperable and executable knowledge artifacts. QICore bridges QUICK and FHIR, making data accessible via the FHIR API.
The use of QICore FHIR profiles to implement quality applications is optional. If the QICore FHIR profiles are not used, the implementer is responsible for mapping their data directly into the QUICK model via their own customized data access layer.
The QICore model is an initiative of the Clinical Quality Information (CQI) and Clinical Decision Support (CDS) HL7 Work Groups. QICore defines a set of FHIR profiles with extensions and bindings needed to create interoperable, quality-focused applications. QICore classes and attributes are the most relevant to the broader QI community, lying in the intersection of clinical quality measures (CQM) and CDS, thus providing a common foundation for reusability. The expectation is that QICore will grow over time by incorporating other extensions with broad applicability. There may also be further extensions and coordinated profiles in specific domains beyond QICore, e.g., radiology-specific profiles. When additional classes and attributes are needed for specific quality applications, they can be added through FHIR's extension mechanism. These extensions, however, would not automatically result in sharable artifacts without additional coordinating agreements between interested parties. It is expected that QICore will evolve over time to include some of the extensional content when the community identifies a common need and the additional content has been validated.
This project is part of an effort to align the HL7 Product Family in the area of health quality improvement. The goal is to have a single logical data model (QUICK), as well as a single logical processing language (CQL), for CDS and clinical quality measurement (CQM). This alignment will lessen the cost and complexity for product developers and vendors, reduce the learning curve, and consolidate efforts to maintain multiple standards.
This initiative began in 2013 with the creation of the Quality Improvement Domain Analysis Model (QIDAM), which drew on the HL7 Virtual Medical Record for Clinical Decision Support (vMR) and the Quality Data Model (QDM) as sources of requirements. QIDAM gave rise to the QUICK logical model in 2014. Recognizing the broader community focus on FHIR, QUICK was aligned, structurally and semantically, as closely as possible to FHIR. This alignment not only creates a common model for quality and interoperability, but will also make it easier in the future to leverage other FHIR-related efforts, such as Clinical Document Architecture (CDA) on FHIR. In summary, the conceptual, logical, and physical models in this initiative are, respectively, QIDAM, QUICK, and the QICore FHIR Profiles.
The QICore FHIR Implementation Guide provides requirements and guidance on the use of FHIR in quality measurement and decision support. The profiles in this implementation guide will be used to meet QICore project objectives of:
This IG is focused on representation of clinical data, and is limited in breadth to the profiles currently included in QICore. Not all FHIR resources are profiled, especially those that do not have clinical value, and do not map to QIDAM. The current set of profiles will change to reflect changes to the underlying FHIR resources during the DSTU 2 period. Additional extensions may be added to the current set of profiles, and additional profiles may be added at a later time. The following topics are explicitly out of scope for this implementation guide:
Some of the above topics are under active investigation and will be topics of future standards efforts.
QICore has been harmonized with certain other FHIR-based initiatives, in particular, the Data Access Framework (DAF). DAF is a U.S. Realm Implementation Guide that maps Meaningful Use data elements to FHIR resources. The data elements in DAF are also in QICore, and the value sets required by DAF are preferred (but not required) in QICore. As a result, conforming to DAF automatically satisfies a significant subset of the conformance requirements of QICore. QICore conformance involves supporting certain additional data elements not required by DAF. However, it is possible to conform to QICore and not conform to DAF, because by design, QICore is less restrictive than DAF. Although there are no conflicts between DAF and QICore, conforming to DAF is neither necessary nor sufficient for conforming to QICore.
QICore's extensions have also been reviewed by HL7 Work Groups and other initiatives to validate that QICore extensions will not create future conflicts. One initiative that provided reviews and feedback was the Clinical Information Modeling Initiative (CIMI) through the Healthcare Services Platform Consortium (HSPC).
The following table lists the QICore profiles that are part of the IG, and the underlying FHIR resources:
QICore profiles are indicated by the prefix "QICore-". For example, the QICore profile of Patient is named QICore-Patient. The official URLs for QICore profiles follow the pattern http://hl7.org/fhir/StructureDefinition/[resource]-qicore-qicore-[resource], for example, http://hl7.org/fhir/StructureDefinition/patient-qicore-qicore-patient. This URL is a unique identifier for the profile, and is not necesssarily a web page. For the May 2015 ballot, the web page where QICore-Patient can be found is http://hl7.org/fhir/2015May/patient-qicore-qicore-patient.html Note: the URL cannot be significantly simplified under the current design of FHIR, so ballot comments are not necessary. Other profiles follow a similar pattern, e.g., patient-daf-dafpatient, patient-uslab-uslabpatient, etc.
QICore adds a variety of extensions to core FHIR classes. These extensions derive from two primary sources: the Quality Improvement Domain Analysis Model (QIDAM), and the Quality Data Model (QDM). Profile pages contain definitions of extensions and mappings to QDM as an aid for current users of QDM.
Certain elements in the QICore profiles have a "MustSupport" flag. In the QICore quality profiles, the MustSupport flag is used to indicate whether the element must be supported in QI implementations. More specifically, labeling an element as MustSupport means that quality improvement implementations SHALL understand and process the element, and the elements are available to CQM and CDS artifacts. Specific applications can modify the profiles and set MustSupport flags to true if they will process additional elements, but setting a MustSupport flag from true to false is noncompliant.
If MustSupport is false (or does not appear), there is no assurance that an interpreter will recognize or process a quality improvement artifact containing the element. Although the element may be returned in a resource when the resource is retrieved from an EHR, no processing involving that data element can be expected. Note that the MustSupport flag does not imply that the element will always have a value, if the lower cardinality is zero. The only assurance associated with MustSupport is that the quality improvement application will try to retrieve the data and process it if the data allows.
In summary, MustSupport elements represent the minimal set of data elements that must be supported in quality applications, defined as follows:
Is-Modifier is a boolean property of an element, indicating that the value of that element may change the interpretation of the resource. Examples of modifying elements include status (in many resources), negations (e.g. Immunization.wasNotGiven), and certainty qualifications (e.g. Observation.reliability). Decision support and quality implementations MUST always check the values of modifying elements. For example, in processing an Immunization resource, the application must inspect the "wasNotGiven" element to determine whether the immunization was given or was not given to the patient. For this reason, modifying elements SHALL be treated as MustSupport, even if not declared.
As an aside, inclusion of modifying elements is a departure from the previous (January 2014) informative version of the QICore profiles, where profiles were developed for each meaning of each modifying attribute. For example, the Condition resource was represented using two profiles, one representing the occurrence of the condition, and the other the non-occurrence of the condition. However, it was felt the proliferation of profiles under this approach would lead to a non-sustainable situation, particularly in light of the future need to expand QICore by incorporation of third-party profiles, such as those being developed by CIMI. The current approach requires quality improvement artifact authors to make explicit checks for modifying elements when dealing with classes that have modifying elements.
Uniformity in vocabularies and value sets enhances the interoperability of knowledge artifacts, but also forces data owners to translate local data into the required vocabulary. As a U.S. Realm product, QICore recommends value sets and vocabularies required by Meaningful Use. DAF provides the FHIR realization of these requirements. Because QICore is expected to be applied outside the U.S. Realm, and also in clinical settings where local terminologies exist, U.S. Realm bindings are preferred but not required in the QICore profiles. When and if Meaningful Use adopts QICore, QUICK, and CQL, policy could be created that could mandate the preferred bindings given in the standard.
FHIR resources frequently contain references (pointers) to other FHIR resources. For example, Encounter.patient is a reference to a Patient resource. In QICore, most references are constrained to QICore-profiled resources. For example, Encounter.patient must point to a Patient resource that conforms to the QICore-Patient profile. Consequently, any extensions or bindings expected to exist in QICore-Patient are also present in the resource pointed to by Encounter.patient. References to QICore extensions accessed through references, such as Encounter.patient.veteranMilitaryStatus, are guaranteed to be valid. References to resources that do not currently have QICore profiles are not constrained, and as such, only the core FHIR properties and bindings are guaranteed to exist.
A particular problem occurs when a resource reference permits any type of resource, such as Encounter.indication. When dealing with "Any" references, the current method of specifying profiles does not allow the profile author to specify something to the effect of "a QICore resource when there is one, and a FHIR core resource if there isn't." In QICore, the resources in "Any" references SHALL conform to QICore profiles if the base resource has been profiled.
Conformance to this QICore Implementation Guide requires the following (in addition to adherence to core FHIR requirements):
| Author Name |
|---|
| Mark Kramer (Primary) |
| Jason Mathews (Primary) |
| Claude Nanjo (Primary) |
| Marc Hadley (Supporting) |
| Lloyd McKenzie (Supporting) |
| Chris Moesel (Supporting) |
| Jason Walonoski(Supporting) |
© HL7.org 2011+. FHIR DSTU (v0.5.0-5149) generated on Fri, Apr 3, 2015 14:36+1100.
Links: What's a DSTU? |
Version History |
Specification Map |
Compare to DSTU1 |
|
Propose a change