HL7 State MachineLab States (StatusCodes) POLB_TE004007UV01

The result has experienced some sort of state or status change. No distinction is made between changes to the focal act or the component acts. This trigger event is used to report any kind of changes that occur to a result to a tracker type application role.

LifeCycle Requirement

To represent LifeCycle [LC], CDA needs to associate any Entry with its history moving from creation to completion• Each Historical “snapshot” of Entry in LC should

– Represent the LC state for the Entry using ProvenanceEvent Actcodes

• Should be comparable to Record Entry Acts• Baseline =>DataOperations codes + GAP coded concepts

– Optionally support relevant participations

Entry Level Provenance Organizer + CDA Provenance Capability

DataOperations => ProvenanceEvent.code

Propose that DataOperations code system be made Act.code coded concepts• Enables use with Entry Act Provenance

Organizer Template• ProvenanceOrganizer is composed of [1…*]

ProvenanceEvents • Each has a SUCC (succeeds) Relationship to

each predecessor ProvenanceEvent

ActRelationship SUCC (succeeds)Among ProvenanceEvents

Use SUCC to specify relationship among ProvenanceEventsLEAF CONCEPT:SUCC (succeeds)Definition: A new act that carries forward the intention of the original act, but does not completely replace it. The status of the predecessor act must be 'completed'. The original act is the target act and the successor is the source act.

RM-ES LifeCycle Actions/Events

RI.1.1.1 Originate and Retain Record Entry

RI.1.1.2 Amend Record Entry Content

RI.1.1.3 Translate Record Entry Content

RI.1.1.4 Attest Record Entry Content

RI.1.1.5 View/Access Record Entry Content

RI.1.1.6 Output/Report Record Entry Content

RI.1.1.7 Disclose Record Entry Content

RI.1.1.8 Transmit Record Entry Content

RI.1.1.9 Receive and Retain Record Entries

RI.1.1.10 De-identify Record Entries

RI.1.1.11 Pseudonymize Record Entries

RI.1.1.12 Re-identify Record Entries

RI.1.1.13 Extract Record Entry Content

RI.1.1.14 Archive Record Entries

RI.1.1.15Restore (previously archived) Record Entries

RI.1.1.16Destroy or Identify Record Entries as Missing

RI.1.1.17Deprecate/Retract Record Entries

RI.1.1.18Re-Activate Record Entries

RI.1.1.19Merge Record Entries

RI.1.1.20Unmerge Record Entries

RI.1.1.21Link Record Entries

RI.1.1.22Unlink Record Entries

RI.1.1.23Place Record Entries on Legal HoldRI.1.1.24Release Record Entries from Legal Hold

LifeCycle [LC] / LifeSpan [LS]Support in DataOperations Vocabulary

GAPS?• Annotate• Aggregate• Derive/Excerpt• Attest

• De-identify• Pseudonymize• Legal Hold• Link/Unlink

• De-identify• Pseudonymize• Legal Hold• Link/Unlink

Data Operations HierarchyStrategy

Way with Verbs Project is working toward Harmonization of the Action Verbs used by EHR FM and in Security RBAC• When project is complete, we

can re-do the ProvenanceEvent codes

• For Harmonization, we can propose some quick fixes to current Operations codes

• Proposal approval needed for balloting DPROV CDA

DataOperation      [2.16.840.1.113883.5.1123]

Lvl- Typ

Concept Code  Head Code-defined Value Set

Print Name Definition, Properties, Relationships

0-S OPERATE operate Definition:Description:Act on an object or objects. Concept Relationships:  Generalizes (derived): CREATE DELETE EXECUTE READ UPDATE

1-L . CREATE create Definition:Description:Fundamental operation in an Information System (IS) that results only in the act of bringing an object into existence. Note: The preceding definition is taken from the HL7 RBAC specification. There is no restriction on how the operation is invoked, e.g., via a user interface. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: OPERATE

1-L . DELETE deleteremove

Definition:Description:Fundamental operation in an Information System (IS) that results only in the removal of information about an object from memory or storage. Note: The preceding definition is taken from the HL7 RBAC specification. There is no restriction on how the operation is invoked, e.g., via a user interface. Concept Relationships:  Specializes: OPERATE

