2.1 Scope of Clinical Statement Topics

The Clinical Statement model is deliberately broad and encompassing. As a result, it can be possible to represent a particular statement in more than one way. The primary objective of the Clinical Statement topics that follow are to constrain the Clinical Statement model when used to communicate certain types of information in an effort to enhance interoperability and shareable semantics.

See section 2.4 below for notes on the process for developing Clinical Statement topics.

2.2 Medication Events Topic

2.2.1 Introduction

This topic constrains the Clinical Statement model for communicating medication-related events such as substance administrations and filling prescriptions. Medication events can be used to define a patient's (person or animal) current medications and pertinent medication history. Coupled with supply acts, medication events can convey a patient's prescription history, and can enable the determination of the source of a medication list (e.g. from a pharmacy system vs. from the patient).

The template identifier for this pattern: root ="2.16.840.1.113883.10", extension="medication events".

The overseeing HL7 Committee for this topic: Pharmacy.

The following figure shows a subset of the Clinical Statement model containing those classes being constrained or referred to in the conformance statements that follow. It should be noted that the entire Clinical Statement model is available for use, and that the model components not shown can be used without any additional constraints.

2.2.2

2.2.3 Conformance Statements for Medication Events Pattern

MED - 1	Medication administration events shall be represented using the SubstanceAdministration class, which shall have a SubstanceAdministration.classCode of "SBADM", and shall have a SubstanceAdministration.moodCode of "EVN".
MED - 2	Medication administration events may include SubstanceAdministration.code. If present, it shall be valued with a SNOMED CT concept, per the guidelines in the "Using SNOMED CT in HL7 Version 3" specification.
MED - 3	Medication administration events shall include SubstanceAdministration.statusCode.
MED - 4	Medication administration events shall include SubstanceAdministration.effectiveTime which is used to indicate the start and stop date of a medication, and the frequency of administration.
MED- 5	Medication administration events should include SubstanceAdministration.routeCode, populated with a code drawn from the HL7 RouteOfAdministration (codeSystem 2.16.840.1.113883.5.112) domain.
MED- 6	Medication administration events should include SubstanceAdministration.doseQuantity or SubstanceAdministration.rateQuantity.
MED - 7	PRN medications shall represent the criteria for administration using the Criterion class, with Criterion.classCode set to "OBS", and Criterion.moodCode set to "EVN.CRT". Criterion.code shall be present, and represents the criteria for administration.
MED - 8	Medication indications shall be represented using an entryRelationship, with a sourceOf.typeCode of "RSON" (has reason). The target of the sourceOf relationship shall be an Observation, with Observation.classCode set to "OBS", and Observation.moodCode set to "EVN". Observation.id and/or Observation.code shall be present, and represents the indication for the medication administration.
MED - 9	Prescriptions and dispensing information shall be represented with the Supply class, which shall be nested under the SubstanceAdministration class, linked by a sourceOf relationship with sourceOf.typeCode of "COMP"; and which shall have a Supply.classCode of "SPLY", and a Supply.moodCode of "EVN".
MED- 10	The medication administered shall be represented as a consumable participant of the SubstanceAdministration class.
MED - 11	Where the person administering a substance is to be included, they shall be represented as a performer participant of the SubstanceAdministration class.
MED - 12	The product dispensed shall be represented as a product participant of the Supply class. The target of the product shall be a LabeledDrug, in which case LabeledDrug.code shall be present; or Material, in which case Material.code shall be present.
MED - 13	Where the prescriber is to be included, they shall be represented as an author participant of the Supply class

2.3 Results Topic

2.3.1 Introduction

This topic constrains the Clinical Statement model for communicating the results of observations generated by laboratories, imaging procedures, and other procedures. The scope includes hematology, chemistry, serology, virology, toxicology, microbiology, plain x-ray, ultrasound, CT, MRI, angiography, cardiac echo, nuclear medicine, pathology, and procedure observations.

Lab results are typically generated by laboratories providing analytic services in areas such as chemistry, hematology, serology, histology, cytology, anatomic pathology, microbiology, and/or virology. These observations are based on analysis of specimens obtained from the patient, submitted to the lab. Imaging results are typically generated by a clinician reviewing the output of an imaging procedure, such as where a cardiologist reports the left ventricular ejection fraction based on the review of a cardiac echo.

Procedure results are typically generated by a clinician wanting to provide more granular information about component observations made during the performance of a procedure, such as where a gastroenterologist reports the size of a polyp observed during a colonoscopy.

The template identifier for this pattern: root="2.16.840.1.113883.10", extension="results".

The overseeing HL7 Committee for this topic: Lab.

The following figure shows a subset of the Clinical Statement model containing those classes being constrained or referred to in the conformance statements that follow. It should be noted that the entire Clinical Statement model is available for use, and that the model components not shown can be used without any additional constraints.

