| POLB_MT004000UV01 Result Event |
Derived from RMIM: POLB_RM004000UV01 and HMD: POLB_HD004000UV01 |
||||||||
| ObservationEventChoice | |||||||||
| specimen [0..*] (Specimen) |
Design Comments: Used to identify the specimen on which the observations are made. The specimen may be any of the entities available in the specimen CMET playing the role of Specimen/Isolate/Aliquot. (see specimen CMET walk through). |
||||||||
| recordTarget [0..1] (RecordTarget) |
Design Comments: This participation is used to identify the subject to whom the ObservationEventChoice relates. Details of the subject are carried in the Subject CMET. The Subject identified here is not necessarily the source of the specimen. Where there is a requirement to identify a different source for the specimen, this is achieved through the specimen CMET via the subject participation. There is a constraint on the recordTarget that it will only be associated with the root ObservationEventChoice. |
||||||||
| performer [0..*] (Performer) |
Design Comments: Identifies the performer of the ObservationEventChoice. This may be an organization, device, individual or patient. The details about the performer are carried in performerChoice AssignedPerson CMET, the AssignedDevice CMET, or the Patient Clinical CMET. |
||||||||
| author [0..*] (Author1) |
Design Comments: The entity responsible for creating the observation. This may be an organization, device or individual. For observations generated by a device it would be the device. UsageNotes: The report date and time will be communicated in the author participation time attribute. |
||||||||
| transcriber [0..1] (DataEnterer1) |
Design Comments: Identifies the person/device transcribing the data, details of which are carried in the AssignedEntity CMET. |
||||||||
| informationRecipient [0..*] (InformationRecipient1) |
Design Comments: The intended recipient(s) of the observations. This is used to identify copy recipients of results. These may be individuals, organizations or devices and are carried in the AssignedEntity CMET. |
||||||||
| verifier [0..*] (Verifier) |
Design Comments: Identifies one or more individuals who verify the content of the ObservationEventChoice, details of which are carried in the AssignedEntity CMET. |
||||||||
| inFulfillmentOf [0..*] (InFulfillmentOf2) |
Design Comments: This association provides a mechanism to relate zero to many orders or promises to each ObservationEventChoice. The model provides a choice of a FulfillerPromise, PlacerOrder or A_PlacerOrder CMET in which to convey information about the Promises and Placer Order(s) being fulfilled. This inFulFillmentOf act relationship connects to the FulFillmentChoice, but there is a constraint that the target of the relationship must be PlacerOrder or A_PlacerOrder universal. This allows the complete chain of fulfillment to be represented in the message: ObservationEventChoice -> FulfillerPromise -> PlacerOrder. |
||||||||
| definition [0..*] (Definition) |
Design Comments: The definition act relationship is used to associate a ObservationReport, ObservationBattery, SpecimenObservationCluster or ObservationEvent with its ActDefinition (master file). The source act is an instance of the target definition act. |
||||||||
| reason [0..*] (Reason) |
Design Comments: Each ObservationEventChoice may have zero to many reasons associated with it. The SupportingClinicalInformation CMET is used to carry this information. |
||||||||
| pertinentInformation [0..*] (PertinentInformation) |
Design Comments: An ObservationEventChoice is associated with zero to many items of supporting clinical information that are pertinent to the event. The information is carried in the SupportingClinicalStatement CMET. |
||||||||
| component1 [0..*] (Component2) |
Design Comments: For each message instance, one of the acts within the ObservationEventChoice shall be selected as the 'Focal act' for the result. If there is a requirement for observations to be grouped together, this may be achieved using the Component Act Relationship recursion. For example, the ObservationReport act may serve as the focal act, with multiple component items carried in the ObservationBattery, SpecimenObservationCluster or ObservationEvent acts. The recursion carries a number of constraints: The ObservationReport may have ObservationReports, ObservationBattery's, SpecimenObservationClusters, and ObservationEvents as components. This allows for repeating report headers within a result. The ObservationBattery may have ObservationEvents as components. The SpecimenObservationCluster may have ObservationBattery's and ObservationEvents as components. The ObservationEvent may have ObservationEvents as components. Mapping: There are several 2.x equivalent structures for this association. The first is the relationship between the OBR segment and its associated OBX's. The second equivalent is OBR 29 Parent field which creates a relationship between child OBR and its parent OBR. In 2.x this parent child linking of OBR's is handled via references to the parent OBR identifiers. In V3, the parent/child relationships are handled structurally in the messages, meaning no identifiers are needed to create the association. |
||||||||
| component2 [0..*] (Component3) |
Design Comments: Each ObservationEventChoice act may have one or more component ProcessSteps. Where the ProcessStep is a specimen collection, information about the collector may be carried in the Collector role linked through the participation. ProcessSteps cover activities such as accessioning, collection, transportation, and result processing. Virtually any workflow step in the laboratory can be communicated here. The statusCode attribute has been provided to allow the filler to indicate the state of a process step (including completion). The performer participation from the ProcessStep act is used where the ProcessStep.ActClass is SPECCOLLECT. The Collector role has a class code from x_CollectorClassCodes and a Role.code from CollectorRoleType. |
||||||||
| subjectOf1 [0..*] (Subject1) |
Design Comments: The result act may be the subject of zero to many ControlActEvents. These Control Acts communicate the trigger event and other "action" information regarding the associated act. This structure is useful for historical query responses and result communications. |
||||||||
| subjectOf2 [0..*] (Subject2) |
Design Comments: The result act my be the subject of zero to many Annotations. Annotations include any sort result comments, special instructions, etc. |
||||||||
| componentOf [0..1] (Component1) |
Design Comments: Provides a link between the result and the Encounter by means of the encounter CMET. |
||||||||
| choice of ObservationReport |
Design Comments: The ObservationReport act serves as an optional header for a group of related reports, batteries, clusters or observations. Its target may be another ObservationReport, ObservationBattery, SpecimenObservationCluster, or an ObservationEvent. Specimen centric ObservationReports will associate the specimen at the ObservationReport level, allowing this specimen to be inherited by component acts. In the case of specimen centric reports, component acts may have additional specimens associated with them, but they should be aliquots or isolates of the specimen associated with the ObservationReport. Non-Specimen centric ObservationReports normally will not have specimens related at this level. Specimens associated with component acts may have specimens associated with them, but those specimens are not necessarily related. |
||||||||
| or ObservationBattery |
Design Comments: The ObservationBattery represents a set of observations. These observations typically have a logical or practical grouping for generally accepted clinical or functional purposes, such as observations that are run together because of automation. A battery can define required and optional components and, in some cases, will define complex rules that determine whether or not a particular observation is made. Examples include "Full blood count", "Chemistry panel". The ObservationBattery may have ObservationEvents as components. It shall not have ObservationReports or SpecimenObservationClusters as components. An ObservationBattery may inherit the specimen from an ObservationReport (if one is present). The ObservationBattery may also be the initial act in a Result Event message. In that case any specimen associated with the battery would be inherited by the component acts of the battery. |
||||||||
| or SpecimenObservationCluster |
Design Comments: The SpecimenObservationCluster represents a set of batteries and observations. All the batteries and observations are related to the specimen associated with the SpecimenObservationCluster. For microbiology the SpecimenObservationCluster represents all the batteries and observations related to a single isolate. The subject of a SpecimenObservationCluster must be either a specimen isolate or a specimen aliquot. The target of a SpecimenObservationCluster must be either an ObservationBattery or an ObservationEvent. An SpecimenObservationCluster may inherit the specimen from an ObservationReport (if one is present). Normally, the SpecimenObservationCluster will identify its own specimen, but that specimen must be an isolate or aliquot of the specimen inherited from the ObservationReport. The SpecimenObservationCluster may also be the initial act in a Result Event message. In that case any specimen associated with the cluster would be inherited by the component acts of the cluster. |
||||||||
| or ObservationEvent |
Design Comments: The ObservationEvent represents a related group of observations. Observations are actions performed in order to determine an answer or result value. Observation result values (Observation.value) include specific information about the observed object. The ObservationEvent is distinguished from the other 3 choices within ObservationEventChoice in that it is the choice which can carry a value (i.e., an actual result). The target of an ObservationEvent may be another ObservationEvent. ObservationReport, ObservationBattery, and SpecimenObservationCluster may not be targets of an ObservationEvent. The ObservationEvent may be the component of an ObservationReport, ObservationBattery, SpecimenObservationCluster, or ObservationEvent. In this case the ObservationEvent can inherit any specimens associated with the parent act. If the parent has a specimen associated with it, and ObservationEvent also has a specimen, the specimen associated with the ObservationEvent must be an isolate or aliquot of the parent acts specimen. The ObservationEvent may also be the initial act in a Result Event message. In that case any specimen associated with the ObservationEvent would be inherited by the component acts of the cluster. It should be noted that there is an entire school of result messaging which will only utilize the ObservationEvent choice within the ObservationEventChoice. ObservationEvent can essentially replace each of the ObservationReport, ObservationBattery, and SpecimenObservationCluster. UsageNotes: The ObservationEvent effective time should only be used when an ObservationEvent is not associated with a specimen. When an ObservationEvent is associated with a specimen, the effective time of the ObservationEvent is the collection time of that specimen. |
||||||||
| Specimen |
Design Comments: Used to identify the specimen on which the observations are made. The specimen may be any of the entities available in the specimen CMET playing the role of Specimen/Isolate/Aliquot. (see specimen CMET walk through). |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationSpecimen, root= "SPC"} |
Design Comments: The typeCode is constrained to "SPC". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| specimenChoice [1..1] (R_SpecimenUniversal) | |||||||||
| RecordTarget |
Design Comments: This participation is used to identify the subject to whom the ObservationEventChoice relates. Details of the subject are carried in the Subject CMET. The Subject identified here is not necessarily the source of the specimen. Where there is a requirement to identify a different source for the specimen, this is achieved through the specimen CMET via the subject participation. There is a constraint on the recordTarget that it will only be associated with the root ObservationEventChoice. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationRecordTarget, root= "RCT"} |
Design Comments: The typeCode is constrained to "RCT". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| subjectChoice [1..1] (R_SubjectUniversal) | |||||||||
| Performer |
Design Comments: Identifies the performer of the ObservationEventChoice. This may be an organization, device, individual or patient. The details about the performer are carried in performerChoice AssignedPerson CMET, the AssignedDevice CMET, or the Patient Clinical CMET. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationPhysicalPerformer, root= "PRF"} |
Design Comments: The typeCode is constrained to "PRF". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| noteText [0..1] Participation (ST) |
Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only. |
||||||||
| time [0..1] Participation (IVL<TS>) |
Design Comments: An interval of time specifying the time during which the performer is involved in the observation act through this Participation. |
||||||||
| performerChoice [1..1] (PerformerChoice) | |||||||||
| PerformerChoice | |||||||||
| choice of R_AssignedPersonUniversal | |||||||||
| or R_AssignedDeviceUniversal | |||||||||
| or R_PatientClinical | |||||||||
| Author1 |
Design Comments: The entity responsible for creating the observation. This may be an organization, device or individual. For observations generated by a device it would be the device. UsageNotes: The report date and time will be communicated in the author participation time attribute. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationAuthorOriginator, root= "AUT"} |
Design Comments: The typeCode is constrained to "AUT". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| noteText [0..1] Participation (ST) |
Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only. |
||||||||
| time [1..1] Participation (TS) |
Design Comments: An interval of time specifying the time during which the author is involved in the act through this Participation. The report date and time will be communicated in the author participation time attribute. |
||||||||
| modeCode [0..1] Participation (CD) {CNE:D:ParticipationMode} |
Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act. |
||||||||
| signatureCode [0..1] Participation (CD) {CNE:D:ParticipationSignature} |
Design Comments: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed. |
||||||||
| signatureText [0..1] Participation (ED) |
Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability. |
||||||||
| assignedEntity [1..1] (R_AssignedEntityUniversal) | |||||||||
| DataEnterer1 |
Design Comments: Identifies the person/device transcribing the data, details of which are carried in the AssignedEntity CMET. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationInformationTranscriber, root= "TRANS"} |
Design Comments: The typeCode is constrained to "TRANS". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| noteText [0..1] Participation (ST) |
Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only. |
||||||||
| time [0..1] Participation (TS) |
Design Comments: An interval of time specifying the time during which the transcriber is involved in the Observation through this Participation. |
||||||||
| modeCode [1..1] (M) Participation (CD) {CWE:D:ParticipationMode} |
Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act. |
||||||||
| assignedEntity [1..1] (R_AssignedEntityUniversal) | |||||||||
| InformationRecipient1 |
Design Comments: The intended recipient(s) of the observations. This is used to identify copy recipients of results. These may be individuals, organizations or devices and are carried in the AssignedEntity CMET. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationInformationRecipient, root= "IRCP"} |
Design Comments: The typeCode is constrained to "IRCP". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
|||||||||
| time [0..1] Participation (IVL<TS>) |
Design Comments: An interval of time specifying the time during which the information recipient is involved in the Observation through this Participation. |
||||||||
| assignedEntity [1..1] (R_AssignedEntityUniversal) | |||||||||
| Verifier |
Design Comments: Identifies one or more individuals who verify the content of the ObservationEventChoice, details of which are carried in the AssignedEntity CMET. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationVerifier, root= "VRF"} |
Design Comments: The typeCode is constrained to "VRF". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| noteText [0..1] Participation (ST) |
Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only. |
||||||||
| time [1..1] Participation (TS) |
Design Comments: An interval of time specifying the time during which the verifier is involved in the act through this Participation. |
||||||||
| modeCode [0..1] Participation (CD) {CWE:D:ParticipationMode} |
Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act. |
||||||||
| signatureCode [0..1] Participation (CD) {CNE:D:ParticipationSignature} |
Design Comments: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed. |
||||||||
| signatureText [0..1] Participation (ED) |
Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability. |
||||||||
| assignedEntity [1..1] (R_AssignedEntityUniversal) | |||||||||
| InFulfillmentOf2 |
Design Comments: This association provides a mechanism to relate zero to many orders or promises to each ObservationEventChoice. The model provides a choice of a FulfillerPromise, PlacerOrder or A_PlacerOrder CMET in which to convey information about the Promises and Placer Order(s) being fulfilled. This inFulFillmentOf act relationship connects to the FulFillmentChoice, but there is a constraint that the target of the relationship must be PlacerOrder or A_PlacerOrder universal. This allows the complete chain of fulfillment to be represented in the message: ObservationEventChoice -> FulfillerPromise -> PlacerOrder. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipFulfills, root= "FLFS"} |
Design Comments: The typeCode for inFulfillmentOf is constrained to "FLFS". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of ON has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'false" has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. Mapping: There is no 2.x equivalent. |
||||||||
| fullfillmentChoice [1..1] (FullfillmentChoice) | |||||||||
| FullfillmentChoice | |||||||||
| choice of FulfillerPromise |
Design Comments: The promise which the associated ObservationEventChoice fulfills. This is essentially a stub which identifies the promise. One thing to note is the inclusion of the statusCode attribute here. When the ObservationEventChoice act is being marked as completed, the filler can also communicate that the associated promise being fulfilled is also complete. This can be done because the filler manages the state of both the event and the promise. |
||||||||
| or PlacerOrder |
Design Comments: The order which the associated ObservationEventChoice fulfills. This is a stub which identifies the order. No status attribute is included here because the filler does not manage the PlacerOrder. |
||||||||
| FulfillerPromise |
Design Comments: The promise which the associated ObservationEventChoice fulfills. This is essentially a stub which identifies the promise. One thing to note is the inclusion of the statusCode attribute here. When the ObservationEventChoice act is being marked as completed, the filler can also communicate that the associated promise being fulfilled is also complete. This can be done because the filler manages the state of both the event and the promise. |
||||||||
| classCode [1..1] (M) Act (CS) {CNE:V:ActClassRoot, root= "ACT"} |
Design Comments: The classCode for FulfillerPromise is constrained to "ACT". |
||||||||
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodPromise, root= "PRMS"} |
Design Comments: FulfillerPromise is in Promise mood. This has been fixed to "PRMS" in the RMIM. |
||||||||
| id [1..*] (M) Act (DSET<II>) |
Design Comments: The FulfillerPromise.id attribute is used to distinguish this promise from all other promises. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id. Mapping: The filler order number in OBR 3 is the 2.x equivalent for this attribute. |
||||||||
| statusCode [1..1] (M) Act (CS) {CNE:V:ActStatus} |
Design Comments: The FulfillerPromise.statusCode attribute is used to report the status of the Promise object. The allowed statuses for the FulfillerPromise are associated with the Promise dynamic model. Only the states allowed by the Promise dynamic model can be communicated in this attribute. |
||||||||
| inFulfillmentOf [0..*] (InFulfillmentOf3) |
Design Comments: This inFulFillmentOf act relationship associates the FufillerPromise to the FulFillmentChoice. This allows the complete chain of fulfillment to be represented in the message: ObservationEventChoice -> FulfillerPromise -> PlacerOrder. |
||||||||
| InFulfillmentOf3 |
Design Comments: This inFulFillmentOf act relationship associates the FufillerPromise to the FulFillmentChoice. This allows the complete chain of fulfillment to be represented in the message: ObservationEventChoice -> FulfillerPromise -> PlacerOrder. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipFulfills, root= "FLFS"} |
Design Comments: The typeCode for inFulfillmentOf is constrained to "FLFS". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of ON has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'false" has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. Mapping: There is no 2.x equivalent. |
||||||||
| fullfillmentChoice [1..1] (FullfillmentChoice) | |||||||||
| PlacerOrder |
Design Comments: The order which the associated ObservationEventChoice fulfills. This is a stub which identifies the order. No status attribute is included here because the filler does not manage the PlacerOrder. |
||||||||
| classCode [1..1] (M) Act (CS) {CNE:V:ActClassRoot, root= "ACT"} |
Design Comments: The classCode for PlacerOrder is fixed to "ACT". |
||||||||
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodRequest, root= "RQO"} |
Design Comments: PlacerOrder is in Request mood. This has been fixed to "RQO" in the RMIM. |
||||||||
| id [1..*] (M) Act (DSET<II>) |
Design Comments: The PlacerOrder.id attribute is used to distinguish this placer order from all other placer orders. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id. Mapping: The placer order number in OBR-2 is the 2.x equivalent for this attribute for single orders or ORC 4 for order groups. |
||||||||
| Definition |
Design Comments: The definition act relationship is used to associate a ObservationReport, ObservationBattery, SpecimenObservationCluster or ObservationEvent with its ActDefinition (master file). The source act is an instance of the target definition act. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipInstantiatesMaster, root= "INST"} |
Design Comments: The typeCode for definition is constrained to "INST". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:C:ContextControl:AN, fixed value= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The fixed value of AN has been associated with this act relationship. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The fixed value of 'false" has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| actDefinition [1..1] (ActDefinition) |
Design Comments: The ActDefinition class represents the definition (master file) for the associated ObservationReport, ObservationBattery, SpecimenObservationCluster or ObservationEvent. Typically this definition is drawn from the local service catalog. |
||||||||
| ActDefinition |
Design Comments: The ActDefinition class represents the definition (master file) for the associated ObservationReport, ObservationBattery, SpecimenObservationCluster or ObservationEvent. Typically this definition is drawn from the local service catalog. |
||||||||
| classCode [1..1] (M) Act (CS) {CNE:V:ActClassRoot, root= "ACT"} |
Design Comments: The classCode for ObservationEvent is constrained to "ACT". |
||||||||
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodDefinition, root= "DEF"} |
Design Comments: ActDefinition is in Definition mood. This has been fixed to "DEF" in the RMIM. |
||||||||
| id [1..1] (M) Act (II) |
Design Comments: The ActDefinition.id attribute is used to distinguish this definition from any other definition. Mapping: The closest 2.x analogs for this attribute is Universal Servce ID OBR 4 or Observation Identifier OBX 3 which are communicated as codes but in V3 will be communicated via id with the II data type. |
||||||||
| text [0..1] Act (ED) |
Design Comments: A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. Please see the RIM Act.text description for further clarification of the use of this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| Reason |
Design Comments: Each ObservationEventChoice may have zero to many reasons associated with it. The SupportingClinicalInformation CMET is used to carry this information. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipReason, root= "RSON"} |
Design Comments: The typeCode for reason is constrained to "RSON". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "true"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'true" has been associated with this attribute. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| priorityNumber [0..1] ActRelationship (INT) |
Design Comments: An integer specifying the relative preference for considering this reason before other reasons having the same source Act. Reasons with lower priorityNumber values are considered before and above those with higher values. |
||||||||
| clinicalStatement [1..1] (A_SupportingClinicalStatementUniversal) | |||||||||
| PertinentInformation |
Design Comments: An ObservationEventChoice is associated with zero to many items of supporting clinical information that are pertinent to the event. The information is carried in the SupportingClinicalStatement CMET. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipPertains, root= "PERT"} |
Design Comments: The typeCode pertinentinformation is constrained to "PERT". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "true"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| clinicalStatement [1..1] (A_SupportingClinicalStatementUniversal) | |||||||||
| Component2 |
Design Comments: For each message instance, one of the acts within the ObservationEventChoice shall be selected as the 'Focal act' for the result. If there is a requirement for observations to be grouped together, this may be achieved using the Component Act Relationship recursion. For example, the ObservationReport act may serve as the focal act, with multiple component items carried in the ObservationBattery, SpecimenObservationCluster or ObservationEvent acts. The recursion carries a number of constraints: The ObservationReport may have ObservationReports, ObservationBattery's, SpecimenObservationClusters, and ObservationEvents as components. This allows for repeating report headers within a result. The ObservationBattery may have ObservationEvents as components. The SpecimenObservationCluster may have ObservationBattery's and ObservationEvents as components. The ObservationEvent may have ObservationEvents as components. Mapping: There are several 2.x equivalent structures for this association. The first is the relationship between the OBR segment and its associated OBX's. The second equivalent is OBR 29 Parent field which creates a relationship between child OBR and its parent OBR. In 2.x this parent child linking of OBR's is handled via references to the parent OBR identifiers. In V3, the parent/child relationships are handled structurally in the messages, meaning no identifiers are needed to create the association. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasComponent, root= "COMP"} |
Design Comments: The typeCode for component2 is constrained to "COMP". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN (additiive non-propagating) has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "true"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'true' has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. Mapping: The 2.x equivalent is OBR 1 and OBX 1 Set ID. |
||||||||
| priorityNumber [0..1] ActRelationship (INT) |
Design Comments: An integer specifying the relative preference for considering this relationship before other like-typed relationships having the same source Act. Relationships with lower priorityNumber values are considered before and above those with higher values. Mapping: There is no 2.x equivalent. |
||||||||
| seperatableInd [0..1] ActRelationship (BL){default= "false"} |
Design Comments: This attribute indicates whether or not the source Act is intended to be interpreted independently of the target Act. The indicator cannot prevent an individual or application from separating the Acts, but indicates the author's desire and willingness to attest to the content of the source Act if separated from the target Act. Also note that this attribute is orthogonal and unrelated to the RIM's context/inheritance mechanism. If the context of an Act is propagated to nested Acts, it is assumed that those nested Acts are not intended to be interpreted without the propagated context. The default value for this attribute has been set to 'false'. Mapping: There is no 2.x equivalent. |
||||||||
| observationEventChoice [1..1] (ObservationEventChoice) | |||||||||
| Component3 |
Design Comments: Each ObservationEventChoice act may have one or more component ProcessSteps. Where the ProcessStep is a specimen collection, information about the collector may be carried in the Collector role linked through the participation. ProcessSteps cover activities such as accessioning, collection, transportation, and result processing. Virtually any workflow step in the laboratory can be communicated here. The statusCode attribute has been provided to allow the filler to indicate the state of a process step (including completion). The performer participation from the ProcessStep act is used where the ProcessStep.ActClass is SPECCOLLECT. The Collector role has a class code from x_CollectorClassCodes and a Role.code from CollectorRoleType. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasComponent, root= "COMP"} |
Design Comments: The typeCode is constrained to "COMP". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "true"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'true" has been associated with this attribute. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| processStep [1..1] (ProcessStep) |
Design Comments: A Process Step is performed on a specimen and its container or holder. Typical process steps are Specimen Collection, Specimen Accession, Specimen Separation etc. The Process Step in EVN mood is intended to identify that the step has taken place but not record any value or the outcome. For instance, when Cold Agglutinins are discovered in the specimen during the processing of a CBC test the specimen is placed in a 37 degree wash for two hours. This observation would record that this had been performed. |
||||||||
| ProcessStep |
Design Comments: A Process Step is performed on a specimen and its container or holder. Typical process steps are Specimen Collection, Specimen Accession, Specimen Separation etc. The Process Step in EVN mood is intended to identify that the step has taken place but not record any value or the outcome. For instance, when Cold Agglutinins are discovered in the specimen during the processing of a CBC test the specimen is placed in a 37 degree wash for two hours. This observation would record that this had been performed. |
||||||||
| classCode [1..1] (M) Act (CS) {CNE:V:x_LabProcessClassCodes} |
Design Comments: A specific process step from the vocabulary. |
||||||||
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
Design Comments: The act is an event that has occurred |
||||||||
| id [0..*] Act (DSET<II>) |
Design Comments: This attribute is used to distinguish this Process Step from any other Process Step. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id. |
||||||||
| code [1..1] (M) Act (CD) {CWE:D:x_LabProcessCodes} |
Design Comments: The Code for the means by which the act is carried out. For Specimen collection, this is generally the collection method such as 'Biopsy', 'Fine needle aspiration' etc |
||||||||
| text [0..1] Act (ST) |
Design Comments: The free text describing the process step. |
||||||||
| statusCode [1..1] (M) Act (CS) {CNE:V:ActStatus} |
Design Comments: The status of the process such as aborted or completed |
||||||||
| effectiveTime [0..1] Act (IVL<TS>) |
Design Comments: The time the process is effective. For collection process, this is the collection time which is the clinically significant time for tests carried out on that specimen. |
||||||||
| Subject1 |
Design Comments: The result act may be the subject of zero to many ControlActEvents. These Control Acts communicate the trigger event and other "action" information regarding the associated act. This structure is useful for historical query responses and result communications. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasSubject, root= "SUBJ"} |
Design Comments: The typeCode for subjectOf1 is constrained to "SUBJ". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of ON has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'false' has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| controlActEvent [1..1] (ControlActEvent) |
Design Comments: These Control Acts communicate the trigger event and other "action" information regarding the associated act. This structure is useful for historical query responses and result communications. Note that the ControlActEvent does not apply to the focal act for the message. It applies to acts nested under the focal act. The control act wrapper for the message applies to the focal act. Mapping: There is no direct 2.x equivalent for the ControlActEvent. The closest equivalent is the OBR.25 Result Status and the OBX.11 Observation Status fields. |
||||||||
| ControlActEvent |
Design Comments: These Control Acts communicate the trigger event and other "action" information regarding the associated act. This structure is useful for historical query responses and result communications. Note that the ControlActEvent does not apply to the focal act for the message. It applies to acts nested under the focal act. The control act wrapper for the message applies to the focal act. Mapping: There is no direct 2.x equivalent for the ControlActEvent. The closest equivalent is the OBR.25 Result Status and the OBX.11 Observation Status fields. |
||||||||
| classCode [1..1] (M) ControlAct (CS) {CNE:V:ActClassControlAct, root= "CACT"} |
Design Comments: The classCode is constrained to "CACT". |
||||||||
| moodCode [1..1] (M) ControlAct (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
Design Comments: Control Act is in Event mood. This has been fixed to "EVN" in the RMIM. |
||||||||
| id [0..*] ControlAct (DSET<II>) |
Design Comments: The identifier that has been designated for the control act or notification. Mapping: There is no 2.x equivalent. |
||||||||
| code [1..1] (M) ControlAct (CD) {CWE:D:HL7TriggerEventCode} |
Design Comments: The code indicates the Trigger Event of the act or the notification that has been sent. The domain HL7TriggerEventCode has been defined to represent these codes. Mapping: The closest 2.x equivalent is the OBR.25 Result Status and OBX.11 Observation Status, but that is not a complete equivalance. For instance there is no V3 trigger event for I - No results available; specimen received, procedure incomplete. This result status is handled as a LaboratoryProcessStep. On the other hand, using the ControlActProcess is the only V3 mechanism we have to communicate that the result has been corrected. |
||||||||
| text [0..1] ControlAct (ED) |
Design Comments: A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. Please see the RIM Act.text description for further clarification of the use of this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| effectiveTime [0..1] ControlAct (IVL<TS>) |
Design Comments: The date and time on which the control act or notification was composed and authorized for transmission, i.e. the date and time the event occurred that triggered the interaction. This date and time will normally differ from the data and time contained in the transmission wrapper. Note that although the OBX does have a timestamp for date and time of the analysis, this is not a timestamp for the trigger event, it is a timestamp for the observation activity. Mapping: The 2.x equivalent for this is the OBR.22 Results Rpt/Status Chng - Date/Time. |
||||||||
| priorityCode [0..*] ControlAct (DSET<CD>) {CWE:D:ActPriority} |
Design Comments: A code, or a set of codes, that identifies the circumstances in which the event happened, shall happen, is planned to happen, or requested to happen. The default value is R for routine. Mapping: There is no 2.x equivalent. |
||||||||
| reasonCode [0..*] ControlAct (DSET<CD>) {CWE:D:ActReason} |
Design Comments: A code specifying the motivation, cause, or rationale of the Act. The reasonCode should only be used for common reasons that are not related to a prior Act or any other condition expressed in Acts. Example reasons that might qualify for being coded in this field might be: "routine requirement", "infectious disease reporting requirement", "on patient request", or "required by law". The reasonCode attribute identifies types of reasons, or broad categories of reasons. It is not to be used for the identification of fine-grained reasons for the Act. Mapping: There is no 2.x equivalent. |
||||||||
| languageCode [0..1] ControlAct (CD) {CWE:D:HumanLanguage} |
Design Comments: The primary language in which this Act statement is specified, particularly the language of the text attribute. Mapping: There is no 2.x equivalent. |
||||||||
| overseer [0..*] (Overseer) |
Design Comments: One who oversees a control act event. Includes either a type of accountability, as in responsible party, verifier (and its children) and witness; or being an assistant to the control act event, as in secondary performer. |
||||||||
| authorOrPerformer [0..*] (AuthorOrPerformer) |
Design Comments: There are zero to many parties recorded as author or performer for a control act. The author of an act is the person who takes responsibility for its creation. This could be the doctor who orders a test or the public health professional who decides to notify a local, state, or national public health entity. The performer of an act is the person who actually and principally carries out the "controlled act". The performer is rarely used. The actual party involved is either a device or a person, and the particular information involved is specified in the Assigned Person, and the Assigned Device CMET. The reader should note that, in many cases, it is the organization responsible for authoring or performing an act that is recorded as opposed to the person. In this case, the Assigned Person CMET is still used. However, the organization that scopes the performer role is recorded. Mapping: There is no 2.x equivalent of the AuthorOrPerformer participation for the ControlActEvent. The 2.x result messages document author or performer of the results and observations, but not the author or performer of the trigger events associated with the result message. |
||||||||
| dataEnterer [0..*] (DataEnterer2) |
Design Comments: Identifies the person/device entering the data, details of which are carried in the R_AssignedPerson CMET. |
||||||||
| informationRecipient [0..*] (InformationRecipient2) |
Design Comments: The intended recipient(s) of the observations. This is used to identify copy recipients of results. These may be individuals, organizations or devices and are carried in the AssignedEntity CMET. |
||||||||
| Overseer |
Design Comments: One who oversees a control act event. Includes either a type of accountability, as in responsible party, verifier (and its children) and witness; or being an assistant to the control act event, as in secondary performer. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:x_ParticipationVrfRespSprfWit} |
Design Comments: The typeCode for Overseer participation is constrained to "x_ParticipationVrfRespSprfWit" value set. |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. |
||||||||
| noteText [0..1] Participation (ED) |
Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only. |
||||||||
| time [0..1] Participation (IVL<TS>) |
Design Comments: An interval of time specifying the time during which the participant is involved in the act through this Participation. |
||||||||
| modeCode [0..1] Participation (CD) {CWE:D:ParticipationMode} |
Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act. |
||||||||
| signatureCode [0..1] Participation (CD) {CNE:D:ParticipationSignature} |
Design Comments: a code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed. |
||||||||
| signatureText [0..1] Participation (ED) |
Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability. |
||||||||
| assignedPerson [1..1] (R_AssignedPersonUniversal) | |||||||||
| AuthorOrPerformer |
Design Comments: There are zero to many parties recorded as author or performer for a control act. The author of an act is the person who takes responsibility for its creation. This could be the doctor who orders a test or the public health professional who decides to notify a local, state, or national public health entity. The performer of an act is the person who actually and principally carries out the "controlled act". The performer is rarely used. The actual party involved is either a device or a person, and the particular information involved is specified in the Assigned Person, and the Assigned Device CMET. The reader should note that, in many cases, it is the organization responsible for authoring or performing an act that is recorded as opposed to the person. In this case, the Assigned Person CMET is still used. However, the organization that scopes the performer role is recorded. Mapping: There is no 2.x equivalent of the AuthorOrPerformer participation for the ControlActEvent. The 2.x result messages document author or performer of the results and observations, but not the author or performer of the trigger events associated with the result message. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:x_ParticipationAuthorPerformer} |
Design Comments: The typeCode for AuthorOrPerformer participation is constrained to "x_ParticipationAuthorPerformer" value set. |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. |
||||||||
| noteText [0..1] Participation (ED) |
Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only. |
||||||||
| time [0..1] Participation (IVL<TS>) |
Design Comments: An interval of time specifying the time during which the participant is involved in the act through this Participation. |
||||||||
| modeCode [0..1] Participation (CD) {CWE:D:ParticipationMode} |
Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act. |
||||||||
| signatureCode [0..1] Participation (CD) {CNE:D:ParticipationSignature} |
Design Comments: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed. |
||||||||
| signatureText [0..1] Participation (ED) |
Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability. |
||||||||
| participationChoice [1..1] (ParticipationChoice) | |||||||||
| ParticipationChoice | |||||||||
| choice of R_AssignedPersonUniversal | |||||||||
| or R_AssignedDeviceUniversal | |||||||||
| DataEnterer2 |
Design Comments: Identifies the person/device entering the data, details of which are carried in the R_AssignedPerson CMET. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationDataEntryPerson, root= "ENT"} |
Design Comments: DataEnterer typeCode is in "ENT" mood. This has been fixed to "ENT" in the RMIM. |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. |
||||||||
| time [0..1] Participation (IVL<TS>) |
Design Comments: An interval of time specifying the time during which the dataEnterer is involved in the act through this Participation. |
||||||||
| assignedPerson [1..1] (R_AssignedPersonUniversal) | |||||||||
| InformationRecipient2 |
Design Comments: The intended recipient(s) of the observations. This is used to identify copy recipients of results. These may be individuals, organizations or devices and are carried in the AssignedEntity CMET. |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationInformationRecipient, root= "IRCP"} |
Design Comments: The typeCode is constrained to "IRCP". |
||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this participation. |
||||||||
| time [0..1] Participation (IVL<TS>) |
Design Comments: An interval of time specifying the time during which the information recipient is involved in the Observation through this Participation. |
||||||||
| assignedPerson [1..1] (R_AssignedPersonUniversal) | |||||||||
| Subject2 |
Design Comments: The result act my be the subject of zero to many Annotations. Annotations include any sort result comments, special instructions, etc. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasSubject, root= "SUBJ"} |
Design Comments: The typeCode for componentOf is constrained to "SUBJ". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'false' has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. Mapping: The 2.x equivalent is NTE 1-Set ID. |
||||||||
| seperatableInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: This attribute indicates whether or not the source Act is intended to be interpreted independently of the target Act. The indicator cannot prevent an individual or application from separating the Acts, but indicates the author's desire and willingness to attest to the content of the source Act if separated from the target Act. Also note that this attribute is orthogonal and unrelated to the RIM's context/inheritance mechanism. If the context of an Act is propagated to nested Acts, it is assumed that those nested Acts are not intended to be interpreted without the propagated context. The default value for this attribute has been set to 'false'. Mapping: There is no 2.x equivalent. |
||||||||
| annotation [1..1] (A_AnnotationUniversal) | |||||||||
| Component1 |
Design Comments: Provides a link between the result and the Encounter by means of the encounter CMET. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasComponent, root= "COMP"} |
Design Comments: The typeCode for componentOf is constrained to "COMP". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "OP"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of OP has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'false' has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| encounter [1..1] (A_EncounterUniversal) | |||||||||
| ObservationReport |
Design Comments: The ObservationReport act serves as an optional header for a group of related reports, batteries, clusters or observations. Its target may be another ObservationReport, ObservationBattery, SpecimenObservationCluster, or an ObservationEvent. Specimen centric ObservationReports will associate the specimen at the ObservationReport level, allowing this specimen to be inherited by component acts. In the case of specimen centric reports, component acts may have additional specimens associated with them, but they should be aliquots or isolates of the specimen associated with the ObservationReport. Non-Specimen centric ObservationReports normally will not have specimens related at this level. Specimens associated with component acts may have specimens associated with them, but those specimens are not necessarily related. |
||||||||
| classCode [1..1] (M) Act (CS) {CNE:V:ActClassGrouper, root= "GROUPER"} |
Design Comments: The classCode for ObservationReport is constrained to "GROUPER". A grouper represents the information acquired for an observation. |
||||||||
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
Design Comments: ObservationReport is in Event mood. This has been fixed to "EVN" in the RMIM. |
||||||||
| id [0..*] Act (DSET<II>) |
Design Comments: The ObservationReport.id attribute is used to distinguish this report from all other reports. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id. Mapping: This attribute has no 2.x analog, as there is no concept of a report identifier in 2.x. |
||||||||
| code [1..1] Act (CD) {CWE:D:ActCode} |
Design Comments: The ObservationReport.code attribute is used to categorize the type of report associated with this class. The analog in 2.x is OBR 4 Universal Service ID. This will be a code that describes the type of report. |
||||||||
| title [0..1] Act (ST) |
|||||||||
| text [0..1] Act (ED) |
Design Comments: A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. Please see the RIM Act.text description for further clarification of the use of this attribute. |
||||||||
| statusCode [1..1] (M) Act (CS) {CNE:V:ActStatus, default= "completed"} |
Design Comments: The ObservationReport.statusCode attribute is used to report the status of the ObservationReport object. The allowed statuses for the ObservationReport are associated with the Lab dynamic model for result reporting. Only the states allowed by the Lab dynamic model can be communicated in this attribute. At this time, the allowed statuses are: active, aborted, completed, nullified and suspended. Please see the Result Topic Trigger Event discussion for further discussion regarding the allowed states of Laboratory Results. |
||||||||
| priorityCode [0..*] Act (DSET<CD>) {CWE:D:ActPriority} |
Design Comments: The ObservationReport.priorityCode attribute is used to communicate the urgency associated with this report. It is not the priority associated with the performance of the testing being reported, rather it is the performer’s assessment of the urgency with which the receiver should pay attention to the report. Mapping: There is no 2.x equivalent of this attribute. |
||||||||
| confidentialityCode [0..*] Act (DSET<CD>) {CWE:D:Confidentiality} |
Design Comments: The ObservationReport.confidentialityCode attribute is used to communicate the confidentiality associated with this report. A set of values that control the disclosure of information about this report. |
||||||||
| reasonCode [0..*] Act (DSET<CD>) {CWE:D:ActReason} |
Design Comments: The ObservationReport.reason attribute is a code specifying the motivation, cause, or rationale of the Observation report when such rationale is not reasonably representable as an ActRelationship of type "reason" linking to A_SupportingClinicalStatement universal act. This reason applies to the entire observation report rather than to one or more sub-components of the report. |
||||||||
| Inherits associations from ObservationEventChoice | |||||||||
| ObservationBattery |
Design Comments: The ObservationBattery represents a set of observations. These observations typically have a logical or practical grouping for generally accepted clinical or functional purposes, such as observations that are run together because of automation. A battery can define required and optional components and, in some cases, will define complex rules that determine whether or not a particular observation is made. Examples include "Full blood count", "Chemistry panel". The ObservationBattery may have ObservationEvents as components. It shall not have ObservationReports or SpecimenObservationClusters as components. An ObservationBattery may inherit the specimen from an ObservationReport (if one is present). The ObservationBattery may also be the initial act in a Result Event message. In that case any specimen associated with the battery would be inherited by the component acts of the battery. |
||||||||
| classCode [1..1] (M) Observation (CS) {CNE:V:ActClassBattery, root= "BATTERY"} |
Design Comments: The classCode for ObservationBattery is constrained to "BATTERY". |
||||||||
| moodCode [1..1] (M) Observation (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
Design Comments: ObservationBattery is in Event mood. This has been fixed to "EVN" in the RMIM. |
||||||||
| id [0..*] Observation (DSET<II>) |
Design Comments: The ObservationBattery.id attribute is used to distinguish this battery (include a document link to Laboratory glossary definition of battery) of observations from any other grouping of observations or single observation. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id. Mapping: There is no 2.x analog for this id. |
||||||||
| code [1..1] Observation (CD) {CWE:D:ActCode} |
Design Comments: The ObservationBattery.code attribute is used to categorize the type of observation battery (same link to battery glossary) associated with this class. This will be a code that describes the type of battery. Mapping: The analog in 2.x is OBR 4 Universal Service ID and its components. |
||||||||
| text [0..1] Observation (ED) |
Design Comments: A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. Please see the RIM Act.text description for further clarification of the use of this attribute. |
||||||||
| statusCode [1..1] (M) Observation (CS) {CNE:V:ActStatus, default= "completed"} |
Design Comments: The ObservationBattery.statusCode attribute is used to report the status of the ObservationBattery object. The allowed statuses for the ObservationBattery are associated with the Lab dynamic model for result reporting. Only the states allowed by the Lab dynamic model can be communicated in this attribute. At this time, the allowed statuses are: active, aborted, completed, nullified and suspended. Please see the Result Topic Trigger Event discussion for further discussion regarding the allowed states of Laboratory Results. |
||||||||
| priorityCode [0..*] Observation (DSET<CD>) {CWE:D:ActPriority} |
Design Comments: The ObservationBattery.priorityCode attribute is used to communicate the urgency associated with this battery. It is not the priority associated with the performance of the testing being reported on the battery, rather it is the performer’s assessment of the urgency with which the receiver should pay attention to the battery group within a report. Mapping: There is no 2.x equivalent of this attribute. |
||||||||
| confidentialityCode [0..*] Observation (DSET<CD>) {CWE:D:Confidentiality} |
Design Comments: The ObservationBattery.confidentialityCode attribute is used to communicate the confidentiality associated with this battery. A set of values that control the disclosure of information about this battery. If the battery is a component of an ObservationReport, the confidentiality of the battery overrides the confidentiality associated with the ObservationReport. |
||||||||
| reasonCode [0..*] Observation (DSET<CD>) {CWE:D:ActReason} |
Design Comments: The ObservationBattery.reason attribute is a code specifying the motivation, cause, or rationale of the Observation battery when such rationale is not reasonably representable as an ActRelationship of type "reason" linking to A_SupportingClinicalStatement universal act. This reason applies to the entire observation battery rather than to one or more sub-components of the battery. Mapping: There is no 2.x equivalent for this attribute. |
||||||||
| device [0..*] (Device) |
Design Comments: Something used in delivering the service without being substantially affected by the service (i.e. durable or inert with respect to that particular service.) Examples are: monitoring equipment, tools, but also access/drainage lines, prostheses, pace maker, etc. UsageNotes: Device participation to R_LabTestKit |
||||||||
| consumable1 [0..*] (Consumable2) |
Design Comments: Reagent Target that is taken up, is diminished, and disappears in the service. UsageNotes: consumable participation to R_Reagent |
||||||||
| consumable2 [0..*] (Consumable) |
Design Comments: Lab test kit Target that is taken up, is diminished, and disappears in the service. UsageNotes: Consumable participation to R_LabTestKit |
||||||||
| Inherits associations from ObservationEventChoice | |||||||||
| Device |
Design Comments: Something used in delivering the service without being substantially affected by the service (i.e. durable or inert with respect to that particular service.) Examples are: monitoring equipment, tools, but also access/drainage lines, prostheses, pace maker, etc. UsageNotes: Device participation to R_LabTestKit |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationTargetDevice, root= "DEV"} |
|||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of ON has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| time [0..1] Participation (IVL<TS>) |
Design Comments: An interval of time specifying the time during which the device is involved in the ObservationEvent through this Participation. |
||||||||
| labTestKit [1..1] (R_LabTestKitUniversal) | |||||||||
| Consumable2 |
Design Comments: Reagent Target that is taken up, is diminished, and disappears in the service. UsageNotes: consumable participation to R_Reagent |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationConsumable, root= "CSM"} |
|||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of ON has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| reagent [1..1] (R_ReagentUniversal) | |||||||||
| Consumable |
Design Comments: Lab test kit Target that is taken up, is diminished, and disappears in the service. UsageNotes: Consumable participation to R_LabTestKit |
||||||||
| typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationConsumable, root= "CSM"} |
|||||||||
| contextControlCode [1..1] (M) Participation (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of ON has been associated with this participation. |
||||||||
| sequenceNumber [0..1] Participation (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. |
||||||||
| labTestKit [1..1] (R_LabTestKitUniversal) | |||||||||
| SpecimenObservationCluster |
Design Comments: The SpecimenObservationCluster represents a set of batteries and observations. All the batteries and observations are related to the specimen associated with the SpecimenObservationCluster. For microbiology the SpecimenObservationCluster represents all the batteries and observations related to a single isolate. The subject of a SpecimenObservationCluster must be either a specimen isolate or a specimen aliquot. The target of a SpecimenObservationCluster must be either an ObservationBattery or an ObservationEvent. An SpecimenObservationCluster may inherit the specimen from an ObservationReport (if one is present). Normally, the SpecimenObservationCluster will identify its own specimen, but that specimen must be an isolate or aliquot of the specimen inherited from the ObservationReport. The SpecimenObservationCluster may also be the initial act in a Result Event message. In that case any specimen associated with the cluster would be inherited by the component acts of the cluster. |
||||||||
| classCode [1..1] (M) Act (CS) {CNE:V:ActClassCluster, root= "CLUSTER"} |
Design Comments: The classCode for SpecimenObservationCluster is constrained to "CLUSTER". |
||||||||
| moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
Design Comments: SpecimenObservationCluster is in Event mood. This has been fixed to "EVN" in the RMIM. |
||||||||
| id [0..*] Act (DSET<II>) |
Design Comments: The SpecimenObservationCluster.id attribute is used to distinguish this cluster of observations from any other grouping of observations or single observation. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id. Mapping: There is no 2.x analog for this id. |
||||||||
| code [0..1] Act (CD) {CWE:D:ActCode} |
Design Comments: The SpecimenObservationCluster.code attribute is used to categorize the type of observation grouping associated with this class. This will be a code that describes the type of cluster. Mapping: The analog in 2.x is OBR 4 Universal Service ID and its components. |
||||||||
| text [0..1] Act (ED) |
Design Comments: A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. Please see the RIM Act.text description for further clarification of the use of this attribute. Mapping: There is no 2.x equivalent since NTE comments will be represented by the annotation act relationship. |
||||||||
| statusCode [1..1] (M) Act (CS) {CNE:V:ActStatus, default= "completed"} |
Design Comments: The SpecimenObservationCluster.statusCode attribute is used to report the status of the SpecimenObservationCluster object. The allowed statuses are associated with the Lab dynamic model for result reporting. Only the states allowed by the Lab dynamic model can be communicated in this attribute. At this time, the allowed statuses are: active, aborted, completed, nullified and suspended. Please see the Result Topic Trigger Event discussion for further discussion regarding the allowed states of Laboratory Results. |
||||||||
| priorityCode [0..*] Act (DSET<CD>) {CWE:D:ActPriority} |
Design Comments: The SpecimenObservationCluster.priorityCode attribute is used to communicate the urgency associated with this specimen cluster. It is not the priority associated with the performance of the testing being reported on the cluster, rather it is the performer’s assessment of the urgency with which the receiver should pay attention to the cluster group within a report. Mapping: There is no 2.x equivalent of this attribute. |
||||||||
| confidentialityCode [0..*] Act (DSET<CD>) {CWE:D:Confidentiality} |
Design Comments: The SpecimenObservationCluster.confidentialityCode attribute is used to communicate the confidentiality associated with this SpecimenObservationCluster. A set of values that control the disclosure of information about this cluster grouping within a report. |
||||||||
| reasonCode [0..*] Act (DSET<CD>) {CWE:D:ActReason} |
Design Comments: The SpecimenObservationCluster.reason attribute is a code specifying the motivation, cause, or rationale of the Observation cluster when such rationale is not reasonably representable as an ActRelationship of type "reason" linking to A_SupportingClinicalStatement universal act. This reason applies to the entire SpecimenObservationCluster rather than to one or more sub-components of the cluster. Mapping: There is no 2.x equivalent for this attribute. |
||||||||
| Inherits associations from ObservationEventChoice | |||||||||
| ObservationEvent |
Design Comments: The ObservationEvent represents a related group of observations. Observations are actions performed in order to determine an answer or result value. Observation result values (Observation.value) include specific information about the observed object. The ObservationEvent is distinguished from the other 3 choices within ObservationEventChoice in that it is the choice which can carry a value (i.e., an actual result). The target of an ObservationEvent may be another ObservationEvent. ObservationReport, ObservationBattery, and SpecimenObservationCluster may not be targets of an ObservationEvent. The ObservationEvent may be the component of an ObservationReport, ObservationBattery, SpecimenObservationCluster, or ObservationEvent. In this case the ObservationEvent can inherit any specimens associated with the parent act. If the parent has a specimen associated with it, and ObservationEvent also has a specimen, the specimen associated with the ObservationEvent must be an isolate or aliquot of the parent acts specimen. The ObservationEvent may also be the initial act in a Result Event message. In that case any specimen associated with the ObservationEvent would be inherited by the component acts of the cluster. It should be noted that there is an entire school of result messaging which will only utilize the ObservationEvent choice within the ObservationEventChoice. ObservationEvent can essentially replace each of the ObservationReport, ObservationBattery, and SpecimenObservationCluster. UsageNotes: The ObservationEvent effective time should only be used when an ObservationEvent is not associated with a specimen. When an ObservationEvent is associated with a specimen, the effective time of the ObservationEvent is the collection time of that specimen. |
||||||||
| classCode [1..1] (M) Observation (CS) {CNE:V:ActClassObservation, root= "OBS"} |
Design Comments: The classCode for ObservationEvent is constrained to "OBS". |
||||||||
| moodCode [1..1] (M) Observation (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
Design Comments: ObservationEvent is in Event mood. This has been fixed to "EVN" in the RMIM. |
||||||||
| id [0..*] Observation (DSET<II>) |
Design Comments: The ObservationEvent.id attribute is used to distinguish this observation from any other grouping of observations or single observation. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id. Mapping: The 2.x analog for this attribute Observation Instance Identifier (OBX.21). |
||||||||
| code [1..1] Observation (CD) {CWE:D:ObservationType} |
Design Comments: The ObservationEvent.code attribute is used to categorize the type of observation associated with this class. This will be a code that describes the type of observation. Mapping: The analog in 2.x includes both OBR.4 Universal Service Identifier and OBX 3 Observation identifier and its components. |
||||||||
| derivationExpr [0..1] Observation (ST.SIMPLE) |
Design Comments: The ObservationEvent.derivationExpr attribute is used to communicate the algorithmic expression used to calculate the observation. |
||||||||
| text [0..1] Observation (ED) |
Design Comments: A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. Please see the RIM Act.text description for further clarification of the use of this attribute. |
||||||||
| statusCode [1..1] (M) Observation (CS) {CNE:V:ActStatus, default= "completed"} |
Design Comments: The ObservationEvent.statusCode attribute is used to report the status of the ObservationEvent object. The allowed statuses for the ObservationEvent are associated with the Lab dynamic model for result reporting. Only the states allowed by the Lab dynamic model can be communicated in this attribute. At this time, the allowed statuses are: active, aborted, completed, nullified and suspended. Please see the Result Topic Trigger Event discussion for further discussion regarding the allowed states of Laboratory Results. |
||||||||
| effectiveTime [0..1] Observation (QSET<TS>) |
Design Comments: The ObservationEvent effective time should only be used when an ObservationEvent is not associated with a specimen. When an ObservationEvent is associated with a specimen, the effective time of the ObservationEvent is the collection time of that specimen. |
||||||||
| priorityCode [0..*] Observation (DSET<CD>) {CWE:D:ActPriority} |
Design Comments: The ObservationEvent.priorityCode attribute is used to communicate the urgency associated with this observation. It is not the priority associated with the performance of the testing being reported, rather it is the performer’s assessment of the urgency with which the receiver should pay attention to the observation. Mapping: There is no 2.x equivalent of this attribute. |
||||||||
| confidentialityCode [0..*] Observation (DSET<CD>) {CWE:D:Confidentiality} |
Design Comments: The ObservationEvent.confidentialityCode attribute is used to communicate the confidentiality associated with this observation. A set of values that control the disclosure of information about this observation. |
||||||||
| reasonCode [0..*] Observation (DSET<CD>) {CWE:D:ActReason} |
Design Comments: The Observationevent.reason attribute is a code specifying the motivation, cause, or rationale of the observation when such rationale is not reasonably representable as an ActRelationship of type "reason" linking to A_SupportingClinicalStatement universal act. This reason applies to the entire ObservationEvent rather than to one or more sub-components. Mapping: There is no 2.x equivalent for this attribute. |
||||||||
| value [0..1] Observation (ANY) {CWE:D:ObservationValue} |
Design Comments: Note that the units of measure if applicable would be carried as part of the PQ (Physical Quantity data type). Information that is assigned or determined by the observation action. Observation.value is normally present for Observations in Event mood (i.e., the value of the test being reported). The Observation.value can be of ANY data type. The ANY data type is an abstract data type that is the parent of all concrete data types. The appropriate data type of the Observation.value varies with the kind of Observation and can generally be described in Observation definitions or in a simple relation that pairs Act.codes to value data types. The following guidelines govern the choice of the appropriate value data type: 1. Quantitative measurements use the data type Physical Quantity (PQ) in general. A PQ is essentially a real number with a unit. This is the general preference for all numeric values, subject to a few exceptions listed below. Numeric values must not be communicated as simply a character string (ST). 2. Titer (e.g., 1:64) and very few other ratios use the data type Ratio (RTO). For titers, the ratio would be a ratio of two integer numbers (e.g., 1:128). Other ratios may relate different quantitative data types, such as a "price" specified in Physical Quantity over Monetary Amount. Sometimes by local conventions titers are reported as just the denominator (e.g., 32 instead of 1/32). Such conventions are confusing and should be converted into correct ratios in HL7 messages. 3. Index values (a number without unit) uses the Real Number (REAL) data type. When a quantity does not have a proper unit, one can just send the number as a real number. Alternatively one can use a PQ with a dimensionless unit (e.g., 1 or %). An integer number should only be sent when the measurement is by definition an integer, which is an extremely rare case and then is most likely an ordinal (see below). 4. Ranges (e.g., <3; 12-20) must be expressed as Interval of Physical Quantity (IVL<PQ>) or intervals of other quantity data types. Sometimes such intervals are used to report the uncertainty of measurement value. For uncertainty there are dedicated data type extensions available. 5. Ordinals (e.g., +, ++, +++; or I, IIa, IIb, III, IV) use the Coded Ordinal (CO) data type. 6. Nominal results ("taxons", e.g., organism type). use any of the coded data types (CD, CE) that specify at least a code and a coding system, and optionally original text, translations to other coding systems and sometimes qualifiers. 7. The character string data type may exceptionally be used to convey formalized expressions that do not fit in any of the existing data types. However, the string data type must not be used if the meaning can be represented by one of the existing data types. 8. Timestamps should not be sent in Observations if there are more appropriate places to send those, e.g., usually as Act.effectiveTime of some act. (E.g., "specimen received in lab" is in the effectiveTime of an Act describing the specimen transport to the lab, not in an Observation. 9. Sets of values of any data type, enumerated sets as well as intervals, are often used for Observation criteria (event-criterion mood) to specify "normal ranges" or "decision ranges" (for alerts) etc. 10. For sequences of observations (repeated measurements of the same property during a relatively short time) a Sequence (LIST) data type is used. 11. Uncertainty of values is specified using the Probability and Probability Distribution data type extensions (UVP, PPD). If a statistical sample is reported with absolute frequencies of categories a Bag collection (BAG) can be used efficiently. Mapping: The 2.x equivalent is OBX 5 for value and OBX 6 for units of measure. |
||||||||
| interpretationCode [0..*] Observation (DSET<CD>) {CNE:D:ObservationInterpretation} |
Design Comments: One or more codes specifying a rough qualitative interpretation of the observation, such as "normal", "abnormal", "below normal", "change up", "resistant", "susceptible", etc. These interpretation codes are sometimes called "abnormal flags", however, the judgment of normalcy is just one of the common rough interpretations, and is often not relevant. For example, the susceptibility interpretations are not about "normalcy", and for any observation of a pathologic condition, it does not make sense to state the normalcy, since pathologic conditions are never considered "normal." Mapping: The 2.x equivalent is OBX 8. |
||||||||
| methodCode [0..*] Observation (DSET<CD>) {CWE:D:ObservationMethod} |
Design Comments: A code that provides additional detail about the means or technique used to ascertain the observation. In all observations the method is already partially specified by simply knowing the kind of observation (observation definition, Observation.code) and this implicit information about the method does not need to be specified in ObservationEvent.methodCode. For example, many LOINC codes are defined for specific methods as long as the method makes a practical difference in interpretation. Thus, using LOINC, the difference between susceptibility studies using the "minimal inhibitory concentration" (MIC) or the "agar diffusion method" (Kirby-Bauer) are specifically assigned different codes. The methodCode therefore is only an additional qualifier to specify what may not be known already from the ObservationEvent.code. Mapping: The 2.x equivalent is OBX 17 Method. |
||||||||
| device [0..*] (Device) | |||||||||
| consumable1 [0..*] (Consumable) | |||||||||
| consumable2 [0..*] (Consumable2) | |||||||||
| derivedFrom1 [0..*] (DerivedFrom1) |
Design Comments: The source ObservationEvent is derived from the target SupportingClinicalInformation. For example a calculated ObservationEvent such as Creatinine Clearance would be the source ObservationEvent for multiple target SupportingClinicalInformation of patient height and weight and other related ObservationEvents. |
||||||||
| derivedFrom2 [0..*] (DerivedFrom2) |
Design Comments: The source ObservationEvent is derived from one or more target ObservationEvent(s). For example a calculated ObservationEvent such as Anion Gap would be the source ObservationEvent for multiple target ObservationEvents of sodium, potassium, chloride and CO2. |
||||||||
| referenceRange [0..*] (ReferenceRange) |
Design Comments: The target act defines an interpretation range for the source act. Interpretation ranges are essentially descriptors of a class of result values or changes in result values assumed to be "normal", "abnormal", or "critical" etc. typically used for 'Reference Ranges' or 'Normal Population Ranges'. These are generally only used for Numerical results. Those can vary by sex, age, or any other criterion. Source and target are observations, the target is in criterion mood. Note that the source act is not ObservationEventChoice, rather it is ObservationEvent. |
||||||||
| Inherits associations from ObservationEventChoice | |||||||||
| DerivedFrom1 |
Design Comments: The source ObservationEvent is derived from the target SupportingClinicalInformation. For example a calculated ObservationEvent such as Creatinine Clearance would be the source ObservationEvent for multiple target SupportingClinicalInformation of patient height and weight and other related ObservationEvents. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipIsDerivedFrom, root= "DRIV"} |
Design Comments: The typeCode for derivedFrom1 is constrained to "DRIV". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "AN"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: An indicator specifying that the ActRelationship.typeCode should be interpreted as if the roles of the source and target Acts were reversed. The inversion indicator is used when the meaning of ActRelationship.typeCode must be reversed. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. Mapping: The 2.x equivalent is OBX-1 Set ID of the input SupportingClinicalInformation Observation. |
||||||||
| localVariableName [0..1] ActRelationship (ST.SIMPLE) |
Design Comments: The derivedFrom1.localVariableName attribute provides a variable name for the target observation value that is used in the source SupportingClinicalInformation's derivationExpression. |
||||||||
| clinicalStatement [1..1] (A_SupportingClinicalStatementUniversal) | |||||||||
| DerivedFrom2 |
Design Comments: The source ObservationEvent is derived from one or more target ObservationEvent(s). For example a calculated ObservationEvent such as Anion Gap would be the source ObservationEvent for multiple target ObservationEvents of sodium, potassium, chloride and CO2. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipIsDerivedFrom, root= "DRIV"} |
Design Comments: The typeCode for derivedFrom2 is constrained to "DRIV". |
||||||||
| inversionInd [1..1] ActRelationship (BL){default= "false"} |
Design Comments: An indicator specifying that the ActRelationship.typeCode should be interpreted as if the roles of the source and target Acts were reversed. The inversion indicator is used when the meaning of ActRelationship.typeCode must be reversed. The default is "false". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of AN has been associated with this act relationship. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "true"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'true" has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. Mapping: The 2.x equivalent is OBX-1 Set ID of the input Observation. |
||||||||
| localVariableName [0..1] ActRelationship (ST.SIMPLE) |
Design Comments: The derivedFrom.localVariableName attribute provides a variable name for the target observation value that is used in the source observation's derivationExpression. |
||||||||
| observationEvent [1..1] (ObservationEvent) | |||||||||
| ReferenceRange |
Design Comments: The target act defines an interpretation range for the source act. Interpretation ranges are essentially descriptors of a class of result values or changes in result values assumed to be "normal", "abnormal", or "critical" etc. typically used for 'Reference Ranges' or 'Normal Population Ranges'. These are generally only used for Numerical results. Those can vary by sex, age, or any other criterion. Source and target are observations, the target is in criterion mood. Note that the source act is not ObservationEventChoice, rather it is ObservationEvent. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasReferenceValues, root= "REFV"} |
Design Comments: The typeCode for ReferenceRange is constrained to "REFV". |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd). The default value of ON has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'false" has been associated with this attribute. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing purposes only. Mapping: There is no 2.x equivalent. |
||||||||
| interpretationRange [1..1] (InterpretationRange) |
Design Comments: Interpretation Ranges may be presented as a pair of values (Lo - Hi) of the same datatype as the observation to which they apply (carried as an IVL). In some instances there may only be a Lo or a Hi rather than a pair of values. Some systems supply ranges as a String. Interpretation range may also carry a Reference Change Value (RCV) either as a percentage or absolute value. UsageNotes: Reference Ranges are generally presented as a pair of values (Lo - Hi) of the same datatype as the observation to which they apply (carried as an IVL). In some instances there may only be a Lo or a Hi rather than a pair of values. Some systems supply ranges as a String. |
||||||||
| InterpretationRange |
Design Comments: Interpretation Ranges may be presented as a pair of values (Lo - Hi) of the same datatype as the observation to which they apply (carried as an IVL). In some instances there may only be a Lo or a Hi rather than a pair of values. Some systems supply ranges as a String. Interpretation range may also carry a Reference Change Value (RCV) either as a percentage or absolute value. UsageNotes: Reference Ranges are generally presented as a pair of values (Lo - Hi) of the same datatype as the observation to which they apply (carried as an IVL). In some instances there may only be a Lo or a Hi rather than a pair of values. Some systems supply ranges as a String. |
||||||||
| classCode [1..1] (M) Observation (CS) {CNE:V:ActClassObservation, root= "OBS"} |
Design Comments: The classCode for InterpretationRange is constrained to "OBS". |
||||||||
| moodCode [1..1] (M) Observation (CS) {CNE:V:ActMoodEventCriterion, root= "EVN.CRT"} |
Design Comments: InterpretationRange is in Event Criterion mood. This has been fixed to "EVN.CRT" in the RMIM. Mapping: There is no 2.x equivalent. |
||||||||
| value [0..1] Observation (ANY) {CWE:D:ObservationValue} |
Design Comments: Interpretation Ranges may be presented as a pair of values (Lo - Hi) of the same datatype as the observation to which they apply (carried as an IVL). In some instances there may only be a Lo or a Hi rather than a pair of values. Some systems supply ranges as a String. Interpretation range may also carry a Reference Change Value (RCV) either as a percentage or absolute value. Mapping: The 2.x equivalent is OBX 7. |
||||||||
| interpretationCode [1..1] (M) Observation (CD) {CNE:V:ObservationInterpretation} |
Design Comments: Describes the type of interpretation range, e.g. normal, high, etc. Mapping: HL7 2.x equivalent is OBX 8 using HL7 Table 0078 Abnormal Flags. |
||||||||
| precondition [0..*] (Precondition) |
Design Comments: Associates specific criteria with a particular reference range (not all reference ranges are "normal", some may be disease related i.e. diabetes). Reference range criteria can be sex-related, age-related, species-related, etc. |
||||||||
| Precondition |
Design Comments: Associates specific criteria with a particular reference range (not all reference ranges are "normal", some may be disease related i.e. diabetes). Reference range criteria can be sex-related, age-related, species-related, etc. |
||||||||
| typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasPre-condition, root= "PRCN"} |
Design Comments: For this act the precondition must be true to qualify the InterpretationRange. |
||||||||
| contextControlCode [1..1] (M) ActRelationship (CS) {CNE:V:ContextControl, default= "ON"} |
Design Comments: A code that specifies how this Precondition contributes to the context of the InterpretationRange, and whether it may be propagated to descendent ObservationEvent Criterion whose association allows such propagation. The default value of ON has been associated with this act relationship. Mapping: There is no 2.x equivalent. |
||||||||
| contextConductionInd [1..1] (M) ActRelationship (BL){default= "true"} |
Design Comments: If the indicator is true, associations in the InterpretationRange are conducted to the Criterion. Mapping: There is no 2.x equivalent. |
||||||||
| sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
Design Comments: This is used for sequencing multiple criteria for display purposes. Mapping: There is no 2.x equivalent. |
||||||||
| conjunctionCode [0..1] ActRelationship (CS) {CNE:V:RelationshipConjunction, default= "AND"} |
Design Comments: A code specifying the logical conjunction of precondition criteria for the InterpretationRange (e.g., and, or, exclusive-or). UsageNotes: All AND criteria must be true. If OR and AND criteria occur together, one criterion out of the OR-group must be true and all AND criteria must be true also. If XOR criteria occur together with OR and AND criteria, exactly one of the XOR criteria must be true, and at least one of the OR criteria and all AND criteria must be true. In other words, the sets of AND, OR, and XOR criteria are in turn combined by a logical AND operator (all AND criteria and at least one OR criterion and exactly one XOR criterion). To overcome this ordering, Act criteria can be nested in any way necessary. Mapping: There is no 2.x equivalent. |
||||||||
| criterion [1..1] (Criterion) |
Design Comments: Criterion allows for the identification of the parameters applied to the quoted interpretation range such as "sex", "age", "species", etc. UsageNotes: Criterion allows for the identification of the parameters applied to the quoted interpretation Range such as ‘Sex’, ‘Age’, ‘Species’, etc. |
||||||||
| Criterion |
Design Comments: Criterion allows for the identification of the parameters applied to the quoted interpretation range such as "sex", "age", "species", etc. UsageNotes: Criterion allows for the identification of the parameters applied to the quoted interpretation Range such as ‘Sex’, ‘Age’, ‘Species’, etc. |
||||||||
| classCode [1..1] (M) Observation (CS) {CNE:V:ActClassObservation, root= "OBS"} |
Design Comments: The classCode for Criterion is constrained to "OBS". Mapping: There is no 2.x equivalent |
||||||||
| moodCode [1..1] (M) Observation (CS) {CNE:V:ActMoodEventCriterion, root= "EVN.CRT"} |
Design Comments: Criterion is in Event Criterion mood. This has been fixed to "EVN.CRT" in the RMIM. Mapping: There is no 2.x equivalent |
||||||||
| code [1..1] Observation (CD) {CWE:D:ObservationType} |
Design Comments: A code that represents the type of criterion associated with the InterpretationRange, e.g. LOINC codes 30525-0 for age, and 21840-4 for gender. Mapping: OBX 3 is the V2.x equivalent for an observation code |
||||||||
| value [1..1] Observation (ANY) {CWE:D:ObservationValue} |
Design Comments: This defines the age range for example as the criterion value. Mapping: There is no 2.x equivalent |
||||||||
| interpretationCode [0..*] Observation (DSET<CD>) {CNE:D:ObservationInterpretation} |
Design Comments: Used to provide an interpretation of the Criterion value. Mapping: There is no 2.x equivalent |
||||||||
| device [0..*] (Device) | |||||||||
| consumable1 [0..*] (Consumable2) | |||||||||
| consumable2 [0..*] (Consumable) | |||||||||