Should we consider naming this element as Health Data or Person’s Health Data, since the scope extends to use of CDS by consumers.
# Data Elements Data Element Descriptions Cardinality Additional Notes Section Name &
Description
Name: Patient Data
Description: The patient data required as input by the CDS system to evaluate if the CDS applies to the patient, and to customize the output for that patient.
Example: A data element representing the patient’s body temperature
1 Unspecified here. Data elements will be specified in a model containing representation for different classes of health data. We express to the right, requirements for the model
Suggested Data Classes:

Things, including people
(providers, caretakers, etc.), evaluated persons (patient, family members, public health contacts), organizations, facilities, administrable substances, specimens, supplies, etc.

Encounters between an evaluated person and the health care system, or a health care provider. May be an encounter that has happened (an event), or proposed (possibly by CDS), ordered (by provider), or scheduled appointment. May also include appointments that were missed. Typically involve a setting in a facility that may be inpatient, emergency, outpatient, mental health, long-term care, etc.

Information/Observations relative to the health state of the patient, including
Multiple In selecting a model for patient data:
1.
Separate ideas of structure of attributes from semantic content of the data
2.
Describe classes that are developed to contain particular sets of attributes, and produce the minimum set of classes that cover at least a large common core of data element needs.
3.
Create a mechanism for extending the coverage to less common data element needs (or data elements that are not known or do not exist at the current time) without having to revise the common core of data element classes.
The key idea is to extend rather than change (as far as possible), so that you have backwards compatibility.
4.
Provide mechanism for scoping the intended use of the data elements in CDS
(with “generic evaluation” as

Section Name &
Description
# Data Elements Data Element Descriptions
 diagnostic test results, HPI, vital signs, family medical Hx, problems, conditions, adverse events, etc. May be something in the past (aka an event) relevant to the patient, or a proposed (possibly by
CDS), ordered (by a provider), or scheduled observation.
May also be information about an observation that was not performed.
Treatments designed to alter the evaluated person’s medical state, including procedures, substance administrations (medical, nutritional, IZ, etc.), provision of DME or supplies, creation of goals, provision of training or education relative to the state of the patient’s health, etc. May be a treatment that has already been performed
(an event), proposed (possibly by CDS), ordered (by a provider), or scheduled. May also be information about a treatment that was not performed.
All valued patient data elements should describe the values in a standard representation (e.g., ISO
21090) and where applicable
 standard terminology codes
Cardinality Additional Notes one available use), so that constrained sets of data requirements can be created for very specific targeted use cases.

Section Name &
Description
# Data Elements Data Element Descriptions Cardinality Additional Notes
 date time stamps, including at least the time the data was recorded, and other times that may be relevant, such as when things happened.
 other attributes as appropriate for the class
Section Name &
Description
Data Elements
Name: Action Sentence
Description: A structured description of the care (?) action that the CDS artifacts recommend to be executed, i.e., the output of the CDS. The data elements contain the action class with the necessary parameters specified
(e.g., dose of medication)
Example: Perform a liver function test panel after 30 days
Unspecified here. Data elements will be specified in a representation for different classes of care actions. We express to the right, requirements for the model.
Data Element Descriptions Cardinality Additional Notes

All classes should support coding the action with codes from standard terminologies.

Action classes will provide the attributes necessary to provide a structured, detailed description of the recommended action. For example, the substance administration class, will contain attributes for dose, frequency, and route of administration, etc.
Single
Suggested Action Classes

Substance Administration
(includes medications, vaccinations, gases, blood products and other activities that fit the same output
Some of the data elements listed at left may be simply more specific instances of other elements, or combinations of several other elements. For example, Diagnostic Test is a
Procedure that may produce an
Observation. Nutrition can be a
Procedure (feeding the patient),
Education, Substance
Administration (which is the superclass of Medication), or a
Goal. We keep the Output Action
Classes as simple and generic as possible, consistent with supporting all the different types of activities that we need to perform.

Section Name &
Description
Data Elements Data Element Descriptions activity structure, including hydration and feeding)

Nutrition

Procedure including surgical procedures, nursing and other allied health activities and procedures

Encounter (including proposed
Appt., Referral, Admission
Discharge)

Observation/Documentation
(including identification of
Problems)/Assessment
Evaluation

Education

Goal

Supply (provision of supplies or medical equipment)

System action (e.g., trigger other CDS)
Cardinality Additional Notes