QUICK Data Model

This reference documentation represents the QUICK logical data model. The QUICK data model is an initiative of the Clinical Quality Information (CQI) and Clinical Decision Support (CDS) HL7 Work Groups. This data model is auto-generated from the HL7 Quality Improvement Core (QICore) FHIR Profiles.

The QUICK logical model hides some details of FHIR's physical implementation, such as the distinction between elements and extensions. By abstracting away some of the implementation details, and focusing on classes and attributes, the features of the logical data model can be seen more clearly. As such, the terms class and resource will be used interchangeably in this documentation.

Profiles are represented as classes, so for example, the QICore Procedure profile is simply represented as the Procedure class. Elements and extensions are normalized and listed as fields on the class with a given type, description, and cardinality. The fields are classified as must support and is modifier, as defined in FHIR and the QICore Implementation Guide. When class elements refer to other classes, the reference type is also normalized from its formal profile name (e.g., QICore-Encounter) to its logical class name (e.g., Encounter).

QICore-defined Extensions

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). The logical model represents extensions like any other element, but annotates them to allow the reader to understand what is and what is not a part of the core FHIR data model.

Must Support

Certain elements in the QICore profiles are annotated as must support. These elements must be supported in Quality Improvement (QI) implementations. QI implementations SHALL understand and process must support elements, and those elements SHALL be available for use in clinical quality measures (CQM) and CDS artifacts. Specific applications may modify the profiles and annotate additional elements as must support, but may not remove existing must support annotations.

If an element is not annotated as must support, there is no assurance that an interpreter will recognize or process a quality improvement artifact containing that 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 a must support annotation does not imply that the element will always have a value (i.e., no data may be available for some fields). The only assurance associated with a must support annotation is that the quality improvement application will try to retrieve the data and process it if the data is available.

The QICore Implementation Guide provides further information regarding the must support annotation.

Modifying Attributes

Certain elements in QICore profiles are annotated as is modifier. These elements may change the interpretation of the resource, depending on their value. Examples of modifying elements include status (in many resources), negations (e.g. Immunization.wasNotGiven), and certainty qualifications (e.g. Observation.reliability). QI implementations MUST always check the values of modifying elements.

The QICore Implementation Guide provides further information regarding the is modifier annotation.

Table View

The Table View lists all the fields for the particular class. The table representing the logical view of the class contains three columns:

Column	Content
Column 1 (Field)	The name of the element in the resource. Some names have "[x]" suffix, which is inherited from FHIR to mean that the [x] is replaced with the title-cased name of the type that is actually used. See FHIR spec for details. For example, Patient class has a deceased[x] field with a type listed as { Boolean | DateTime } such that a DateTime value can be referenced as Patient.deceasedDateTime. In addition, this column annotates elements using icons to represent must support, QICore-defined extensions, and is modifier. Key:  = must support,  = QICore-defined extension,  = is modifier
Column 2 (Card.)	The cardinality is the lower and upper bounds on how many times this element is allowed to appear in the resource; e.g., 0..1 is optional and 1..1 is required. 0..* indicates that there is no lower or upper bound to how many times the element may appear.
Column 3 (Type & Description)	type The type of the element (hyperlinked to the definition of the type). If the name of the element has "[x]" suffix then the element can have multiple types. Likewise, if the type of the element is Reference then the list of clinically relevant resources will be listed. The cardinality is the lower and upper bounds on how many times this element is allowed to appear in the resource. If the upper bounds of the cardinality is unbounded then the List<> notation is defined in the type definition. description A description of the element, and details about constraints that are applied to it. Particularly, for coded elements, information about which codes can be used.