1-L . EXECUTE execute Definition:Description:Fundamental operation in an IS that results only in initiating performance of a single or set of programs (i.e., software objects). Note: The preceding definition is taken from the HL7 RBAC specification. There is no restriction on how the operation is invoked, e.g., via a user interface. Concept Relationships:  Specializes: OPERATE

1-L . READ read Definition:Description:Fundamental operation in an Information System (IS) that results only in the flow of information about an object to a subject. Note: The preceding definition is taken from the HL7 RBAC specification. There is no restriction on how the operation is invoked, e.g., via a user interface. Concept Relationships:  Specializes: OPERATE

DataOperation Codes

Lvl- Typ

Concept Code  Head Code-defined Value Set

Print Name Definition, Properties, Relationships

1-S . UPDATE reviseupdate

Definition:Definition:Fundamental operation in an Information System (IS) that results only in the revision or alteration of an object. Note: The preceding definition is taken from the HL7 RBAC specification. There is no restriction on how the operation is invoked, e.g., via a user interface. Concept Relationships:  Specializes: OPERATE  Generalizes (derived): APPEND MODIFYSTATUS

2-L . . APPEND append Definition:Description:Fundamental operation in an Information System (IS) that results only in the addition of information to an object already in existence. Note: The preceding definition is taken from the HL7 RBAC specification. There is no restriction on how the operation is invoked, e.g., via a user interface. Concept Relationships:  Specializes: UPDATE

2-S . . MODIFYSTATUS

modify status Definition:Description:Change the status of an object representing an Act. Concept Relationships:  Specializes: UPDATE  Generalizes (derived): ABORT ACTIVATE CANCEL COMPLETE HOLD JUMP NULLIFY OBSOLETE REACTIVATE RELEASE RESUME SUSPEND

3-L . . . ABORT abort Definition:Description:Change the status of an object representing an Act to "aborted", i.e., terminated prior to the originally intended completion. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . ACTIVATE activate Definition:Description:Change the status of an object representing an Act to "active", i.e., so it can be performed or is being performed, for the first time. (Contrast with REACTIVATE.) For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . CANCEL cancel Definition:Description:Change the status of an object representing an Act to "cancelled", i.e., abandoned before activation. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

DataOperation Codes[2.16.840.1.113883.5.1123]Slide 1 of 3

Lvl- Typ

Concept Code  Head Code-defined Value Set

Print Name Definition, Properties, Relationships

3-L . . . COMPLETE

complete Definition:Description:Change the status of an object representing an Act to "completed", i.e., terminated normally after all of its constituents have been performed. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . HOLD hold Definition:Description:Change the status of an object representing an Act to "held", i.e., put aside an Act that is still in preparatory stages. No action can occur until the Act is released. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . JUMP jump Definition:Description:Change the status of an object representing an Act to a normal state. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . NULLIFY nullify Definition:Description:Change the status of an object representing an Act to "nullified", i.e., treat as though it never existed. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . OBSOLETE

obsolete Definition:Description:Change the status of an object representing an Act to "obsolete" when it has been replaced by a new instance. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

DataOperation CodesSlide 1 of 3

Lvl- Typ

Concept Code  Head Code-defined Value Set

Print Name

Definition, Properties, Relationships

3-L . . . REACTIVATE

reactivate Definition:Description:Change the status of a formerly active object representing an Act to "active", i.e., so it can again be performed or is being performed. (Contrast with ACTIVATE.) For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . RELEASErelease Definition:Description:Change the status of an object representing an Act so it is no longer "held", i.e., allow action to occur. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . RESUME resume Definition:Description:Change the status of a suspended object representing an Act to "active", i.e., so it can be performed or is being performed. For an HL7 Act, the state transitions per the HL7 Reference Information Model. Concept Relationships:  Specializes: MODIFYSTATUS

3-L . . . SUSPEND

suspend Definition:Definition:Change the status of an object representing an Act to suspended, i.e., so it is temporarily not in service. Concept Relationships:  Specializes: MODIFYSTATUS

DataOperation Codes

LifeSpan [LS] Entry Level

Business requirement is to enable exchange of Document and Entry Level LS• Support by adding ActRelationship codes

