IHE Devices
Technical Framework Supplement
Point-of-Care Identity Management (PCIM)
Revision 2.2 — Trial Implementation
Date: December 5, 2024
Author: IHE Devices Technical Committee
Email: dev@ihe.net
Foreword
This is a supplement to the IHE Devices Domain Technical Framework. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.
This supplement is published on December 5, 2024 for trial implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing, it will be incorporated into the Devices Technical Framework. Comments are invited and can be submitted at https://www.ihe.net/DEV_Public_Comments/.
This supplement describes changes to the existing technical framework documents.
“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume.
Amend Section X.X by the following:
Where the amendment adds text, make the added text bold underline. Where the amendment removes text, make the removed text bold strikethrough. When entire new sections are added, introduce with editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined.
General information about IHE can be found at https://www.ihe.net.
Information about the IHE Devices domain can be found at https://www.ihe.net/IHE_Domains/.
Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at https://www.ihe.net/resources/profiles/ and https://www.ihe.net/about_ihe/ihe_process/.
The current version of the IHE Devices Domain Technical Framework can be found at https://profiles.ihe.net/DEV/index.html.
Introduction to This Supplement
This supplement to the IHE Devices Technical Framework adds rationale and implementation details of the Point-of-Care Identity Management Profile to the Framework, providing a means for standards-based exchange between systems of information collected and confirmed at the point-of-care tracking the set of medical devices originating observations about each patient.
Open Issues and Questions
The work group solicits feedback on workflow effects and problems found in analyzing the profile and in trial implementation.
Closed Issues
Discuss differences from previous approaches based on ADT messages: will be faster, closer to the actual events than ADT feeds, which have a different purpose and are often not well synchronized with actual events at the point-of-care. Will enable devices, device controllers and a variety of other hospital systems to flexibly exchange information, publish or subscribe to change notifications.
IHE Technical Frameworks General Introduction and Referenced Versions
The IHE Technical Framework General Introduction is shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to this document where appropriate.
The IHE Technical Framework versions referenced in this document are listed below:
| Ref Name | Volume | Version | Date |
|---|---|---|---|
DEV TF-1 |
Volume 1 - Profiles |
Revision 10.0 - Final Text |
November 4, 2024 |
DEV TF-2 |
Volume 2 - Transactions |
Revision 10.0 - Final Text |
November 4, 2024 |
9 Copyright Licenses
IHE technical documents refer to, and make use of, a number of standards developed and published by several standards development organizations. Please refer to the IHE Technical Frameworks General Introduction, Section 9 - Copyright Licenses for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there.
10 Trademark
IHE® and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. Please refer to the IHE Technical Frameworks General Introduction, Section 10 - Trademark for information on their use.
IHE Technical Frameworks General Introduction Appendices
The IHE Technical Framework General Introduction Appendices are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these where appropriate.
Update the following appendices to the General Introduction as indicated below. Note that these are not appendices to this domain’s Technical Framework (TF-1, TF-2, TF-3 or TF-4) but rather, they are appendices to the IHE Technical Frameworks General Introduction located here. |
Appendix A — Actors
Add the following new or modified actors to the IHE Technical Frameworks General Introduction Appendix A. |
| Actor Name and Acronym | Definition | Actor OID |
|---|---|---|
Device-Patient Association Reporter (DPAR) |
A system that asserts a device-patient association or disassociation with the attributes related including location, starting and ending times, and observers involved. The system may be fully automated or require human machine interaction (HMI). Provisions are made so systems may report assertions that are final or those that require additional user validation. |
1.3.6.1.4.1.19376.1.6.3.22 |
Device-Patient Association Manager (DPAM) |
A system that receives and manages association assertions and association state and coordinates conflict resolution. The system delivers records that match device-patient association query filters in real-time. The system is required to provide an HMI to allow responsible observers to validate assertions that require it. |
1.3.6.1.4.1.19376.1.6.3.24 |
Device-Patient Association Consumer (DPAC) |
A system that receives device-patient association records from the manager in real-time. There is an option to dynamically filter the device-patient association records it wishes to receive via a subscription query. |
1.3.6.1.4.1.19376.1.6.3.23 |
Appendix B — Transactions
Add the following new transactions to the IHE Technical Frameworks General Introduction Appendix B: |
| Transaction Name and Number | Definition | Transaction OID |
|---|---|---|
Filter Associations (DEV-19) |
A Device-Patient Association Consumer sends an optional query to a Device-Patient Association Manager with filter criteria. The Device-Patient Association Manager sets up a real-time subscription with the specified filter criteria applied. |
1.3.6.1.4.1.19376.1.6.1.19.1 |
Communicate Association State (DEV-51) |
A Device-Patient Association Reporter asserts to a Device-Patient Association Manager that a device has been associated or disassociated with a patient and optional location. It may also report updated data for a previously reported assertion. |
1.3.6.1.4.1.19376.1.6.1.51.1 |
Report Association State (DEV-52) |
A Device-Patient Association Manager reports to a Device-Patient Association Consumer that a device has been associated or disassociated with a patient with optional location. It may also report an update for an existing association. |
1.3.6.1.4.1.19376.1.6.1.52.1 |
Appendix D — Glossary
Add the following new glossary terms to the IHE Technical Frameworks General Introduction Appendix D. |
| Glossary Term | Definition |
|---|---|
Assertion |
A statement that a certain premise is true, for example that a device has been prepared to collect data about a patient. |
Binding |
A process of associating two related elements of information. |
Biometrics |
A measurable physical characteristic or personal behavioral trait used to recognize the identity, or verify the claimed identity of a person. |
Direct Association |
A patient association established by the observation and recording of a physical connection of a device to the patient. |
Direct Device-Patient Association Assertion |
A claim of direct device-patient association based on evidence. |
Indirect Device-Patient Association |
A patient association asserted on the basis of a common attribute shared by a device and patient, such as a location. |
Location-based Assertion |
An assertion of an association between two objects (e.g., a patient and a device, device-to-device, patient-to-caregiver), based solely upon the co-location (e.g., same room and bed) of these two objects. |
Observation-Patient Association |
The assignment of a device measurement/parameter to a specific patient. Observation - patient associations are established through the connection relationship of a unique patient to a unique device at the point in time that the measurement was recorded by the device. |
Device-Patient Association Conflict Notification |
A message from a particular clinical IT system that it detects an inconsistency between different identity assertions. For example, a device and an intermediary system may be simultaneously asserting that a single data stream represents two different patients. |
Device-Patient Record Linkage |
The process of binding and/or associating a discrete patient record to a discrete device record. |
Precondition |
"What the system under analysis will ensure is true before letting the use case start." |
Receiving System |
In the context of PCIM, any system which is a consumer of device-patient association or observation messages, such as an electronic medical record system, device gateway, or a device at the point-of-care. |
Record |
The discrete representation of a specific and unique patient or the device in either the reporting or consuming system’s database. |
Strong Identity Assertion |
A presumption of patient or device unique recognition using multiple factors that provides a high degree of accuracy and certainty (e.g., barcode, biometric). |
Strong Identity Factors |
An identifier designed to be unique (applies to only one person) and consistent over the appropriate domain for at least throughout the visit or encounter, for example, Medical Record Number or National ID number. |
Unique Device Identifier |
In the US, a unique identifier for a medical device that is recognized by the US FDA and which has a part that identifies the maker and model of the device (DI) and a part that identifies the particular instance of the device. More generally, any identifier which allows a particular device to be uniquely identified. |
Weak Identity Assertion |
A presumption of patient or device unique recognition using factors that provides a low degree of accuracy and certainty (e.g., name, location). |
Weak Identity Factors |
Factors which can contribute to identification, but typically are not unique to patient; for example, name, sex, date of birth. |
Volume 1 — Profiles
Domain-specific additions
None
Editor: Add new Section 7 to DEV TF-1 |
7 Point-of-Care Identity Management (PCIM) Profile
The Point-of-Care Identity Management (PCIM) Profile is a Transport Profile specifying HL7 v2 standard messaging for devices and IT systems at a point-of-care to exchange and synchronize information about the identity of specific devices collecting clinical information about a specific patient, to:
-
Assist in the reliable association of the collected data to the proper patient record, based on first-hand observation and data entry by a person at the point-of-care, specifically designed to avoid wrong attribution of data from before or after the period of actual measurement on the patient.
-
Assist in maintaining a correct “census” of devices that frequently move between patients such as infusion pumps, and mechanical ventilators.
The messaging defined provides for capable devices to originate messages asserting association and disassociation to a particular patient, for human interface software components to afford users the opportunity to originate or confirm association or disassociation assertions, for one or more systems to receive and persist device-patient association information, to distribute reporting messages or receive and respond to queries about such associations.
7.1 PCIM Actors, Transactions, and Content Modules
This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at https://profiles.ihe.net/GeneralIntro/
Figure 7.1-1 shows the actors directly involved in the PCIM Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a required grouping are shown in conjoined boxes (see Section X.3).
Figure 7.1-1: PCIM Actor Diagram
Table 7.1-1 lists the transactions for each actor directly involved in the PCIM Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).
Table 7.1-1: PCIM Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
Device-Patient Association Reporter |
Communicate Association State |
I |
R |
DEV TF-2 3.51 |
Device-Patient Association Consumer |
Consume Association State |
R |
R |
DEV TF-2: 3.52 |
Filter Associations |
I |
O |
DEV TF-2: 3.19 |
|
Device-Patient Association Manager |
Consume Association State |
R |
R |
DEV TF-2: 3.51 |
Report Association State |
I |
R |
DEV TF-2: 3.52 |
|
Filter Associations |
R |
O |
DEV TF-2: 3.19 |
7.1.1 Actor Descriptions and Actor Profile Requirements
Requirements are documented in Transactions (Volume 2) and Content Modules (Volume 3). This section documents any additional requirements on profile’s actors.
7.1.1.1 Device-Patient Association Reporter
The Device-Patient Association Reporter actor asserts that a given device is associated or disassociated with a specific patient. The reporter may update existing associations. For each such event, the unique Patient ID, Device ID, and timestamp of the beginning of association or end of association shall be reported. If a location is known, it should be included in the report. Each report represents a single device patient association assertion. If the report is validated, the report observation status field shall be marked final, otherwise it shall be marked as requiring validation.
7.1.1.2 Device-Patient Association Manager
The Device-Patient Association Manager actor collects and persists information on devices currently associated with patients within a defined scope, such as a clinical unit and shall communicate validated associations as event notifications. The system is responsible for resolving conflicts and shall provide an HMI for validating association assertions that require validation and resolving conflicts.
7.1.1.3 Device-Patient Association Consumer
The Device-Patient Association Consumer actor receives information on what devices are associated with which patients. The actor initially receives current association status followed by updates in real-time. Common examples are a medical device or critical care system that charts device observations for a patient. The actor receives association updates in real-time.
7.1.1.4 Device Registration
The IHE MEM DMC profile enables automated contributions to the list of medical devices that can be associated with a patient.
The list of medical devices that can be associated with the patient may be pre-configured or automated with MEM DMC. Device registration may also be manually accomplished during system setup and maintenance. Examples of information available from MEM DMC are the device model, manufacturer, serial number, and network end point (ip address, port).
7.2 PCIM Actor Options
The Device-Patient Association Manager may optionally filter events sent to the Device-Patient Association Consumer. The filter request to the Manager results in an immediate delivery from the manager of the current active associations via DEV-52 messages based on the filter criteria. The Consumer then receives an unsolicited continuous stream of association state events. The Device-Patient Association Manager may support this subscription and filtering option.
Options that may be selected for each actor in this profile, if any, are listed in the Table 7.2-1. Dependencies between options, when applicable, are specified in notes.
Table 7.2-1: PCIM — Actors and Options
| Actor | Option Name | Reference |
|---|---|---|
Device-Patient Association Consumer |
Subscription and Filtering Option |
7.2.1 |
Device-Patient Association Manager |
Subscription and Filtering Option |
7.2.1 |
Device-Patient Association Reporter |
No options defined |
7.2.1 Subscription and Filtering Option
The subscription and filtering option applies to interactions between Device-Patient Association Manager and Device-Patient Association Consumer and specifies that the communication between manager and consumer is a filtered real-time delivery of device-patient association state.
A Device-Patient Association Consumer that supports this option shall formulate its request in the form described in Section 3.19.
7.3 PCIM Required Actor Groupings
There are no required actor groupings specified in the Point-of-Care Identity Management (PCIM) Profile.
7.4 PCIM Overview
7.4.1 Concepts
Properly validated associations between devices, and patients that the devices are sourcing observations for, are an essential underpinning for clinical surveillance and clinical decision support systems. Patient safety depends on certainty that the values being charted do not have gaps, or worse, data from the wrong patient.
This profile provides standards-based messages for communications about the beginning, end, and current state of intervals in which a device is associated with a particular patient. It uses HL7 version 2 messages, still the most common pattern in healthcare institutions for similar information such as patient demographics. It does not specify a particular configuration of systems for its functions, but rather describes roles which may be assigned to different systems according to the workflow in the institution. For example, selection of the patient and the devices could be accomplished on a module of an electronic medical record system, on a medical device such as a physiological monitor or ventilator with appropriate communication and display capabilities, or on a hand carried device controlling another healthcare information system.
7.4.2 Use Cases
7.4.2.1 Use Case #1: Associating Device with Patient
7.4.2.1.1 Description
A Device-Patient Association Reporter asserts a device-patient association to a Device-Patient Association Manager.
An authorized person at the point-of-care and able to see the patient and the devices has gathered and checked the unique identifying information for a patient and one or more devices that are designated to originate observations on that patient. Before being sent, the information is displayed to the operator for verification. Once verified, a message is originated by the Association with the following information:
-
Patient identifier unique within the scope of the institution
-
Method of data capture (for example, scanned device bar code and patient wrist band, fixed device location, etc.)
-
Time parameters (typically effective begin time of the association. In the case where only a single set of observation from the device is expected, as for a spot-check monitor, the end time of the association is simultaneous with the beginning time)
-
Authorized performing participant
7.4.2.1.2 Process Flow
This use case can be driven by an authorized user responsible for entering, verifying, or both, the beginning or ending of an association between a device and a particular patient. This should be based on first person awareness of the situation at the point-of-care. Automatic Identification and Data Capture methods such as barcodes or RFID should be used to assist the workflow and increase data reliability to the maximum feasible extent. In certain circumstances and with appropriate risk analysis, the association may be automatically generated. For example, a device with its own “admission” process, the act of manipulating the user interface at the point-of-care to “admit” a patient to the device may be deemed a patient-safe way of generating validated information of this device-patient association. For another example, a device with a fixed location and a known patient associated with the location may be appropriate to originate a device-patient association.
These means of identification are specific to the clinical environment in question, and standard procedures of risk analysis at the institution should be applied to assure that patient safety is adequately protected.
7.4.2.1.3 Pre-conditions:
Patient is to be associated with a device for clinical observations. Patient has been assigned unique identifier at registration which has been collected and verified at the point-of-care. Device identity has been registered for use. The identities of patient and device(s) have been collected and verified by an authorized person.
7.4.2.1.4 Main Flow:
Device-Patient Association Reporter originates a message with the specific information on the association and its time of beginning. When such an association message is received, the manager system is responsible for determining if any conflicting information is in the system and generating an appropriate error message to assist the responsible personnel in resolving the conflict.
7.4.2.1.5 Post-conditions:
After completion of this use case, an association record identifying the patient and the associated device and giving the start time of the association is created and persisted by the Device-Patient Association Manager.
7.4.2.2 Use Case #2: Disassociating Device From Patient
7.4.2.2.1 Description
At the time the device is no longer set up to make observations on the patient, the Device-Patient Association Reporter originates a message conveying this information to the Device-Patient Association Manager. It should be noted that even though this may be a less salient event at the point-of-care, completeness and accuracy of disassociation is as important to an accurate record and proper association of observations with patients. This is a key issue in risk analysis and in system design.
7.4.2.2.2 Process Flow
The Device-Patient Association Manager receives the information that the association between a particular patient and one or more devices no longer exists. An authorized operator may originate this message through a user interface. In some cases, the device itself is capable of determining that the association has been broken and can communicate this information directly to the Device-Patient Association Manager, or indirectly through the Device-Patient Association Reporter. It may be appropriate to note this event on a user interface and get confirmation that it is correct. It also could be appropriate to ask whether other devices on record as being connected to the same patient are still connected or not.
7.4.2.2.3 Pre-conditions:
Patient is to be disassociated with a device. Patient has been assigned unique identifier at registration which has been collected and verified at the point-of-care. Device identity has been registered for use. The identities of patient and device(s) have been collected and verified by an authorized person. The patient has already been associated with a device.
7.4.2.2.4 Main Flow:
Device-Patient Association Reporter originates a message with the specific information on the disassociation and its time of ending.
7.4.2.2.5 Post-conditions:
After completion of this use case, a record identifying the patient and the associated device and giving the end time of the association correlated with the starting time is persisted by the Device-Patient Association Manager.
7.4.2.3 Use Case #3 Filter Devices for a Patient
7.4.2.3.1 Description
A Device-Patient Association Manager may filter association messages to a Device-Patient Association Consumer for current and ongoing device patient associations. Retrospective queries are currently out of scope.
7.4.2.3.2 Process Flow
For status display or for error-checking and diagnostic purposes, the Device-Patient Association Manager sends the Device-Patient Association Consumer the current association records for each patient it is configured to receive.
7.4.2.3.3 Pre-conditions:
Patient has been assigned unique identifier at registration which has been collected and verified at the point-of-care. Device identity has been registered for use. The identities of patient and device(s) are known to the system or person performing the filtering.
7.4.2.3.4 Main Flow:
A Device-Patient Association Consumer originates a message to the Device-Patient Association Manager with the specific filter information for the devices to receive filtered association reports for.
7.4.2.3.5 Post-conditions:
After completion of this use case, if the manager supports the filtering option, a subscription filter for the requested devices and the requesting consumer is persisted and any matching association reports are sent by the Device-Patient Association Manager to the Device-Patient Association Consumer. If the manager does not support the filtering option, an appropriate error code is sent to the consumer when the filter request message is received.
7.5 PCIM Security Considerations
This profile itself does not impose specific requirements for authentication, encryption, or auditing, leaving these matters to site-specific policy or agreement based on careful risk analysis taking into account the security and privacy sensitivity of the patient and device-patient association content being handled. The IHE PCD Technical Framework identifies security requirements across all PCD profiles.
See the associated IHE PCD PCIM White Paper for additional discussion of some additional specific security concerns.
7.6 PCIM Cross Profile Considerations
This profile specifically covers associations and disassociations between patients and devices. As patient demographics and ADT information (e.g., patient location) are often integral to satisfying the use cases profiled in this document, implementers should be familiar with the following profiles within the IT Infrastructure Technical Framework:
-
Patient Administration Management Profile
-
Patient Demographics Query
-
ITI Patient Demographic Query - Patient Demographic Reporter
A Patient Demographic Consumer in IT Infrastructure might be used by a Device-Patient Association Reporter to allow presentation of a pick list of candidate patients to associate with one or more devices at the point-of-care.
7.7 Out of Scope Items
An actor that supports retrospective queries was considered. For the use cases outlined, it was noted that they require accurate up-to-date patient identification for transferring patient information with observations and alarms. Retrospective queries, although useful, were considered functionality deemed secondary and for further consideration in the future.
Appendices to Volume 1
Volume 2 — Transactions
Editor: Insert in Section 3 of DEV TF-2 as new Section 3.51 |
3.51 Communicate Association State [DEV-51]
3.51.1 Scope
This transaction is used by a Device-Patient Association Reporter to assert that an association has been established or broken between a device and a patient, or to update information reported previously by that reporter.
3.51.2 Actor Roles
The roles in this transaction are defined in the following table and may be played by the actors listed:
Table 3.51.2-1: Actor Roles
| Actor | Role |
|---|---|
Device-Patient Association Reporter |
The source of the assertion. Identifies the device, the patient, the responsible observer or automated system that is triggering the assertion for the association or disassociation, and the effective time. If the responsible observer verifies at the reporter, the manager does not need to verify. The reporter must record the responsible observer when verification occurs. The reporter must include in the observation the status field that indicates whether the assertion requires validation or is final (already verified). |
Device-Patient Association Manager |
Establishes or updates the persistent record of the association. The manager must provide a HMI to verify association and disassociation assertions. The manager is also responsible for conflict resolution with the HMI and sending corresponding HL7 ACK error codes at commit or application levels. Note that the HMI need not be constrained to running on the same device as the manager. For example, the HMI may be in the form of a mobile app. |
3.51.3 Referenced Standards
HL7 2.6 Chapters 2, 3, 5 and 7
3.51.4 Messages
Figure 3.51.4-1: Interaction Diagram
3.51.4.1 Communicate Association State
This is an HL7 Version 2 message giving details of the association being asserted. The message asserts an association between one device and one patient.
The manager may receive this message from multiple Reporter instances.
3.51.4.1.1 Trigger Events
This message is triggered when a logical connection between a device and a particular patient is established or removed, or when an attribute associated with an existing device-patient association has changed. If the event has been verified by a user, the message represents a final, updated or corrected association or disassociation.
3.51.4.1.2 Message Semantics
The significant content of the message is the following:
-
Confirmed unique identity of patient, preferably derived from an AIDC (Automatic Identification and Data Capture) such as scanning the patient wristband or reading an RFID tag. Code used to identify the patient must be chosen so as to be unique at least over the scope of the set of patients seen over all information systems in the institution, such as a Medical Record Number issued by the institution for the patient, or, if available, a national id number. The type and issuing entity shall be recorded with the code. Additional identity codes may be provided at the discretion of the institution. Note that any code identifiable with an individual patient must by secured from misuse in accordance with applicable legal and policy procedures.
-
Unique identity of Device. This again is determined by site considerations. It is preferable to use a universally unique identification of the individual instance of the device, such as an IEEE EUI-64 or a Unique Device Identifier such as one produced in accordance with the US FDA (or other regulatory agency) UDI standards. If this is not possible, then another universal identification scheme such as EUI-64 or a local identification scheme allowing all device instances in the institution to be uniquely distinguished and tracked may be used. Additional identification codes may be included. Whatever code is used should be possible to record automatically, as manual data entry has a high error rate, and correct identification is a patient safety concern.
-
Identity of the authorized person responsible for obtaining and visually confirming the identity information for the patient and the device.
The form of the message is similar to an unsolicited observation report, with supplementary PRT segments identifying the device, human operator originating the association. See Appendix 0 for details of HL7 V2 messages.
On receipt of the message, the manager system checks for valid syntax and that the:
-
originating reporter system and human user are included
-
the device is a member of the set of registered device instances and has no current conflicting association recorded (e.g., a single-patient device has an active association with a different patient)
-
the patient identity provided corresponds to a known person in an appropriate status (e.g., admitted)
After these checks, the Manager records the result and returns an appropriate positive or negative commit-level acknowledgement to the Reporter. If a positive commit-level acknowledgement is sent, an application-level acknowledgement may be sent to the Reporter after the association or disassociation is processed by the Manager (Additional detail on application acknowledgement semantics is forthcoming). The system design must assure that errors are indicated to the appropriate human user(s) in an effective and timely manner so that action can be taken. In this case, a technical alert should be raised using the ACM profile, the details of this are out of scope for this document.
Examples of application level errors that can occur during device patient association processing include the following:
-
Device specified by the Reporter is unknown to the Manager.
-
An association request is received by the Manager, but the specified device is associated with another patient.
-
Specified patient is unknown.
-
An internal error prevents the Manager from fulfilling the request.
If the checks are passed, the Manager establishes a record of the beginning or ending of the association and the effective time.
Editor: Insert in Section 3 of DEV TF-2 as new Section 3.52 |
3.52 Report Association State [DEV-52]
3.52.1 Scope
This transaction is used by a Device-Patient Association Manager to report to Device-Patient Association Consumers that an association has been established or broken between a device and a patient, or to update information reported previously.
3.52.2 Actor Roles
The roles in this transaction are defined in the following table and may be played by the actors listed:
Table 3.52.2-1: Actor Roles
| Actor | Role |
|---|---|
Device-Patient Association Manager |
Reports confirmed association events to consumers. The manager must provide a HMI to verify association and disassociation assertions from a reporter if required, and once verified it persists the record and reports it to any consumers configured to receive the events in real-time. The manager should support filtering of messages, and may support dynamic filtering requested by the consumer. The manager must send current associations for all devices that the consumer is configured to receive reports for immediately after a connection is established. |
Device-Patient Association Consumer |
The receiver of the verified and final association report. The Consumer may optionally initiate a subscription by sending a message with filtering criteria, if any, to the Manager in the form of a HL7 query. The subscription and filter may also be pre-configured in the Manager. The Consumer initially receives current association status followed by updates in real-time on a connection established by the Manager. When an association report is successfully received, a commit-level accept acknowledgement must be returned to the Manager. |
3.52.3 Referenced Standards
HL7 2.6 Chapters 2, 3, 5 and 7
3.52.4 Messages
Figure 3.52.4-1: Interaction Diagram
3.52.4.1 Report Association State
This is an HL7 Version 2 message giving details of the association being reported. The message reports an association between one device and one patient.
The manager must send this message to all configured Consumer instances with matching filter criteria.
3.52.4.1.1 Trigger Events
This message is triggered when a validated association or disassociation is received.
The significant content of the message is the following:
-
Confirmed unique identity of patient, preferably derived from an AIDC (Automatic Identification and Data Capture) such as scanning the patient wristband or reading an RFID tag. Code used to identify the patient must be chosen so as to be unique at least over the scope of the set of patients seen over all information systems in the institution, such as a Medical Record Number issued by the institution for the patient, or, if available, a national id number. The type and issuing entity shall be recorded with the code. Additional identity codes may be provided at the discretion of the institution. Note that any code identifiable with an individual patient must by secured from misuse in accordance with applicable legal and policy procedures.
-
Unique identity of Device. This again is determined by site considerations. It is preferable to use a universally unique identification of the individual instance of the device, such as an IEEE EUI-64 or a Unique Device Identifier such as one produced in accordance with the US FDA (or other regulatory agency) UDI standards. If this is not possible, then another universal identification scheme such as EUI-64 or a local identification scheme allowing all device instances in the institution to be uniquely distinguished and tracked may be used. Additional identification codes may be included. Whatever code is used should be possible to record automatically, as manual data entry has a high error rate, and correct identification is a patient safety concern.
-
Identity of the reporter system that originated the association or disassociation.
-
Identity of the authorized person responsible for obtaining and visually confirming the identity information for the patient and the device.
The form of the message is similar to an unsolicited observation report, with supplementary PRT segments identifying the device, reporter system and human operator validating the association.
See Appendix 0 for details of HL7 V2 messages.
On receipt of the message, the Consumer parses and extracts the association details before returning an appropriate commit-level acknowledgement to the Manager. If the message is semantically and syntactically valid, the Consumer returns a positive acknowledgement and utilizes the record of the beginning or ending of the association and the effective time for the specified patient and device. If the message is invalid, the Consumer returns a negative acknowledgement. Once the commit-level acknowledgement is received by the Manager, it records that the message was delivered to the Consumer along with the corresponding acknowledgement code.
Editor: Insert in Section 3 of DEV TF-2 as new Section 3.19 |
3.19 Filter Associations [DEV-19]
3.19.1 Scope
This transaction is used by a Device Patient Association Consumer to access filtered device-patient association information held by a Device Patient Association Manager.
As stated previously, the DEV-19 transaction is optional. If the message is accepted by the Device-Patient Association Manager, the accept acknowledgement shall contain the value CA in MSA-1.
If this message is not supported, MSA-1 shall contain the value CR, ERR-3 (HL7 Error Code) shall contain the value 200 (Unsupported Message Type), and ERR-4 (Severity) shall contain the value E. If the transaction is not supported, and the network connection between the Device-Patient Association Manager and Device-Patient Association Consumer is lost, the Device-Patient Association Manager shall send DEV-52 messages for all current Device-Patient associations to the Device-Patient Association Consumer when network connectivity is restored. This ensures the Device-Patient Association Consumer has the current association state.
3.19.2 Actor Roles
TBD
Figure 3.19.2-1: Use Case Diagram
Table 3.19.2-1: Actor Roles
| Actor | Role |
|---|---|
Device-Patient Association Consumer |
Establishes a real-time message reporting subscription filter for Device-Patient Associations. This may be filtered for device or location. It establishes an ongoing feed of device-patient association information. |
Device-Patient Association Manager |
Fulfills a request from a Device-Patient Association Consumer for device-patient association information filtered as specified by the Consumer |
3.19.3 Referenced Standards
HL7 2.6 Chapters 2, 3, 5 and 7
3.19.4 Messages
Figure 3.19.4-1: Interaction Diagram
3.19.4.1 Filter Associations
This message from a Device-Patient Association Consumer requests a filtered real-time event stream from a Device-Patient Association Manager containing device-patient association data. A Device-Patient Association Manager is expected to be able to service multiple Device-Patient Association Consumer systems and manage different query and response streams and communications connections with each. Whether these communications ports are pre-configured, or dynamic with appropriate node identification and authorization for each connection request, is a matter of implementation design. This profile chooses the QSB publish-subscribe paradigm, where the request is for an ongoing real-time feed of changes in associations using special semantics of query parameters described below.
3.19.4.1.1 Trigger Events
This message is triggered by the Device-Patient Association Consumer when it requires information about current associations for devices or patients in the form of a continuing feed of data.
3.19.4.1.2 Message Semantics
This message is a query specification. It gives the scope of the information wanted by the Device-Patient Association Consumer in response to the query: what patients, units, devices are pertinent. See Appendix 0 for details of HL7 segment contents and semantics.
3.19.4.1.3 Expected Actions
The Device-Patient Association Manager is responsible for collecting, formatting and sending the requested information back to the Device-Patient Association Consumer according to the filtering specified in the query.
3.19.4.2 Filter Associations Response
The response is a commit-level acknowledgement. If the request is ill-formed (incorrect syntax or impossible query specification), an indication of the nature of the error should be returned.
3.19.4.2.1 Trigger Events
This message and the activity of preparing it, is triggered in the Device-Patient Association Manager by the query filter request from the Device-Patient Association Consumer. This trigger initially requests the setting up of a sequence of messages reporting all device-patient associations matching the filter criteria. Once the initial device-patient associations have been sent, subsequent changes in the device-patient association state will trigger additional messages to be sent to the Device-Patient Association Consumer as long as the current subscription is in effect. A subscription remains in effect until it is canceled or modified by the Device-Patient Association Consumer.
3.19.4.2.2 Expected Actions
The Device-Patient Association Consumer is expected to take actions depending on the reason it made the query request and its own business logic. An example would be for a device without its own selection and validation mechanism for identifying the patient it is interacting with to receive and use the information from the Device-Patient Association Manager to send that patient identity information with its observations or display the patient identity on its user interface.
3.19.5 Security Considerations
No special security or security audit considerations beyond the general ones already discussed apply to this transaction.
Volume 2 Namespace Additions
The PCD registry of OIDs is located at https://wiki.ihe.net/index.php/PCD_OID_Management.
Additions to the PCD OID Registry are:
| OID | Refers to |
|---|---|
1.3.6.1.4.1.19376.1.6.1.19.1 |
Point-of-Care Identity Management - Filter Associations [DEV-19] |
1.3.6.1.4.1.19376.1.6.1.51.1 |
Point-of-Care Identity Management - Communicate Device-Patient Association [DEV-51] |
1.3.6.1.4.1.19376.1.6.1.52.1 |
Point-of-Care Identity Management - Report Device-Patient Association [DEV-52] |
Appendices to Volume 2
Appendix A — Proposed Messages
The descriptions of these messages do not repeat all information in the related sections of the DEV TF-2 or the base HL7 specifications, which should be consulted for additional details. The base version of HL7 used in IHE PCD Profiles is version 2.6; however, this profile uses the semantics of the PRT segment which was not introduced until version 2.7 and not extended with full details of the Unique Device Identifier until version 2.8.2.
A.1 Communicate and Report Association State
As all of the use cases identified in this profile can be considered observations (it was observed that device d1 was connected to patient p1 starting at t1 and ending at t2), the ORU message structure is used throughout this profile to manage associations. This description is also applicable to an Communicate Device-Patient Disassociation scenario – the only difference between the Association and Disassociation messages is the content of OBX-5. The Message Structure and attendant notes also serve to specify the segment pattern to be expected in Report Association State [DEV-52] messages. The prototype for the IHE Patient Care Device observations in this profile is the [PCD-01] in the Device Enterprise Communication Profile (DEV TF-2: 3.1), which implementers should familiarize themselves with – it consists of useful background information and contains details on some fields that are not covered in this profile.
Communicate and Report Association messages for DEV-51 and DEV-52 transactions, respectively, use the same structure, with the following differences that pertain to DEV-52:
-
A report must always have a OBX-11 status that is not "R" (requires validation)
-
A report may contain an additional participant segment of the responsible observer (human) that validated the association using the Manager HMI
A.1.1 Message Structure
Table A.1.1-1: Communicate Device-Patient Association
| Segments | Meaning | Usage | Cardinality |
|---|---|---|---|
MSH |
Message Header |
R |
[1..1] |
[{SFT}] |
Software Segment |
X |
[0..0] |
[UAC] |
User Authentication Credential |
O |
[0..1] |
{ |
— PATIENT_RESULT begin |
R |
[1..1] |
{ |
--- PATIENT begin |
R |
[1..1] |
PID |
Patient Identification |
R |
[1..1] |
{ |
— VISIT begin |
R |
[1..1] |
PV1 |
Patient Visit Information (for room bed) |
R |
[1..1] |
} |
--- VISIT end |
||
} |
--- PATIENT end |
||
{ |
--- ORDER_OBSERVATION begin |
R |
[1..1] |
OBR |
Observation Request |
R |
[1..1] |
OBX |
Observation Result |
R |
[1..1] |
{PRT} |
Participation — One PRT segment for device, one for person or system making assertion and conditionally one for person doing additional validation |
R |
[2..3] |
} |
--- ORDER_OBSERVATION end |
||
} |
--- PATIENT_RESULT end |
MSH, SFT, and UAC Segments follow the specifications for [PCD-01] in DEV TF-2 Appendix B.1, except that in the MSH segment, MSH-21 is valued “IHE_DEV_051^IHE PCD^1.3.6.1.4.1.19376.1.6.1.51.1^ISO” to identify it as a Communicate Device-Patient Association or “IHE_DEV_052^IHE PCD^1.3.6.1.4.1.19376.1.6.1.52.1^ISO” to identify it as a Report Device-Patient Association. In the context of this specification, the message is constrained to reporting association(s) for a single patient and device.
A.1.2 Segments
A.1.2.1 MSH — Message Header
Since this message is effectively an unsolicited observation report, the contents of the MSH segment follow the specifications for [PCD-01] in DEV TF-2 Appendix B.1, except for the following changes:
Table A.1.2.1-1: MSH Fields
| SEQ | DT | OPT | Description |
|---|---|---|---|
15 |
ID |
R |
Accept Acknowledgement Type - This must be set to "AL" and is returned on the same connection as the initiating message. |
16 |
ID |
R |
Application Acknowledgement Type – Set to AL, NE or ER. See IHE PCD TF Vol 2 Table 3.3.4.4.1-1 for description of possible values and their meaning. |
21 |
EI |
R |
Message Profile Identifier - Value set to "IHE_DEV_051^IHE PCD^1.3.6.1.4.1.19376.1.6.4.51.1^ISO" |
A.1.2.2 PID — Patient Identification
In order to assert an association between a patient and a device, the PID segment is required. It identifies the patient who is associated to the device. The Patient Identifier List must contain an identifier that is unique for all patients within the scope of the system. By default, if an identifier on the list is identified as a medical record number, it is used (PID-3.5 Identifier Type code valued as “MR”). There may be multiple identifiers in the list, and implementers may choose to allow a different identifier than the medical record number to be used as a configuration option.
Table A.1.2.2-1: PID Fields
| SEQ | DT | OPT | RP | Description |
|---|---|---|---|---|
1 |
SI |
O |
Set ID - PID |
|
3 |
CX |
R |
Y |
Patient Identifier List |
5 |
XPN |
O |
Y |
Patient Name |
7 |
DTM |
RE |
DOB |
|
8 |
IS |
RE |
Gender |
A.1.2.3 PV1 Patient Visit Information
See transaction [PCD-01] for basic information (DEV TF-2 Appendix B.6). In this profile, the PV1 segment is used to convey patient location information in PV1-3 Assigned Patient Location.
A.1.2.4 OBR — Observation Request
This segment serves as a wrapper for an association observation. It gives the association message a unique identifier in the Filler Order Number OBR-3. This is a required field: it acts as an association object instance identifier for tracking is used for tracking messages from all sources in the overall configuration of systems, so it must be constrained by some method of generation that assures that duplicate identifiers between sources are not possible. It gives the timestamp of the beginning of the association (OBR-7), and when it is known, the end of the association (OBR-8).
Table A.1.2.4-1: OBR Fields
| SEQ | DT | OPT | Description |
|---|---|---|---|
1 |
SI |
O |
Set ID - OBR |
3 |
EI |
R |
Unique instance identifier for the association event. Must be constrained during generation to ensure duplicate identifiers between sources are not possible. See Appendix B.7 OBR - Observation Request Segment OBR-3 Filler Order Number for additional details. |
4 |
CE |
R |
Universal Service Identifier – set to 69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC |
7 |
TS |
C |
Earliest participant involvement |
8 |
TS |
C |
Latest participant involvement |
29 |
EIP |
C |
Unique instance identifier for the originating association event that all updates apply to. See Appendix B.7 OBR - Observation Request Segment OBR-29 Parent (EIP) 00261 for additional details. |
The OBR shall also include the timestamp of the earliest participant involvement (OBR-7) and latest participant involvement (OBR-8) for an association or disassociation event report. Each report consists of two Participation Information Segments (PRT) and each may have timestamps for their involvement in PRT-11 and/or PRT-12. OBR-7 and OBR-8 conveys the range of time of both participants. See Table A.1.2.6-3 and Table A.1.2.6-4 for definitions of the timestamp semantics in PRT-11 and PRT-12. The logic for filling in the timestamp values for OBR-7 and OBR-8 is to examine both the PRT segments that will be sent out in the report and set OBR-7 to the earliest timestamp value and OBR-8 to the latest timestamp value. OBR-7 and 8 may contain the same timestamp.
A.1.2.5 OBX — Observation
This segment conveys the “observation” that the patient has been associated or disassociated to a device. It includes the time stamp of the association event and whether the event is a association or disassociation.
A set of PRT segments accompanies it to convey the device, and the responsible observer. The PID segment conveys the patient identification.
Table A.1.2.5-1: OBX Fields
| SEQ | DT | OPT | RP | Description |
|---|---|---|---|---|
1 |
SI |
O |
Set ID - OBX |
|
2 |
ID |
R |
Value Type — set to CWE |
|
3 |
CWE |
R |
Observation Identifier — set to 68487^MDC_ATTR_EVT_COND^MDC |
|
4 |
ST |
O |
Observation Sub-ID. Use to convey a specific channel that’s been associated, as <MDS>.<VMD>.<CHANNEL>.<facet> |
|
5 |
CWE |
R |
Observation Value. See Table A.1.2.5-2: OBX-5 Values. |
|
11 |
ID |
R |
Observation Result Status. See Table A.1.2.5-3: OBX-11 Values. |
Table A.1.2.5-2: OBX-5 Values
| Observation Value | Description |
|---|---|
198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC |
Device has been associated to a patient. |
198334^MDC_EVT_DISASSOCIATION_PATIENT_DEVICE^MDC |
Device has been disassociated from a patient. |
Table A.1.2.5-3: OBX-11 Values
| Status | HL7 Description | Adaptation |
|---|---|---|
C |
Record coming over is a correction and thus replaces a final result. |
Record coming over is a correction and thus replaces a validated association. |
D |
Deletes the OBX record |
Deletes the association record. |
F |
Final results; can only be changed with a corrected result. |
Validated association. Can only be changed with a corrected association record. |
R |
Results entered — not verified |
An association has been asserted, but not validated. |
W |
Post original as wrong, e.g., transmitted for wrong patient. |
Post original as wrong, e.g., transmitted for wrong patient. |
A.1.2.6 PRT — Participation (Observation Participation)
This segment conveys information about persons and/or devices and systems that participated in the association, ancillary to the patient and device that are its subjects. There will be PRT segments identifying the device, responsible observer, and/or reporting system of a device-patient association as described in Section 0. For example:
-
A nurse that established and/or validated an association
-
A device gateway
-
A reporter system sending a non-validated assertion
-
The device itself, if the patient ID is entered directly onto the device
Table A.1.2.6-1: PRT Fields
| SEQ | DT | OPT | RP | Description |
|---|---|---|---|---|
| 2 | ID | R | Action Code. Always value to UC (unchanged). | |
| 4 | CWE | R | Participation. Includes Participation Code, Text and Name of Coding System. See table A.1.2.6-2 for details for code in PRT 4.1. PRT 4.2 shall be set to the same value as PRT 4.1. PRT 4.3 must be set to HL70912. | |
| 5 | XCN | Y | Participation Person. If a person is the participant in this association message, his or her ID and name appear here. | |
| 9 | PL | Y | Participant Location. Location where association was asserted or observed. | |
| 10 | EI | C | Y | Participation Device. If a device is the initiator of this association record (PRT-4 = AUT), its ID appears here. Format is the same as in existing IHE PCD profiles and will match PRT-10 of device-as-subject PRT segment of this message, provided that the device associated with the patient and the device reporting the participation are one and the same (e.g., patient admitted on this monitor). If this PRT segment identifies this device as the subject of the association (PRT-4 = EQUIP), its ID appears here. Note — Prior to HL7 2.7, this would have appeared in OBX-18. |
| 11 | DTM | C | Participation Begin Date/Time (arrival time). Refer to Table A.1.2.6-3. | |
| 12 | DTM | C | Participation End Date/Time (departure time). Refer to Table A.1.2.6-4. | |
| 13 | CWE | O | Participation Qualitative Duration. Not used in this profile. | |
| 14 | XAD | O | Participation Address | |
| 15 | XTN | O | Participant Telecommunication Address | |
| 16 | EI | O | Participant Device Identifier. From UDI, should be present if known. See discussion below. | |
| 17 | DTM | Participant Device Manufacture Date. From UDI, should be present if known. | ||
| 18 | DTM | O | Participant Device Expiry Date. Not normally applicable in this profile. | |
| 19 | ST | O | Participant Device Lot Number. Not normally applicable in this profile. | |
| 20 | ST | C | Participant Device Serial Number. From UDI, should be present if known. |
Table A.1.2.6-2: PRT-4 Values
| Participation | HL7 Description | Adaptation |
|---|---|---|
AUT |
AUT Author/Event Initiator |
The participant (nurse, device, etc.), initially asserts the association. An RO participant is not included if the association is validated at the time it was asserted. |
EQUIP |
Equipment |
The participant is the device that is a subject of the device-patient association. |
RO |
Responsible Observer |
The participant (nurse, etc.) observes an already asserted association as a prelude to adjusting, validating, or marking in error. A RO PRT segment shall be included in a DEV-52 if the DEV-51 is validated at the manager. Association or Disassociation assertion messages with OBX-11 values of 'C', 'D' and 'W' shall always be validated by a RO using the Manager HMI and thus the RO PRT segment must be included in the resulting DEV-52. |
PRT-10 Participation Device (EI)
PRT-10 should contain some form of identifier sufficient to uniquely identify the device within the scope of the overall system. This is a repeating field, so more than one identifier can be given. If available, it should have as one of its values the “human readable form” of the Unique Device Identifier defined by the US FDA. See details in the UDI Final Rule (U.S. Food and Drug Administration 2013).
It should be noted that the use of OBX-18 for equipment identification has been deprecated. So for long-term use, the PRT segment is preferred. See DEV TF-2 Appendix B.10.2 for details of how the PRT segment should be used for equipment identification.
Definition: Identifier for the device participating. This may reflect an unstructured or a structured identifier such as FDA UDI, RFID, IEEE EUI-64 identifiers, or bar codes.
If this attribute repeats, all instances must represent the same device.
Condition: At least one of the Participation Person, Participation Organization, Participation Location, or Participation Device fields must be valued.
If this field contains an FDA UDI, it shall contain the entire Human Readable Form of the UDI. For example, a GS1-based UDI would be represented as follows:
|(01)00643169001763(17)160712(21)21A11F4855^^2.16.840.1.113883.3.3719^ISO|
A HIBCC-based example would be represented as follows:
|+H123PARTNO1234567890120/$$420020216LOT123456789012345/SXYZ4567890123 45678/16D20130202C^^2.16.840.1.113883.3.3719^ISO
The identifier root shall be the OID assigned to UDI. For example, for FDA UDIs the root shall be 2.16.840.1.113883.3.3719, and the extension shall be the Human Readable Form appropriate for the style of content. When captured as a simple string, the string shall be the Human Readable Form appropriate for the style of content. The content style can be determined from the leading characters of the content:
UDIs beginning with:
'`('` are in the GS1 Human Readable style;
‘0-9’ are a GS1 DI (containing only the DI value, no PI or GS1 AI);
'`+'` are in the HIBCC Human Readable style;
‘='` or '`&’ are in the ICCBBA Human Readable style.
| If “&” is used in the UDI while one of the delimiters in MSH.2 includes “&” as well, it must be properly escaped per Chapter 2.7 of the HL7 Specification. |
The exchange of UDI sub-elements in PRT-16 through PRT-21 is not required when the full UDI string is provided in PRT.10.
When a UDI is provided and sub-elements are also provided, then for those sub-elements that are valued, the content must match the content encoded in the UDI if it is encoded within the UDI.
| The UDI may contain personally identifying information in the form of the device serial number which may be used to link to other information on a patient. Standard practice for exchanging potentially identifying content should be exercised when exchanging UDIs which contain a serial number. |
| PRT.10 is a repeating field. Additional device identifiers, such as an IEEE EUI-64 may also be contained in this field. |
Table A.1.2.6-3: PRT-11 Interpretation
| Participation Status | AUT | EQUIP | RO |
|---|---|---|---|
R-Asserted |
Time that the person/device asserted the association between the patient and device. |
Time that the device-patient association is asserted to have been established. |
Unusual. Time that the person in this role observed the person/device in the AUT role asserting the association. |
C-Corrected |
n/a |
Corrected time that the device-patient association is asserted to have been established. |
Time that the person in this role issued the correction. |
D-Deleted |
n/a |
n/a |
Time that the person in this role issued the deletion order. |
F-Validated |
n/a |
Time that the device-patient association is confirmed to have been established. If null, most recently asserted/corrected time has been confirmed. |
Time that the person in this role validated the association. |
W-Wrong |
n/a |
n/a |
Time that the person in this role declared the association to be erroneous. |
Table A.1.2.6-4: PRT-12 Interpretation
Participation → ↓Status |
AUT | EQUIP | RO |
|---|---|---|---|
| R-Asserted | Time that the person/device asserted the disassociation between the patient and device. | Time that the device-patient disassociation is asserted to have taken place. | Unusual. Time that the person in this role observed the person/device in the AUT role asserting the disassociation. |
| C-Corrected | n/a | Corrected time that the device-patient association is asserted to have ended. | Time that the person in this role issued the correction. |
| D-Deleted | n/a | n/a | n/a |
| F-Validated | n/a | Time that the device-patient association is confirmed to have ended. If null, most recently asserted/corrected time has been confirmed. | Time that the person in this role validated the disassociation. |
| W-Wrong | n/a | n/a | n/a |
PRT-16 Participation Device Identifier (EI)
Definition: Provides the U.S. FDA UDI device identifier (DI) element.
This is the first component in the UDI and acts as the look up key for the Global Unique Device Identification Database (GUDID), and may be used for retrieving additional attributes.
When exchanging Device Identifiers (DI) the root shall be the OID, or standards’ appropriate corollary to the OID, assigned to DI and the extension shall be the Human Readable Form of the content. For example, for DIs the root shall be:
GS1 DIs: 2.51.1.1
HIBCC DIs: 1.0.15961.10.816
ICCBBA DIs: 2.16.840.1.113883.6.18.1.17 for Blood containers and 2.16.840.1.113883.6.18.1.34 otherwise.
Example: |00643169001763^^2.51.1.1^ISO|
A.1.3 Application Acknowledgement Message
Table A.1.3-1: Communicate Device-Patient Association - Application Acknowledgement Message
| Segments | Description | Usage |
|---|---|---|
MSH |
Message Header - Defined in Appendix B.1 |
R |
MSA |
Message Acknowledgement - Defined in Appendix B.2 |
R |
[{ ERR }] |
Error - Defined in Appendix B.3. |
C |
[{ SFT }] |
Software |
X |
[{ NTE }] |
Notes and Comments |
X |
The list of error codes that can occur during the processing of DEV-51 messages are listed below. The application acknowledgement sent by the Device-Patient Association Manager should contain the Code and Text in ERR-5.1 and ERR-5.2 respectively. ERR-5.9 can also be used to contain additional text related to the error.
| The definition of the range of error codes available for use by this profile is TBD. It is assumed that error codes will start at the lower limit of the range and be incremented by one as new error codes are added. |
| Code | Text | Example |
|---|---|---|
Lower limit |
Other error |
Used when other errors are not applicable. |
Lower limit + 1 |
Unknown device |
Specified device is unknown. |
Lower limit + 2 |
Unknown patient |
Specified patient is unknown. |
Lower limit + 3 |
Device is associated with another patient |
A device-patient association or disassociation request was received, but the device specified in the request is associated with a different patient. |
Lower limit + 4 |
Device is not associated with a patient |
A device-patient disassociation request was received, but the device specified in the request is not associated with a patient. |
Lower limit + 5 |
Unknown location |
Specified location is unknown. |
Lower limit + 6 |
Device-Patient association rejected. |
Device-Patient Association Reporter sent an unvalidated Device-Patient association request (OBX-11 is not equal to \‘F\’). Association request was rejected by the participating user. |
Lower limit + 7 |
User is unauthorized. |
Participating user is unauthorized to perform request. |
Lower limit + 8 |
Unknown user |
Participating user is not known by the Device-Patient Association Manager. |
A.2 Filter Associations Message
A.2.1 Scope
This optional message allows a system to dynamically configure a filtered subscription for a list of the device-patient associations meeting specified conditions.
A.2.2 Use Case Roles
A.2.3 Details of Device-Patient Association Query Message [DEV-19]
This message is used by a Device-Patient Association Consumer to request current device-patient association information from a Device-Patient Association Manager followed by a on-going subscription to ongoing real-time device-patient association information, specifying filtering by message receiver, location or device identification. The query takes the form of a QSB publish and subscribe query as described in HL7 Chapter 5, Section 5.7.3.1. It is almost identical to the profile for the QSB^Z83^QSB_Q16 trigger with ORU^R01^ORU_R01 response trigger described in Section 5.7.3.1 of the HL7 specification except that the query parameters are different to accommodate the semantics of filtering for device-patient associations, and the observation reports sent in real-time and constrained by the filtering, while conforming to the ORU_R01 message structure, have the specific semantics of transaction Device-Patient Association Reports [DEV-52].
For identification, the arbitrary “local” (i.e., not issued by the HL7 organization) trigger event Z66 is used for the query/subscription message. This applies for initial testing but is subject to change before this profile is submitted for final text.
Table A.2.3-1: Query Profile
| Name | Value |
|---|---|
Query Statement ID |
Z66 |
Type |
Publish |
Query Name |
Device Patient Association Query |
Query Trigger |
QSB^Z66^QSB_Q16 |
Query mode |
Both |
Response Trigger |
ORU^R01^ORU_R01 |
Query Characteristics |
Triggers a realtime subscription with filtering. No results are returned directly. |
Purpose |
Requests filtering of device-patient association records, as defined in input parameters |
Response Characteristics |
The response contains a commit-level ACK. |
Table A.2.3-2: QBP^Z66^QBP^QBP_Z66 Query Grammar - QBP Message Segments
| Segments | Description | HL7 Section Reference |
|---|---|---|
MSH |
Message Header Segment |
2.15.9 |
[{SFT}] |
Software Segment |
|
[UAC] |
User Authentication Credential |
2.14.13 |
QPD |
Query Parameter Definition |
5.5.4 |
RCP |
Response Control Parameter |
5.5.6 |
A simple commit-level ACK is expected as response to this query, see section B.2 in IHE PCD TF VOL 2.
The results of a successful query results in the manager sending all [DEV-52] messages reporting current device-patient association events followed by ongoing real-time updates to device-patient association events, all filtered according to optional query parameters. If the connection is lost, the manager must continue to try and establish a new connection to the consumer, always sending the current device-patient association events matching the filter once the connection is re-established.
A.2.3.1 MSH Segment
Same as for transaction [PCD-01] in DEV TF-2 Appendix B.1, except that MSH-9 is valued as QSBQ66QSB_Q16 and MSH-21 is valued as IHE_DEV_019^IHE PCD^1.3.6.1.4.1.19376.1.6.4.19.1^ISO.
A.2.3.2 QPD Segment
Table A.2.3.2-1: QPD - Query Parameter Definition
| Mnemonic | Description | Type | Optionality | Length | Table | Repetition |
|---|---|---|---|---|---|---|
QPD.1 |
Message Query Name - Set to 'Q66^Device-Patient Subscription^HL7005' |
CE |
Required |
250 |
471 |
No |
QPD.2 |
Query Tag |
ST |
Optional |
32 |
No |
|
QPD.3 |
User Parameters |
VARIES |
Optional |
256 |
No |
|
QPD.4 |
Action Code |
ID |
323 |
Table A.2.3.2-2: QPD Input Parameter Specification
| Field Seq (Query ID=Z99) |
Name | LEN | DT | OPT | R/# | TBL | Segment Field Name |
Element Name |
|---|---|---|---|---|---|---|---|---|
| 1 | MessageQueryName | 60 | CWE | R | MessageQueryName | |||
| 2 | QueryTag | 32 | ST | R | QueryTag | |||
| 3 | User Parameters | ID | 0 | 033 | ActionCode |
Table A.2.3.2-3: Identifiers for field, component, or subcomponent in QPD.3 User Parameters
| FLD | ELEMENT NAME |
|---|---|
PV1.3.1 |
Assigned Patient Location — Point-Of-Care (least accurate location) |
PV1.3.2 |
Assigned Patient Location — Room (least accurate location) |
PV1.3.3 |
Assigned Patient Location — Bed (least accurate location) |
PRT.9.1 |
Participation Device Location — Point-Of-Care (most accurate location, if present) |
PRT.9.2 |
Participation Device Location — Room (most accurate location, if present) |
PRT.9.3 |
Participation Device Location — Bed (most accurate location, if present) |
PRT.10.1 |
Participation Device — Entity Identifier |
PRT.10.2 |
Participation Device — Namespace Id |
PRT.10.3 |
Participation Device — Universal Id |
PRT.10.4 |
Participation Device — Universal Id Type |
The QueryTag (QPD.2) is used to identify a query instance and therefore must be unique for each query.
The User Parameters field (QPD.3) is used to specify “filtering” values, so that the query response can be limited to, for example, the records matching a particular Assigned Location (by including a PV1.3.1 specification), a particular device (by adding a Participation Device PRT specification) and so on. If multiple specifications are given, the responding system "`AND`"s the specifications together, so that for example, a patient location and a device identifier specification result in the response only gives associations involving that patient location and device.
The form of the User Parameters specifications in QPD.3 field uses one or more repetition of the QSC data type (separated by the HL7 repetition separator, by default the tilde character ~), one for each query parameter to be specified, with each repetition using the QSC data type. This data type takes the form of a component specifying the field, component, or subcomponent to filter on as @<seg>.<field number>.<component number>.<subcomponent number>, followed by a logical operator component (normally EQ for “equals”), and a component giving the value sought for that field. An example would be:
@PV1.3.1^EQ^MICU~@PRT.10.1^EQ^PUMP1
This means limit the messages given in response to ones involving patient location at point-of-care MICU and device identifier PUMP1.
The Device-Patient Association Manager is responsible for executing the search in accordance with the filters. The different query parameter filters are ANDed together, that is, only associations where all query parameters match the sought value will be sent by the Device-Patient Association Manager.
Where the association records have query parameter fields that are repeated (as for example where multiple patient identifiers of different Identifier Types, or multiple device identifiers of different Identifier Types, are present), the Device-Patient Association Manager will consider the association record matched and send it if any value present in any repeat of the repeated field matches the sought value without regard to the Identifier Type.
A.2.4 RCP Segment
Table A.2.4-1: RCP - Response Control Parameter
| Field | Description | Type | Optionality | Length | Table | Repetition |
|---|---|---|---|---|---|---|
1 |
Query Priority |
ID |
R |
1 |
91 |
No |
2 |
Query Limited Request |
X |
||||
3 |
Response Modality |
CNE |
R |
|||
4 |
Execution and Deliver Time |
|||||
5 |
Modify Indicatory |
ID |
Table A.2.4-2: RCP Response Control Parameter Field Description and Commentary
| Field Seq (Query ID=Z99) |
Name | Component Name |
LEN | DT | Description |
|---|---|---|---|---|---|
| 1 | Query Priority | 1 | ID | Deferred / Immediate | |
| 2 | Quantity Limited Request | 10 | CQ | Not applicable, this profile does not support continuation | |
| 3 | Response Modality | 60 | CWE | Real time or Batch. Default is R. | |
| 4 | Execution and Delivery Time | DTM | Only valued when RCP-1 Query Priority contains the value D (deferred) | ||
| 5 | Modify Indicator |
The possible values for RCP-1, Query Priority, are:
| Value | Description | Comment |
|---|---|---|
D |
Deferred |
|
I |
Immediate |
Quantity limited requests are not supported, so RCP-2 Quantity Limited Request value is not used.
The supported values of RCP-3 Response Modality is R (Real Time). The Device-Patient Association Consumer must support receiving a continuous real-time feed of association events and will receive all existing associations when the connection is first established that meet the desired filter specification to get the starting state. After that initial state is received, association records are sent as they arrive at the Device-Patient Association Manager. The Device-Patient Association Consumer can optionally configure (or reconfigure) filter criteria and even cancel the continuing real-time query dynamically.
RCP-4 Execution and Delivery Time is required when RCP-1 contains the value of D (Deferred). It specifies when the response is to be returned.
RCP-5 Modify Indicator specifies whether a new subscription is being requested (value: N), or a modification is being made to an existing subscription (M). QPD-4 Action Code can signify the deletion of a subscription with a value of D.
A.2.5 Cancelling a Subscription
A subscription may be explicitly cancelled by the Device-Patient Association Consumer by sending a QSX^J66^QSX_J01 message, which is simply an MSH segment containing that string as MSH-9, followed by a QID segment identifying the subscription being cancelled with QID Query Identification Segment containing in field QID-1 the Query Tag (from QPD-2 of the original query establishing the subscription) and in QID-2 the Message Query Name (from QPD-1 of the original query). See Appendix Section A.3 Example Messages, Example 4.
A.3 Example Messages
Example 1: At 12:00, Nurse Diesel connected patient Spaniel to a continuous physiological monitor with ID MON5588. At 12:30, she records the association on the Critical Care application. As she is an RN and has witnessed and entered the association on the Critical Care system, this is considered a validated association. This message would be sent from the Critical Care system in the role of Association Reporter to the Association Manager. Note that since Nurse Diesel recorded the association 30 minutes after the association occurred, the timestamps for OBR-7 and OBR-8 capture that range of time in the OBR wrapper segment. Additionally, each PRT segment provides specific time for each participant. For the device equipment, when that association occurred and for the initiator Nurse Diesel who validated the association when it was recorded.
MSH|^~\&|CritCare||AssocMgr||20160726123002||ORU^R01^ORU_R01|12d15a9|P|2.6|||AL|AL|USA||||IHE_DEV_051^IHE PCD^1.3.6.1.4.1.19376.1.6.1.51.1^ISO PID|||AB60001^^^A^PI||Spaniel^C^R^^^^L PV1||E|3 WEST ICU^3001^1 OBR|||15404652|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726120000|20160726123000 OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC||||||F PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 WEST ICU^3001^1|MON5588^^231A8456B1CB2366^EUI-64|20160726120000 PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3001^1||20160726123000
The Association Manager first responds with the following commit level acknowledgement.
MSH|^~\&|AssocMgr||CritCare||20160726123002||ACK^R01^ACK|12d1510|P|2.6|||NE|NE MSA|CA|12d15a9
Once the association is fully processed, the Association Manager responds by initiating the following application level acknowledgement
MSH|^~\&|AssocMgr||CritCare||20160726123003||ACK^R01^ACK|AM52E123|P|2.6|||AL|NE||8859/1|||IHE_DEV_051^IHE PCD^1.3.6.1.4.1.19376.1.6.4.51.1^ISO MSA|AA|12d15a9
To which the Association Reporter responds with a commit level acknowledgement, completing the exchange.
MSH|^~\&|CritCare||AssocMgr||20160726123003||ACK^R01^ACK|AM52E125|P|2.6|||NE|NE MSA|CA|AM52E123
Example 2: At 16:00, Nurse Ratched connected patient McMurphy to a continuous physiological monitor with ID MON5596. She enters his patient ID on the monitor and presses a button causing the association to be asserted.
MSH|^~\&|MonitorGateway||AssocMgr||20160726160000||ORU^R01^ORU_R01|12d1574|P|2.6|||AL|AL|USA||||IHE_DEV_051^IHE PCD^1.3.6.1.4.1.19376.1.6.1.51.1^ISO PID|||AB60001^^^A^PI||McMurphy^R^P^^^^L PV1||E|3 WEST ICU^3001^1 OBR|||15404697^^132233FFFE445566^EUI-64|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726160000|20160726160000 OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC||||||R PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 WEST ICU^3001^1|MON5588^^231A8456B1CB2366^EUI-64|20160726120000 PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3001^1||20160726123000
(Acknowledgement messages not shown)
Since the assertion requires validation, the Association Manager presents an HMI showing the relevant details and a confirmation button to the responsible observer, Nurse Ratched in this case, and she then presses a confirmation button to validate the association. The Association Manager may then broadcast this information to subscribers (such as Critical Care), or its clients (such as Critical Care) may query for this information, depending on how the systems are integrated.
At 16:45, she confirms the association on the Critical Care application (or the Association Manager, depending on how the systems are integrated). This message would be sent from the Critical Care system in the role of Association Reporter to the Association Manager.
Example 3: A device controller needs an ongoing feed of all devices connected to a patient in a specific room. The controller opens a subscription to the Device-Patient Association Manager to get a filtered device-patient information feed of the relevant data in room 10 of the MICU:
MSH|^~\&|MonitorGateway||AssocMgr||20160726160000||QSB^Z66^QSB_Q16|12d1579|P|2.6|||AL|AL||8859/1|||IHE_DEV_019^IHE PCD\^1.3.6.1.4.1.19376.1.6.1.19.1^ISO QPD|Q66^Device-Patient Subscription^HL7005|Q0044|@PV1.3.1^EQ^MICU@PV1.3.2^EQ^10 RCP|I||R||N
The Device-Patient Association Manager responds by starting a continuous stream of Report Association [DEV-52] messages, starting with message(s) giving the current device associations of the patient (which will require the Device-Patient Association Manager to access that information and format it in [DEV-52] form).
MSH|^~\&|AssocMgr||AssocConsumer||20160726160000||ORU^R01^ORU_R01|12d1599|P|2.6|||AL|AL|USA||||IHE_DEV_052^IHE PCD^1.3.6.1.4.1.19376.1.6.1.52.1^ISO PID|||AB60001^^^A^PI||McMurphy^R^P^^^^L PV1||E|3 WEST ICU^3001^1 OBR|||2543241^^020000FFFE000000^EUI-64|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726160000|20160726160000 OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC||||||F PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 WEST ICU^3001^1|MON5596^^231A8456B1CB2366^EUI-64|20160726160000 PRT|2|UC||AUT^AUT^HL70912|58796^Ratched^N||||3 WEST ICU^3001^1||20160726160000 PRT|3|UC||RO^RO^HL70912|58796^Ratched^N||||3 WEST ICU^3001^1||20160726164500
To cancel the subscription, the Device-Patient Association Consumer can send the following cancel message:
MSH|^~\&|MonitorGateway||AssocMgr||20160726168000||QSX^J66^QSX_J01|12d1879|P|2.6|||AL|NE||8859/1|||IHE_DEV_019^IHE PCD^1.3.6.1.4.1.19376.1.6.1.19.1^ISO QID|Q0044|Q66^Device-Patient Subscription^HL7005
Example 4:
At 23:00, Nurse Ratched disconnected patient McMurphy from the physiological monitor previously connected in Example 2. She presses a button and then confirms causing the disassociation to be asserted.
MSH|^~\&|MonitorGateway||AssocMgr||20160726230000||ORU^R01^ORU_R01|12d1586|P|2.6|||AL|AL|USA||||IHE_DEV_51^IHE PCD^1.3.6.1.4.1.19376.1.6.1.51.1^ISO PID|||AB60001^^^A^PI||McMurphy^R^P^^^^L PV1||E|3 WEST ICU^3001^1 OBR|||15404712^^132233FFFE445566^EUI-64|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726230000|20160726230000|||||||||||||||||||||^15404697&&132233FFFE445566&EUI-64 OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198334^MDC_EVT_DISASSOCIATION_PATIENT_DEVICE^MDC||||||R PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 WEST ICU^3001^1|MON5596^^231A8456B1CB2366^EUI-64||20160726230000 PRT|2|UC||AUT^AUT^HL70912|58796^Ratched^N||||3 WEST ICU^3001^1||20160726230000
B.7 OBR - Observation Request Segment
OBR-3 Filler Order Number
Add the following definition after the last paragraph ending on line 2436:
In the DEV-51 and DEV-52 transactions of the PCIM Profile, this field serves as the unique identifier for the initial association instance and each subsequent update to that association. This value is assigned by the Device-Patient Association Reporter (DEV-51) and Device-Patient Association Manager (DEV-52). For the initial association message, OBR-29 Parent is required to be empty. For all subsequent updates to the same association, OBR-3 Filler Order Number identifies the unique update and OBR-29.2 Parent Filler-Assigned Identifier contains the value from OBR-3 Filler Order Number of the initial association instance. Device-Patient Association Reporters that are sending an update for an association instance they did not create are not required to fill in OBR-29.2, but Device-Patient Association Managers shall fill in OBR-29.2 for updates. This allows the Device-Patient Association Consumer to correlate all subsequent updates with the original association.
When transcribing the components of the OBR-3 field value to OBR-29.2, all subcomponents shall be transcribed and the component delimiters (^) replaced with subcomponent delimiters (&).
OBR-29 Parent (EIP) 00261
Add the following definition after the last paragraph ending on line 2554:
The EI data type value in the OBR-29.2 Parent Filler-Assigned Identifier field serves as the unique association instance identifier in DEV-51 and DEV-52 transactions of the PCIM profile. It is assigned by a Device-Patient Association Reporter (DEV-51) and Device-Patient Association Manager (DEV-52), and is used by Device-Patient Association Manager and Device-Patient Consumer to associate all updates to a particular association instance throughout the history of the association. The Device-Patient Association Reporter shall fill in OBR-29.2 with the originating OBR.3 Filler Order Number for all updates to association instances that it initially originated. The Device-Patient Association Manager shall fill in OBR-29.2 with the originating OBR.3 Filler Order Number in all DEV-52 messages conveying updates to an association instance. See OBR-3 Filler order Number for additional information.
When transcribing the components of the OBR-3 field value to OBR-29.2, all subcomponents shall be transcribed and the component delimiters (^) replaced with subcomponent delimiters (&).
Volume 3 — Content Modules
No content modules
Volume 4 — National Extensions
No national extensions