2.3.2

2.3.3 Conformance Statements for Results Pattern

RSL- 14	Results shall include Observation.classCode, which shall be valued with "OBS" (observation) or "DGIMG" (diagnostic image).
RSL- 15	Results shall include Observation.moodCode, which shall be valued with "EVN".
RSL - 16	Results should include Observation.id.
RSL - 17	Results shall include Observation.code, which should be valued with a LOINC or SNOMED CT code. Other codes, such as CPT codes, may be included as translations.
RSL- 18	Where Observation.value is a physical quantity, the units of measure shall be expressed using a valid UCUM expression.
RSL- 19	Results shall include Observation.statusCode unless the Observation is a component of an Observation or Organizer, in which case the absence of Observation.statusCode shall imply that the status of the result equals the status of the outer result.
RSL- 20	Results shall include Observation.effectiveTime unless the Observation is a component of an Observation or Organizer, in which case the absence of Observation.effectiveTime shall imply that the effective time of the result equals the effective time of the outer result.
RSL- 21	Results should include Observation.interpretationCode, which can be used to provide a rough qualitative interpretation of the observation, such as "normal", "abnormal", resistant", "susceptible", etc. Interpretation is generally provided for Numeric results where an interpretation range has been defined or for Antimicrobial susceptibility test interpretation.
RSL- 22	Results may include Observation.methodCode if the method isn't inherent in Observation.code or if there is a need to further specialize the method in Observation.code. If present, it shall not conflict with the method inherent in Observation.code.
RSL - 23	Results should include Observation.referenceRange to show the normal range of values for the observation result. It may include Criterion.code if needed to associate a reference range with a particular criterion such as age or gender.

Invariably an ordered test (e.g. Complete Blood Count, Chemistry Panel) or a performed procedure (e.g. Cardiac Echo) have component observations, in which case the following conformance rules apply:

RSL - 24	Where an ordered test or a performed procedure have component observations, the result shall be represented as an Observation, Organizer, or Procedure, depending on the nature of the result. Results of a battery shall use Organizer. Component results of a performed procedure shall use Procedure. Other observations with component results shall use Observation.
RSL - 25	An Observation result or a Procedure with component results shall have an sourceOf relationship to each component result. Each sourceOf relationship shall have a sourceOf.typeCode, which shall be valued with "COMP".
RSL - 26	An Organizer result shall have a component link to each component result. Each component shall have a component.typeCode, which shall be valued with "COMP".
RSL - 27	Each component result shall be an Observation, with Observation.classCode of "OBS", and Observation.moodCode of "EVN".
RSL- 28	The absence of Observation.statusCode on a component result shall imply that the status of the result equals the status of the outer result.
RSL - 29	The absence of Observation.effectiveTime on a component result shall imply that the effective time of the result equals the effective time of the outer result.

2.4 Development of Clinical Statement Topics

The process for developing and maintaining a Clinical Statement topic is:

• Identify a domain owned by an HL7 Committee where the model has been fairly well established. For instance, a domain might include the Clinical Genomic's model of Family History, Pharmacy's model of Medications, Patient Care's model of Allergies, etc.
• Work with the HL7 Committee overseeing the identified domain to build an isomorphic model as a set of constraints against the Clinical Statement model. For instance, if a domain model represents a lab battery as a "BATTERY" clone linked to an "OBSERVATION COMPONENT" clone via an ActRelationship with typeCode of "COMP", the corresponding constraint on the Clinical Statement model might be something like: "A lab battery shall be represented as an Organizer. Components of the lab battery shall be represented as nested Observations, linked by an actRelationship.typeCode of COMP".
• Work with the HL7 Committee overseeing the identified domain to maintain and extend the Clinical Statement topic as the domain's model changes and evolves over time.
• New requirements for topics shall go back to the HL7 Committee overseeing the identified domain. A topic should not introduce constraints that potentially conflict with an evolving HL7 Committee domain model. For instance, if there are requests to develop a constraint on the Clinical Statement model for the representation of microbiology results, step one is to work with the Lab committee to flesh out the details of the model.

Each Clinical Statement topic is organized as follows:

• Each topic has a narrative description defining the scope and use case.
• Each topic has an associated Figure, showing a subset of the Clinical Statement model being constrained. It should be noted that the entire Clinical Statement model is available for use, and that the topics are only focusing on constraints. Thus, Clinical Statement classes not shown in the associated Figure can be used without any additional constraints.
• Each topic has a set of constraints, expressed using conformance verbs (e.g. "shall", "should", "may").
• Each topic has a template identifier, which can be used to populate the InfrastructureRoot.templateId attribute of an instance. An instance that thus populates the templateId attribute is claiming conformance to the corresponding topic.
• Each topic has an overseeing HL7 Committee.