This page is part of the FHIR Specification (v1.4.0:
STU
3 Ballot 3). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions 
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.
QICore
FHIR
profiles
define
the
Quality
Information
and
Clinical
Knowledge
(QUICK)
logical
model.
The
QUICK
model,
derived
from
QICore,
provides
a
uniform
way
for
clinical
decision
support
and
quality
measures
to
refer
to
clinical
data.
Simultaneously,
the
QICore
profiles
provide
a
physical
implementation
of
QUICK,
making
data
for
quality
improvement
applications
accessible
via
the
FHIR
interface.
However,
using
FHIR
in
the
physical
layer
is
optional.
If
the
QICore
FHIR
profiles
are
not
used
at
the
physical
layer,
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
shareable
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.
, 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.
QICore FHIR profiles define the Quality Information and Clinical Knowledge (QUICK) logical model. The QUICK model, derived from QICore, provides a uniform way for clinical decision support and quality measures to refer to clinical data. Simultaneously, the QICore profiles provide a physical implementation of QUICK, making data for quality improvement applications accessible via the FHIR interface. However, using FHIR in the physical layer is optional. If the QICore FHIR profiles are not used at the physical layer, 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 shareable 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.
Understanding QICore and how it is used in quality applications requires an understanding role of common reference models. Electronic Health Records (EHRs) are stored in many different local formats. Exchanging data between EHRs requires mapping between local data formats. It is well understood that standards can reduce the number of data maps each data provider must create. In a similar manner, to share quality measures and clinical decision support artifacts, the measures and artifacts must refer to data in a standardized way.
In the U.S. Realm, under Meaningful Use, the common reference model for quality measures is the
Quality Data Model (QDM)
.
For
clinical
quality
measures,
a
common
reference
model
is
the
HL7
Virtual
Medical
Record
for
Clinical
Decision
Support(vMR)
. For clinical quality measures, a common reference model is the
HL7 Virtual Medical Record for Clinical Decision Support(vMR)
.
Decision
support
and
quality
measures
are
closely
related,
and
can
be
viewed
as
"two
sides
of
the
same
coin".
Specifically,
decision
support
provides
guidance
for
clinical
best
practices,
and
quality
measures
assess
whether
clinical
best
practices
have
been
followed.
It
therefore
makes
intuitive
sense
to
use
the
same
common
reference
model
for
both
types
of
applications.
The
proposed
unified
model
is
known
as
QUICK.
QUICK
is
a
logical
model
consisting
of
objects,
attributes,
and
relationships.
QUICK
provides
a
uniform
way
for
clinical
decision
support
and
quality
measures
to
refer
to
clinical
data.
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.
This
initiative
began
in
2013
with
the
creation
of
the
Quality
Improvement
Domain
Analysis
Model
(QIDAM),
which
drew
on
the
vMR
and
QDM
as
sources
of
requirements.
QIDAM
gave
rise
to
the
QUICK
logical
model
in
2014.
Originally,
QUICK
was
entirely
independent
of
FHIR.
However,
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.
The
conceptual,
logical,
and
physical
models
in
this
initiative
are,
respectively,
QIDAM,
QUICK,
and
the
QICore
FHIR
Profiles.
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.
. Decision support and quality measures are closely related, and can be viewed as "two sides of the same coin". Specifically, decision support provides guidance for clinical best practices, and quality measures assess whether clinical best practices have been followed. It therefore makes intuitive sense to use the same common reference model for both types of applications.
The proposed unified model is known as QUICK. QUICK is a logical model consisting of objects, attributes, and relationships. QUICK provides a uniform way for clinical decision support and quality measures to refer to clinical data. 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.
This initiative began in 2013 with the creation of the Quality Improvement Domain Analysis Model (QIDAM), which drew on the vMR and QDM as sources of requirements. QIDAM gave rise to the QUICK logical model in 2014. Originally, QUICK was entirely independent of FHIR. However, 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. The conceptual, logical, and physical models in this initiative are, respectively, QIDAM, QUICK, and the QICore FHIR Profiles.
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.
As mentioned above, the QUICK logical model was originally developed without reference to FHIR. However, when it became clear that FHIR would be the focus of interoperability efforts in HL7, it no longer made sense for the quality improvement community to maintain its own model of clinical information, for example, having a procedure model with different attributes than the FHIR procedure resource. The decision was made by the CDS and CQI working groups to align QUICK with FHIR, and use the FHIR resources to define the QUICK model. This decision means that QUICK benefit from all the thought and effort being put into FHIR, and stay in synchronization with the development and evolution of FHIR.
Using FHIR to define the QUICK logical model seems to reverse the usual flow from conceptual model to logical model to physical model. This is true, and has been the source of some controversy. Without revisiting that debate, the bottom line is whether the QUICK model has the right set of objects and attributes that are needed for quality improvement applications. To assure that QUICK does meet those requirements, the QICore profiles were created. QICore fills any gaps such as missing attributes and unspecified value sets, that might make QUICK insufficient for quality improvement applications. In turn, QUICK is derived from QICore profiles, rather than directly from FHIR.
As explained above, QUICK model will be the logical model used by quality artifact developers. To obtain data to evaluate the artifacts, the interactions with the local EHR can use FHIR or implement a custom data mapping to local EHR data. In addition to defining QUICK, the QICore profiles provide a bridge to using FHIR as QUICK's physical model. To correctly map between FHIR and QUICK, the data instances retrieved from a FHIR interface must conform to the QICore profiles. The QICore FHIR Profiles link the QUICK logical model to FHIR at the physical level.
For the developer, using FHIR as the physical data model behind QUICK may provide several benefits. It may be that the local EHR has already been mapped to FHIR. In this case, the same interface with minor modifications can be used for quality applications. Developers can also leverage future reference implementations based on FHIR. Using FHIR as a common model for different applications (quality, interoperability, etc.) reduces the overall learning curve.
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 in the context of quality improvement, or do not map to QIDAM. Additional extensions may be added to the current set of profiles, and additional profiles may be added at a later time. In particular, QICore represents a subset of the semantics covered in QIDAM, vMR, and QDM. The parts of the latter specifications that are not in the QICore profiles could be handled with additional profiles, if the DSTU period reveals the need for such additions. Keeping the QICore profiles (and QUICK) in line with FHIR and FHIR's "80%" rule is one way to make sure that the quality artifacts produced from QUICK and QICore are computable, based on commonly-collected clinical data. The current set of profiles will evolve to reflect changes to the underlying FHIR resources.
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.
Quality applications may make use of patient-specific information. For this reason, all transactions must be appropriately secured, limiting access to authorized individuals and protecting data protected while in transit. These are the same considerations that would relate to any FHIR implementation, and include authentication, authorization, access control consistent with patient consent, and transaction logging. For the purposes of QICore, security conformance rules are as follows:
It is the responsibility of the server(data provider)to ensure that any necessary consent records exist and are reviewed prior to each exchange of patient-identifiable healthcare information. This verification should be logged in the same manner as other transactions, as discussed above under General Security Considerations.
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, because they are needed for quality measures. However, it is possible to conform to QICore and not conform to DAF, because by design, QICore is less restrictive than DAF, allowing QICore to be used outside the U.S. Realm. Although there are no conflicts between DAF and QICore, conforming to DAF is neither necessary nor sufficient for conforming to QICore.
In general, where DAF defines its own value sets, QICore uses the same value sets. This assures the alignment of the two sets of profiles. The binding strengths may not be the same, however, and in many cases value sets that are required by DAF are only preferred in QICore. The weaker binding allows QICore to be used outside the U.S. Realm. In the U.S. Realm, compliance with QICore SHALL requires simultaneous compliance with DAF; therefore, any value set required by DAF SHALL be required by 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)
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.
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, labelling an element as MustSupport means that quality improvement implementations SHALL understand and process the element.
If MustSupport is false (or does not appear), and that element appears in a quality measure or in the matching criteria of a CDS artifact (e.g., the left-hand side or antecedent), the entire quality measure or CDS artifact may be ignored. However, all elements in the QICore profiles, including those that are not MustSupport, can be used in CDS actions (i.e. right-hand side or consequents of CDS rules). For example, vaccination protocol in ImmunizationRecommendation is not a MustSupport element, so it cannot be used in a quality measure or as a criteria for triggering a CDS action. However, it can be filled in as part of the recommendation of a CDS application.
Although the element may be returned in a resource when the resource is retrieved from an EHR, no logical 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.
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.
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 STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100.
QA Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Compare
to
DSTU1
|
Version History
|
Table of Contents
|
Compare to DSTU2
|
|
|
Propose
a
change
|
Propose a change