needed to convey LS Provenance to following value sets:

Provenance Organizer

• Provenance Organizer has 1…* component Provenance Acts

• Each component Provenance Act has entryRelationship = SUCC

• Each component of Each Organizer may have 0…* author, attester, informant, custodian, participant participations

Entry Level Provenance Organizer + CDA Provenance Capability

HL7 ActRelationshipType codes (subset related to provenance)

1-S SEQL .

is sequel Definition: An act relationship indicating that the source act follows the target act. The source act should in principle represent the same kind of act as the target. Source and target need not have the same mood code (mood will often differ). The target of a sequel is called antecedent. Examples for sequel relationships are: revision, transformation, derivation from a prototype (as a specialization is a derivation of a generalization), follow up, realization, instantiation.

2-L APND . .

is appendage Definition: An addendum (source) to an existing service object (target), containing supplemental information. The addendum is itself an original service object linked to the supplemented service object. The supplemented service object remains in place and its content and status are unaltered.

2-L COMPLY . .

complies with Definition: The source act complies with, adheres to, conforms to, or is permissible under (in whole or in part) the policy, contract, agreement, law, conformance criteria, certification guidelines or requirement conveyed by the target act.

Examples for compliance relationships are: audits of adherence with a security policy, certificate of conformance to system certification requirements, or consent directive in compliance with or permissible under a privacy policy.

2-L DOC . .

documents Definition: The source act documents the target act.

2-L REV . .

reverses Definition: A relationship between a source Act that seeks to reverse or undo the action of the prior target Act. Example: A posted financial transaction (e.g., a debit transaction) was applied in error and must be reversed (e.g., by a credit transaction) the credit transaction is identified as an undo (or reversal) of the prior target transaction. Constraints: the "completion track" mood of the target Act must be equally or more "actual" than the source act. I.e., when the target act is EVN the source act can be EVN, or any INT. If the target act is INT, the source act can be INT.

2-L RPLC . .

replaces Definition: A replacement source act replaces an existing target act. The state of the target act being replaced becomes obsolete, but the act is typically still retained in the system for historical reference. The source and target must be of the same type.

2-L SUCC . .

succeeds Definition: A new act that carries forward the intention of the original act, but does not completely replace it. The status of the predecessor act must be 'completed'. The original act is the target act and the successor is the source act.

2-L UPDT . .

updates (condition)

Definition: A condition thread relationship specifically links condition nodes together to form a condition thread. The source is the new condition node and the target links to the most recent node of the existing condition thread.

2-S XCRPT . .

Excerpts Definition: The source is an excerpt from the target.

3-L VRXCRPT . . .

Excerpt verbatim Definition: The source is a direct quote from the target. Specializes: XCRPT

2-L XFRM . .

transformation Definition: Used when the target Act is a transformation of the source Act. (For instance, used to show that a CDA document is a transformation of a

DICOM SR document.)

ActRelationshipType Codes

ActRelationship Value Sets

X_ActRelationshipEntryRelationshipCurrent in CDA at Entry Level – GAPS?

• COMP can be used to indicate non-specific aggregation or composition relationship

• SAS could indicate succession at in Lifecycle – but would SUCC be better?

• SUBJ can be used to relate an Entry to a Provenance Act

• XCRPT can be used to indicate that one Entry is excerpted from another Entry

GAP?• DRIV – What’s the diff with XCRPT• RPLC – What’s the use case• PERT – Might be useful for Trust

Labels• XFORM – is there a use case for one

Entry to be a Transform of another?

Other ActRelationshipsSUCC

LEAF CONCEPT: SUCC (succeeds)KC – Seems like best fit for AR from Last ProvenanceEvent to preceding for LifeCycle Description:Definition: A new act that carries forward the intention of the original act, but does not completely replace it. The status of the predecessor act must be 'completed'. The original act is the target act and the successor is the source act.

Other ActRelationships Of InterestUPDT

LEAF CONCEPT:UPDT (updates (condition))KC – Could be used for LS/LCDescription:A condition thread relationship specifically links condition nodes together to form a condition thread. The source is the new condition node and the target links to the most recent node of the existing condition thread.

x_ActRelationshipExternalReference

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 entry 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").

