Clinical Statement

1.2.1 Model Overview

The model can be divided into 4 related parts:

• Clinical Statement Act Choice Box
• Relationships between Clinical Statements
• Participations surrounding the Acts
• Acts and relationships outside the Choice Box

Each of these parts is described below in sections 1.2.3 - 1.2.6.

1.2.2 Attributes of Clinical Statements

In general, the use of attributes within classes representing Clinical Statements follows the standard HL7 v3 rules.

1.2.2.1 moodCode

Following the HL7 v3 approach to modeling, most of the classes within the Clinical Statement can be assigned a moodCode that determines whether it is reporting an actual event or expressing a request, proposal, promise, appointment or goal. The only exception is Organizer.moodCode, which always has a value of 'EVN'. The allowed values for this attribute in most Clinical Statement classes have been specified using an x_domain. Where a Work Group or Realm implementation etc. uses a constrained version of this model, the value set for the constrained model may be restricted to a sub-set of one or more of the values allowed.

The use of moodCode overlaps with SNOMED CT context attributes and the SNOMED CT concept identifiers and expressions used in the code attribute shall not contradict the moodCode. The Terminfo project provides guidance on the binding between the moodCode and the SNOMED CT context model for the different classes in the Clinical Statement pattern.

NOTE: [Derived from the draft Vocabulary TC document "Domain and Value Set Definitions and Binding.] The name X-domain is a misnomer. A more accurate name would be "X-Value Sets", since they are really HL7 defined value sets. As time permits, all X-domains will be replaced by Value Sets. When this occurs the current x_domains in the RIM and in the Clinical Statement pattern will be replaced by value sets containing the same values.

1.2.2.2 id

Each instance of a Clinical Statement may be identified by means of an id using any of the HL7's II data types which currently includes GUID/UUID, OID, or RUID in the root plus a potential extension. Any of these provides a unique identification, depending on the level of coupling between the communicating systems, which in turn uniquely identifies the specific Clinical Statement. If precisely the same information (statement and context) is required to be referenced either in the same communication instance or in another communication instance, then the same identifier value shall be used in an ActReference to reference the original Clinical Statement.

Conversely, if all of the attributes and context of a Clinical Statement class are not identical, then it is a different Clinical Statement and a new unique identifier shall be assigned. This means:

• a subset of a Clinical Statement is a different Clinical Statement, requiring a different identifier

• an Organizer where one of the 'contained' statements is modified is a new statement requiring a new identifier.

The Clinical Statement 'pattern' allows Clinical Statements to have multiple identifiers. This allows Clinical Statements to be identified by a human readable identifier in addition to the unique identifier and will always be represented by an OID and code value. The use of these identifiers could include identifiers such as departmental order number, episode number etc. where required by specific communication use cases.

NOTE: Modeling and Methodology (MnM) are currently undertaking work to allow identifiers to be classified based on their role in the life cycle and the local management practices for Clinical Statements. When this work is complete, it will be reflected in the definitions for this attribute.

1.2.2.3 code

The code attribute is used to identify the nature of the information conveyed by an instance of a Clinical Statement Act. Code may be optional in some specifications. The cardinality and conformance of the code attribute in the Observation is act is 1..1 required. While the attribute must be present in all Observation instances it is permissible to send an exceptional value from the nullFlavor vocabulary domain as a legal value. The HL7 v3 data type of the code attribute is CD (Concept Descriptor). The CD data type allows the inclusion of:

• The text assigned to the code by the coding scheme (displayText) and the text on which the encoding was based (originalText)

• Qualifiers of the type used in SNOMED CT (including context attributes) to refine the meaning of the primary code

  • Each qualifier is a name + value pair with the name expressed as a code and the value expressed as another instance of the CD data type (allowing nested qualifiers where needed).

• Translations to allow the representation of the concept in the coding scheme in which it originated as well as translated into other preferred terminologies.

  • Note that the original code is expressed at the outer level with the required code (if different) expressed as a translation within this. The ability to recognize the original code is important to enable future enhanced translations based on improved mappings. Thus, if the data was originally encoded in a different coding system the original code should be included with the translation element containing the SNOMED CT representation.

The CD data type supports the use of pre and post-coordination of vocabulary expressions and this model places no restrictions on how these expressions are represented other than the constraints imposed by the respective terminologies.

1.2.2.4 value

Observation.value is information that is assigned or determined by the observation action.

There is still some debate for many observation events, in determining how to populate Observation.code and Observation.value. While this is typically straight-forward for laboratory observations, it can get blurry for other types of observations, such as findings and disorders, family history observations, etc. The HL7 Terminfo project has defined the principles for different patterns of the use for these two attributes where the clinical terminology used in the code attribute is SNOMED Clinical Terms.

The data type of the Observation.value attribute varies and where the expression in Observation.code requires a value, the subset of allowed data types is constrained by the code. Where the PQ data type is used then the UCUM codes should be used to represent the units of the measurement.

1.2.2.5 priorityCode

The Act.priorityCode is defined by HL7 as: "A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen".

The priorityCode attribute has a potential overlap with some vocabularies. This potential conflict is resolved as follows:

• priorityCode should be used to indicate the priority as it relates to workflow management. It is also used to indicate priority assigned by the originator of a request or result or to indicate the priority with which the communication recipient should respond to the information in the Act. For example, the request for a procedure should be treated as 'urgent'.

• Where the vocabulary used in the message has a priority attribute, then this should be used in coded expressions where the priority significantly alters the Act.code, or in the case of an Observation, the Observation.value attribute. For example, the concept 'an Emergency appendectomy' should be expressed totally within vocabulary expression used in Procedure.code.

1.2.2.6 Act.code dependent attributes in the Clinical Statement model

Some coded attributes included in the HL7 v3 RIM are deliberately made optional in Act classes in this model because they represent qualifications that might be more appropriately handled within the terminology model (e.g. using SNOMED CT qualifiers within the code attribute where necessary). These include:

• actionNegationInd
• uncertaintyCode
• priorityCode
• statusCode
• Observation.methodCode
• Observation.valueNegationInd
• Observation.targetSiteCode
• Procedure.methodCode
• Procedure.targetSiteCode
• Procedure.approachSiteCode

The rationale for considering these attributes optional is that flexibility is required by realms in order to be able to implement the vocabularies of choice without ambiguities related to whether a particular concept is included in an Act.code expression or included in another Act Class attribute value. The Terminfo project provides guidance on how these attributes should be used in models and message instances where the code system used is SNOMED CT.

1.2.3 Clinical Statement Act Choice Box

This part of the model is used to convey the detailed clinical information that is being sent in support of the specific business need. As well as providing a mechanism for conveying the components of this information, it supports grouping of these components and provides mechanisms to explicitly link statements where there is a specific relationship.

Where a Clinical Statement has previously been conveyed in a communication and is consequently known within an information system, the Clinical Statement may be included either by reference or by repeating the full statement. Where the full statement is repeated, all attributes and context (whether explicit or inherited) shall be identical.

Clinical Statement has the choice box structure to allow any clinically relevant selection, duplication, constraining and ordering of Acts to be included in the communication.

All items in the clinical data will be able to be coded via either an HL7 code, an external registered coding system, or a locally derived / developed coding system. Through use of the OID structure, the appropriate coding system will be identified.

1.2.3.1 Observation

The Observation (OBS) choice, a derivative of the RIM Observation class used for representing coded and other observations, includes information about an observation including the nature and, where appropriate, the result or finding from that observation. This includes requesting, recommending, promising, refusing or setting a goal to be attained or risk to be avoided, as well as a specific instance of an observation with its result. It also includes any kind of Observation subclass.

The value sets for Observation.moodCode (CNE) may be taken from the x_ClinicalStatementObservationMood. See the detailed description of moodCode above in section 1.2.2.1 for more details on the use of x_domains in this model.

An Observation.interruptableInd was added in February 2009 to align the Clinical Statement observation to source models. The interruptableInd is used to indicate, on a request, that a particular action cannot be stopped during that action (e.g. 24 hour specimen collection procedure cannot be stopped in the middle).

As with Act Class described below in section 1.2.3.7, use may be made of the Observation.actNegationInd. When set to "true", this is a positive assertion that the descriptive attributes of the Observation as a whole are negated. Similarly, the inert properties such as Observation.id, Observation.moodCode, and the participations are not negated.

An Observation can have zero to many referenceRange relationships, which relate an Observation to the ObservationRange class, where the expected range of values for a particular observation can be specified.

1.2.3.2 SubstanceAdministration

The Substance Administration (SBADM) choice is a derivative of the RIM SubstanceAdministration class used for representing medication-related events such as medication history or planned medication administration orders or ongoing medication administration. This includes the act of introducing or otherwise applying a substance (pharmacy, diet or provision of nutritional supplement) to the subject. It also includes requesting, instructing the patient, recommending, promising, prohibiting or refusing to administer a substance, as well as the actual act of personally administering the drug.

This part of the pattern will be further harmonized with Pharmacy.

The value set for SubstanceAdministration.moodCode (CNE) may be taken from the x_ClinicalStatementSubstanceMood vocabulary x_domain which now includes the value Definition (DEF). See the detailed description of moodCode above in section 1.2.2.1 for more details on the use of x_domains in this model.

SubstanceAdministration.priorityCode	Categorizes the priority of a substance administration
SubstanceAdministration.doseQuantity	Indicates how much medication is given per dose
SubstanceAdministration.rateQuantity	Can be used to indicate the rate at which the dose is to be administered (e.g. the flow rate for intravenous infusions)
SubstanceAdministration.maxDoseQuantity	Is used to capture the maximum dose of the medication that can be given over a stated time interval (e.g. maximum daily dose of morphine, maximum lifetime dose of doxorubicin)
SubstanceAdministration.effectiveTime	Is used to describe the timing of administration. It is modeled using the GTS data type to accommodate various dosing scenarios.

SubstanceAdministration.actNegationInd, when set to "true", is a positive assertion that the descriptive attributes of the SubstanceAdministration as a whole are negated. As discussed above, the inert properties of the Act Class such as SubstanceAdministration.id, SubstanceAdministration.moodCode, and the participations are not negated. These inert properties always have the same meaning: i.e. the author remains the author of the negative SubstanceAdministration. A substance administration statement with actNegationInd is still a statement about the specific fact described by the SubstanceAdministration. For instance, a negated "aspirin administration" means that the author positively denies that aspirin is being administered, and that he takes the same responsibility for such statement and the same requirement to have evidence for such statement than if he had not used negation.

The capture of medication-related information also involves the interrelationship of SubstanceAdministration with several other classes.

1.2.3.3 Supply

The Supply (SPLY) choice is a derivative of the RIM Supply class, used for representing the provision of a material (pharmacy, diet or nutritional supplement) by one entity to another. It includes requesting, recommending, promising, prohibiting or refusing such a supply, as well as the actual supply event.

Note that an outpatient prescription typically includes both a recommendation for SubstanceAdministration and a request to Supply.

This part of the pattern will further be harmonized with Pharmacy.

The value set for Supply.moodCode (CNE) may be taken from the x_ClinicalStatementSupplyMood. See the detailed description of moodCode above in section 1.2.2.1 for more details on the use of x_domains in this model, which now includes the value Definition (DEF).

The Supply class represents dispensing, whereas the SubstanceAdministration class represents administration. Prescriptions are complex activities that involve both an administration request to the patient (e.g. take Digoxin 0.125mg by mouth once per day) and a supply request to the pharmacy (e.g. dispense 30 tablets, with 5 refills). This should be represented by a SubstanceAdministration statement that has a component Supply statement. The nested Supply statement can have Supply.independentInd set to "false" to signal that the Supply cannot stand alone, without it's containing SubstanceAdministration.

1.2.3.4 Procedure

The Procedure (PROC) choice is a derivative of the RIM Procedure class, used for representing procedures. It is an act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. This includes requesting, recommending, promising, prohibiting or refusing to carry out a procedure as well as the actual act of undertaking the procedure.

The value sets for Procedure.moodCode (CNE) may be taken from the x_ClinicalStatementProcedureMood. See the detailed description of moodCode above in section 1.2.2.1 for more details on the use of x_domains in this model.

Procedure.actNegationInd, when set to "true", is a positive assertion that the descriptive attributes of the Procedure as a whole are negated. The inert properties such as Procedure.id, Procedure.moodCode and the participations are not negated. These inert properties always have the same meaning: i.e. the author remains the author of the negative Procedure. A procedure statement with actNegationInd is still a statement about the specific fact described by the Procedure. For instance, a negated "appendectomy performed" means that the author positively denies that there was ever an appendectomy performed, and that he takes the same responsibility for such statement and the same requirement to have evidence for such statement than if he had not used negation.

1.2.3.5 Encounter

An Encounter (ENC) choice is an interaction between a patient and care provider(s) for the purpose of providing healthcare-related service(s). Healthcare-related services include health assessment.

Note this type of statement covers admissions, discharges and transfers of care, as well as the more usual understanding of a single discrete office visit.

It further deals with a plan for regular visits, such as preventive care during pregnancy, or monitoring of chronic ill patients.

Includes requesting, proposing, promising, prohibiting or refusing an encounter as well as an actual encounter event.

The encounter is a derivative of the RIM PatientEncounter class, used to represent related encounters, such as follow-up visits or referenced past encounters.

The value sets for Encounter.moodCode (CNE), which now includes the value Definition (DEF), may be taken from the x_ClinicalStatementEncounterMood. See the detailed description of moodCode above in section 1.2.2.1 for more details on the use of x_domains in this model.

1.2.3.6 Organizer

An Organizer (ORGANIZER) choice is a derivative of the RIM Act class, which can be used to create groupings of other Clinical Statements that share a common context for navigational purposes. An Organizer can contain other Organizers and/or other Clinical Statement, by traversing the component relationship. An Organizer can refer to acts by reference or by value via the component relationship. An Organizer cannot be the source of the sourceOf1, sourceOf2, definition or conditions relationships.

The record entries relating to a single clinical session are usually grouped under headings that represent phases of the encounter, or assist with layout and navigation. The organizer represents a heading in a heading structure, or "organizer tree" and does not itself have any semantic content. Clinical headings usually reflect the clinical workflow during a care session, and might also reflect the main author's reasoning processes. Knowledge of the heading is not required to interpret contained Clinical Statements. Much research has demonstrated that headings are used differently by different professional groups and specialties, and that headings are not used consistently enough to support safe automatic processing of the EHR.

The value for Act.ClassCode has been changed to ActClassRecordOrganizer.

An Organizer typically can be assigned a SNOMED CT concept identifier appropriate to its type (for example a category might be identified as 'investigations' and a battery might be identified as 'Full blood count'). However, any kind of concept identifier can be used, such as in the case of the HL7 CDA R2 Implementation Guides where LOINC is frequently employed.

The Organizer may be used to harmonize hierarchical RECORD_COMPONENTs within and ENTRY object under either the CEN/ISO 13606 or openEHR standard with a Clinical Statement.

NOTE: Clinical Statement ActChoice Acts such as Observation can also contain other ActChoice Acts by traversing the sourceOf2 class. There is no requirement that the Organizer statement be used in order to group Clinical Statements.

The value sets for Organizer.moodCode (CNE) is fixed to EVN (Event).

1.2.3.7 Act Class

The Act (ACT) choice is a derivative of the RIM Act class, to be used when the other more specific classes are not appropriate.

Attributes of the Act Class include:

Act.actNegationInd: when set to "true", is a positive assertion that the descriptive attributes of the Act as a whole are negated. The inert properties such as Act.id, Act.moodCode, and the participations are not negated. These inert properties always have the same meaning: i.e., the author remains the author of the negative Act. An act statement with actNegationInd is still a statement about the specific fact described by the Act. For instance, a negated "finding of wheezing on July 1" means that the author positively denies that there was wheezing on July 1, and that he takes the same responsibility for such statement and the same requirement to have evidence for such statement than if he had not used negation.

The value for Act.moodCode (CNE) may be taken from the x_ClinicalStatementActMood, which now includes the value Risk (RSK). See the detailed description of moodCode below for more details on the use of x_domains in this model.

1.2.4 Relationships between Clinical Statements

The model provides three mechanisms that allow Clinical Statements to be linked by the Act Relationship Class:

• Containment
• Direct relationship
• Reference

These links may be achieved by one of three act relationships in the pattern described below:

• component
• sourceOf2/targetOf
• sourceOf1

These are all refinements of the same general structure and share the following facilities:

• inversionInd; when 'true' reverses the direction of the relationship e.g. 'Cause of' becomes 'Caused by' (see Context and Inheritance below for how this works with Context Inheritance)
• negationInd; when 'true' allows the sender to specifically state that the relationship does not apply e.g. An observation was not caused by a medication

There is some overlap in the potential use of these three relationship mechanisms that shall be resolved as follows:

1.2.4.1 Containment

Grouping of classes of clinical data is achieved using collector classes such as Organizer and Battery (a specialization of the Observation class code) associated with a 'Component' Act Relationship that supports recursion of the Clinical Statement structure.

Grouping can be used for many purposes, including:

• Relating statements. For example, an Antenatal exam may comprise individual observations of maternal weight, maternal BP, fetal size, fetal heart rate etc.
• Linking statements relating to a specific 'Problem' in the case of Condition Node

Organizer: The type of grouping permitted is restricted by the vocabulary used in the Organizer.code attribute. Specific vocabulary constraints will be applied in individual communication designs based on the communication requirement that is being addressed.

1.2.4.2 Direct relationship

This linkage type is supported by the recursion on the Clinical Statement, with ActRelationship.typeCode specifying the nature of the link between the statements. It is used to include a Clinical Statement in a communication that relates to another included Clinical Statement but is not directly pertinent to the Focal Act, source Act or purpose of the communication.

An example would be if a previous condition explains an observation made during an encounter. In this case the previous condition is only being included in the communication to explain the observation and not because it was identified during the encounter.

Where the supporting Clinical Statement is already available from a previous communication, the link by reference approach may be used to convey this type of linkage.

1.2.4.3 Reference

Linking Clinical Statements by reference is supported by the sourceOf1 Act Relationship between the Clinical Statement and ActReference, again with typeCode specifying the nature of the link. There are three cases for its use:

• To assert a link to a Clinical Statement that is already in the communication instance for another purpose, thus avoiding unnecessary duplication

• To assert a link to a Clinical Statement that is directly related to the purpose of the communication but has been sent as part of a prior notification

• To link to a Clinical Statement that is already available as a result of an unrelated communication.

The ActReference.classCode and ActReference.moodCode shall take the values of the target Act and ActReference.id is the unique identifier of the target Clinical Statement.

NOTE: The current methodology for ActReference is not ideal, since only the class name itself helps to know that this construct actually is an act reference and not just an act. RIM class names are not intended to be semantic markers. MnM are working to resolve this and are defining a way of unambiguously knowing that this is a reference. It is suggested that implementers refer to current MnM guidance, pre-adopting if necessary.

Alternatively, in many contexts, given the small nature of the ActReference, just ClassCode and MoodCode and Id, will serve to identify it - though this is a workaround at best.

1.2.4.4 Component

The component relationship is used to link the organizer class to one or more ActChoice Acts. The component.typeCode value is fixed to COMP (is component of) and is used to show that the target is a component of the source Organizer act (for instance "hemoglobin measurement" is a component of a "complete blood count"). The source Organizer can contain other Organizers and/or other Clinical Statements, by traversing the component relationship.

1.2.4.5 sourceOf2/targetOf

Clinical Statement has identified and modelled various link scenarios. These scenarios enable ActChoice Acts to be semantically linked to Acts that exist within the same document or message

NOTE: The Clinical Statement model permits any ActChoice Act to relate to any ActChoice Act using any of the following relationship types. In many cases, this would result in nonsensical relationships. The following table is a guideline for reasonable relationships between Clinical Statement Acts and is not a conformance constraint.

ActRelationship Type	Reasonable Source and Target classes	Comments
CAUS (is etiology for)	[Act | Observation | Procedure | SubstanceAdministration] CAUS [Observation]	Used to show that the source caused the target observation (for instance, source "diabetes mellitus" is the cause of target "kidney disease").
COMP (has component)	[Act | Observation | Procedure | SubstanceAdministration | Supply] COMP [Act | Observation | Procedure | SubstanceAdministration | Supply]	Used to show that the target is a component of the source (for instance "hemoglobin measurement" is a component of a "complete blood count").
GEVL (evaluates (goal))	[Observation] GEVL [Observation]	Used to link an observation (intent or actual) to a goal to indicate that the observation evaluates the goal (for instance, a source observation of "walking distance" evaluates a target goal of "adequate walking distance").
MFST (is manifestation of)	[Observation] MFST [Observation]	Used to say that the source is a manifestation of the target (for instance, source "hives" is a manifestation of target "penicillin allergy").
REFR (refers to)	[Act | Observation | Procedure | SubstanceAdministration | Supply] REFR [Act | Observation | ObservationMedia | Procedure | RegionOfInterest | SubstanceAdministration | Supply]	Used to show a general relationship between the source and the target, when the more specific semantics of the relationship isn't known.
RSON (has reason)	[Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply] RSON [Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply]	Used to show the reason or rational for a service (for instance source "treadmill test" has reason "chest pain").
SAS (starts after start)	[Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply] SAS [Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply]	The source Act starts after the start of the target Act (for instance source "diaphoresis" starts after the start of target "chest pain").
SPRT (has support)	[Observation] SPRT [Observation | ObservationMedia | RegionOfInterest]	Used to show that the target provides supporting evidence for the source (for instance source "possible lung tumor" has support target "mass seen on chest-x-ray").
SUBJ (has subject)	[Observation | RegionOfInterest] SUBJ [Observation | ObservationMedia]	Used to relate a source region of interest to a target image, or to relate an observation to its subject observation (for instance, source "moderate severity" has subject target "chest pain"). The ActRelationshipType "has subject" is similar to the ParticipationType "subject". Entries that primarily operate on physical subjects use the Participation, whereas entries that primarily operate on other entries use the ActRelationship.
XCRPT (is excerpt of)	[Act | Observation] XCRPT [Act | Observation | Procedure | SubstanceAdministration | Supply]	Used to show that the source is excerpted from the target (for instance source "hemoglobin value of 12" is an excerpt of target "complete blood count"). The distinction between an excerpt and an informant participant can be blurry ? such as in the case of recording a patient's medication history where the clinician may obtain the information from an informant or may excerpt the information from another computer system. An informant (or source of information) is a person who provides relevant information. An informant class is in the header, and can be overridden in the body. An excerpt is a sub portion of some other act.

The sourceOf2.inversionInd can be set to "true" to indicate that the relationship should be interpreted as if the roles of the source and target entries were reversed. In the example in the table above, "treadmill test" RSON (has reason) "chest pain". Inverted, this would have "chest pain" as the source and "treadmill test" as the target: "chest pain" RSON (inverted) "treadmill test". Inversion can be useful when the current context is describing the target of an act relationship that needs to be related back to the source.

1.2.4.6 sourceOf1

Clinical Statement has identified and modeled various reference scenarios. These scenarios enable ActChoice Acts to be semantically linked to Acts by reference that exist within the same document/message or to Acts external to it. Each object allows for an identifier.

A description of allowable, reference typeCode values are shown in the following table. As in the table above (sourceOf2/targetOf1 Types) this table is a guideline for reasonable relationships ActChoice acts and ActReference objects, and is not a conformance constraint.

ActRelationship Type	Reasonable Source and Target classes	Comments
ELNK (episode link)	[Observation] ELNK [ExternalObservation]	Used to show that the source and the target are part of the same episode (for instance, a diagnosis of "pneumonia" can be linked to an external problem list entry of "pneumonia" to show that the current diagnosis is part of the ongoing episode of pneumonia).
REFR (refers to)	[Act | Observation | Procedure | SubstanceAdministration | Supply] REFR [ExternalAct | ExternalDocument | ExternalObservation | ExternalProcedure]	Used to show a general relationship between the source and the target, when the more specific semantics of the relationship isn't known.
RPLC (replace)	[Act | Encounter | Observation | ObservationMedia | Organizer | Procedure | SubstanceAdministration | Supply] RPLC [ExternalAct | ExternalDocument | ExternalObservation | ExternalProcedure]	Used to indicate that the source statement is a replacement for the target external act.
SPRT (has support)	[Observation] SPRT [ExternalDocument | ExternalObservation]	Used to show that the target provides supporting evidence for the source.
SUBJ (has subject)	[Observation | RegionOfInterest] SUBJ [ExternalObservation]	Used to relate a source region of interest to a target image, or to relate an observation to its subject observation.
XCRPT (is excerpt of)	[Act | Observation] XCRPT [ExternalAct | ExternalDocument | ExternalObservation | ExternalProcedure]	Used to show that the source is excerpted from the target (for instance "the hemoglobin is 10.7" is an excerpt of an externally referenced "complete blood count").

1.2.4.7 Context and Inheritance

Although potentially complex, context inheritance provides an essential facility that:

• removes the need to explicitly state the full context of every Clinical Statement as in the general case this can be inherited from the source statement; and

• provides a mechanism that allows specific items of context to be overridden when appropriate. For instance the 'author' of a result for a battery is assumed to be the author for all the components but each test within the battery could be performed by a different person or device.

Following the HL7 v3 conventions the source class (the class at the 'blunt' end of the SourceOf arrow) always specifies the context in which the SourceOf was asserted. Thus this source class indicates the attribution (time, author, etc.) of the linkage. The semantic direction of the relationship type (as expressed by SourceOf.typeCode) can be reversed using the inversionInd. As this does not reverse the owning context it allows the full range of directional relationships to be expressed from the context of either of the related classes.

The seperatableInd in an Act Relationship indicates whether the author is willing to attest to the content of the source Act if it is separated from the target Act. A value of 'false' indicates that they intend that the two acts are not separated for interpretation. This clearly cannot be enforced, but is intended as a warning to the recipient of the author's intent. The value of the seperatableInd is not propagated beyond the target Act, regardless of other context inheritance.

For a full discussion of propagation and its representation, refer to the RIM section of the HL7 Version 3 Standard.

Act Relationships that have an ActReference as their target should never conduct context, as the context of the referenced Clinical Statement is defined from its original setting. See sourceOf1.blockedContextActRelationshipType and blockedContextParticipationType, and notes attached to that relationship.

1.2.5 Participations surrounding the Acts

Clinical statements can have various participations. Participations propagated from the focal or source Act can be overridden within the Clinical Statement. These participations include:

• recordTarget
• subject
• author
• consumable
• informant
• performer
• product
• location
• dataEnterer
• verifier
• responsibleParty

As well as applying to a patient, a Clinical Statement can also apply to a variety of other types of entity (e.g. equipment or population). To support this, the target of the "recordTarget" participation is an R_Subject, which contains options R_Patient and R_InvestigativeSubject. Similarly, the "subject" participation of a Clinical Statement can (via the R_SubjectOrRelatedEntityOrSpecimen CMET) be any one of several types of entity including:

• the patient
• another person (e.g. mother)
• an animal
• a specimen
• a facility
• an environmental site

In general, the RecordTarget is the main Entity for which an Act, for example a Care Provision, is carried out, whereas the Subject is only involved in this Act via an associated Act. It helps to distinguish a patient for whom a record is kept (record target), from a subject in a family history, such as details of the mother of the record target. Equipment, as devices, is supported by DEV participations from Procedure and Observation acts.

The value sets for typeCode (CNE) for all participants are defined in the RIM. Selected participations are detailed below.

1.2.5.1 recordTarget

The record target is the entity for which the Act is being recorded. There is normally only one record target for a Clinical Statement. In the case where multiple entities are involved, the record target is the main entity, and the subject can be an entity for which (whom) some underlying clinical statements are documented. For instance, if a pregnant woman is the entity for whom the Act is recorded, she is the recordTarget. If the fetal heart rate is recorded in a Clinical Statement, the fetus is the subject of this observation.

1.2.5.2 subject

The patient, via the recordTarget participation, is considered to be the subject of each Clinical Statement in the communication unless it is explicitly indicated that this is not the case for the specified statement(s). This can be indicated in one of the following ways:

• The Clinical Statement has a subject participation that provides details of the person or entity to whom the statement relates
• Optionally, in some realms, the SNOMED CT concept in the code attribute has a context that refers to someone other than the patient e.g. Father has history of Diabetes, or Fetus has a heart rate of 148.

1.2.5.3 author

Represents the humans and/or machines that authored the statements. This may be an assigned person or organization (R_AssignedEntity) such as a healthcare provider, a related party such as a family member or court, or the patient (R_Patient) themselves. The author participant can be ascribed to a Clinical Statement where it overrides the value(s) propagated from the focal or source act and propagates to nested Acts.

1.2.5.4 consumable

The consumable participation, linked to the SubstanceAdministration Act, is used to describe any orderable and administrable materials. Accordingly, the previous AgentChoice choice box has been replaced with a new all encompassing R_ClinicalStatementComsumableMaterial [universal] CMET, which consists of a choice of CommonProductModel (CPM) CMET and the current AdministrableMaterial construct.

The Material entity is used to identify non-drug administered substances such as vaccines and blood products, diets and nutritional supplements.

The value sets for R_ProductListed.classCode (CNE), R_ProductReportable.classCode (CNE), Material.classCode (CNE), and Material.determinerCode (CNE) are defined in the RIM.

1.2.5.5 informant

An informant (or source of information) is a person that provides relevant information, such as the parent of a comatose patient who describes the patient's behavior prior to the onset of coma. This may be an assigned person or organization (R_AssignedEntity) such as a healthcare provider, a related party such as a family member or court, or the patient (R_Patient) themselves. The R_RelatedEntity [universal] role is used to represent an informant without a role.id (e.g. a parent or individual on the street). The informant in this case bears some formal or personal relationship to the patient. RelatedEntity.code can be used to specify the nature of the relationship. The R_AssignedEntity role is used for an identified informant, and is scoped by an Organization. The informant participant, can be ascribed to a Clinical Statement where it overrides the value(s) propagated from the focal or source Act and propagates to nested Acts.

The value sets for the RelatedEntity.classCode (CNE) is defined in the RIM.

1.2.5.6 performer

The performer is a person who carries out or will carry out a particular act. The performer need not be the principal responsible participant, e.g. a surgery resident operating under supervision of attending surgeon is a performer.

1.2.5.7 product

The dispensed product associates the Supply act to the new R_ClinicalStatementProductModel [universal] comprising R_ProductListed, R_ProductReportable CMETS.

NOTE: In collapsing all the possible participations with the CPM into a single CMET, the CS Working Group acknowledges separate discussions may be required on how to address implants.

1.2.5.8 location

Describes the location that the Clinical Statement took place or is intended to take place. It uses a new R_ClinicalStatementLocation CMET which combines the A_SpatialCoordinates CMET with the LocationChoice roles that may optionally use the OrganizationChoice or PlaceChoice entities to describe the particular location of the Clinical Statement.

1.2.6 Acts and relationships outside the Choice Box

1.2.6.1 ControlActEvent

A Clinical Statement can be associated with the Control Act in the Clinical Statement pattern. Each message has a Control Act wrapper to represent the trigger event to which this message relates. The contents, participations and semantics of the Trigger Event Control act are conducted to each class in the message including each Clinical Statement. In some circumstances, mostly for messaging in transactional domains such as Laboratory and Pharmacy, it may be necessary to associate one or more Clinical Statements to an additional control act. The ControlActEvent has been placed in the Clinical Statement pattern so that those transactional domains that would like to be compliant with the Clinical Statement may use it in their models and remain Clinical Statement compliant.

In non-transactional messages it would be conceivable to use the control act to represent version history and to indicate that the Clinical Statements were subject to trigger events that differ from that in the Control Act wrapper. At present there are a number of areas where the V3 methodology does not support the use of control acts in non-transactional domains. It is advised that the control act is not included in messages derived from the Clinical Statement pattern in non-transactional domains.

1.2.6.2 referenceRange

The referenceRange relationship (described above, see Observation), has a source of Observation, and a target that is another Clinical Statement.

1.2.6.3 conditions

The precondition class, derived from the ActRelationship class, is used along with the Criterion class to express a condition that must hold true before some other activity occurs.