Reference ActRelationship

4.3.8.5

• CDA entries can reference external objects such as external images and prior reports. These external objects are not

part of the authenticated document content. They contain sufficient attributes to enable an explicit reference rather

than duplicating the entire referenced object. The CDA entry that wraps the external reference can be used to

encode the specific portions of the external reference that are addressed in the narrative block.

• Each object allows for an identifier and a code, and contains the RIM Act.text attribute, which can be used to store

the URL and MIME type of the object. External objects always have a fixed moodCode of "EVN".

• The reference class contains the attribute reference.seperatableInd, which indicates whether or not the source is

intended to be interpreted independently of the target. The indicator cannot prevent an individual or application

from separating the source and target, but indicates the author's desire and willingness to attest to the content of

the source if separated from the target. Typically, where seperatableInd is "false", the exchanged package should

include the target of the reference so that the recipient can render it.

• A description of allowable reference.typeCode values are shown in the following table. As in the table above (CDA

entryRelationship Types), the following table is a guideline for reasonable relationships between CDA entries and

external objects, and is not a conformance constraint.

ParticipationFunction Harmonization ProposalREVIEWER – Business Requirement

• esMD requested a new ParticipationType REVIEWER

• Request was [reportedly] declined because ParticipationType is fixed in CDA as a structural code– May be possible to extend CDA if cost/benefit

pans out

RIM Participation.functionCode

Participation.functionCode :: CD (0..1) Property conformance: U Concept domain: ParticipationFunctionDefinition: Additional detail about the function that the Participation has in the Act, if such detail is not implied by the Participation.typeCode.Usage Constraint:No HL7 standard specification may be written to depend on the functionCode. When such a constraint is deemed necessary, it is to be defined in the Participation.typeCode. UsageNotes:This code can accommodate a variety of functions greater than that which can be managed in the tightly controlled typeCode. The numbers and kinds of functions applicable depend on the specific kind of act, e.g., each operation may require a different number of assistant surgeons or nurses. Since Participation functions refer to what people do in an Act, they are effectively sub-activities that may all occur in parallel. If more detail needs to be captured about these activities than who does them, component acts should be used instead.

ParticipationFunction Harmonization ProposalREVIEWER - Recommendation

May add fine detail with ParticipationFunction• However, no way to test conformance and

receiver can ignore while maintaining Recommendation:• Add new REVIEWER ParticipationFunction• Usage Note to indicate that REVIEWER is to be

used with the ParticipationType = VERIFER

ReviewerDescription/Definition

REVIEWER Description:• Specifies the exact function an actor is

authorized to have as a verifier of an Act.• Usage Note:

– Used to more fully specify the VERIFER ParticipationType

ParticipationTypeVRF (verifier)

REVIEWER adds specificity to VRF without connoting attestationSPECIALIZABLE CONCEPT:VRF (verifier)Description:A person who verifies the correctness and appropriateness of the service (plan, order, event, etc.) and hence takes on accountability.

• ABSTRACT CONCEPT:_AuthorizedParticipationFunction [abstract term]

• Description:• <p>This code is used to specify the exact function an actor is

authorized to have in a service in all necessary detail.</p>• Concept Properties:• internalId: 22338Concept Relationships:• Generalizes (derived): _AuthorizedReceiverParticipationFunction• Generalizes (derived): _ConsenterParticipationFunction• Generalizes (derived): _OverriderParticipationFunction• Generalizes (derived):ReviewerKC – could have truncated code, e.g., RWER but not necessary

New ParticipationType/ParticipationFunction?ASSEMBLER [assembly software]

• Business Need – convey Assembling Software that was used to generate Document or Entry

• Could propose ASSEMBLER as new ParticipationType code but this would be an extension.

• Proposed ASSEMBLER Definition: A device that operates on custodian’s algorithms for data extraction for purpose of generating an artifact.

New ParticipationFunctionASSEMBLER [assembly software]

Could make ParticipationFunction to SPECIALIZABLE CONCEPT: DEV (device)• Description: Participant used in performing

the act without being substantially affected by the act (i.e. durable or inert with respect to that particular service). Examples: monitoring equipment, tools, but also access/drainage lines, prostheses, pace maker, etc.