PCD Brief Profile Proposal 2009 PoC ID Management

Proposed Workitem: Point-of-Care Identity Management

• Proposal Editor: Todd Cooper / Khalid Zubaidi
• Editor: TBD
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Patient Care Devices (PCD)

The Problem

Information acquired from a device must be associated with a patient in order for it to be properly recorded and available for clinical decision making. Though the current IHE PCD Technical Framework provides for a DEC DOR actor to authenticate a patient ID (e.g., using ITI PAM or PDQ profiles), there is no profile mechanism for associating and disassociating a device or other identifier with a patient at the point of care. In some cases this data if associated with the wrong patient, may result in incorrect documentation, increasing the potential of documentation errors or even mistreatment.

A typical process involves manual assignment of patient identifier to the device. This manual assignment process can be inconsistent and can lead to manual data entry errors. With the emerging adoption of Bar-Coding Medication Administration (BCMA) and Bar-Coding at the Point of Care (BPOC) systems, there is an opportunity in automating this process. The medication administration workflow being proposed by these systems includes a positive patient identification step. Although the PIV profile supports this assignment as a part of populating infusion parameters, this profile does not cover all user needs in assigning patient identifiers outside of an infusion administration workflow.

The need is to provide mechanisms (e.g., patient association transaction) to enable point-of-care patient to device or other "resource" association.

Key Use Cases

Proposed 11073-20103 CCoM

A recently parkinglotted standard profile for Clinical Context Management (CCoM) included a proposed finite state machine for managing associations / identification of a device as it moves through various clinical contexts:

Standards & Systems

A number of technical approaches have been suggested; however, given the general HL7 ver 2.x foundation for most of the PCD enterprise-related profile components, most of the proposals have centered around leveraging either current or closely related technical approaches:

1. HL7 v2 ORU^R30 (Ch. 7, a la POCT)

2. HL7 v2 Scheduling - SRM / SIU (Ch. 10)

• 10.4.7 NOTIFICATION OF ADDITION OF SERVICE/RESOURCE ON APPOINTMENT (EVENT S18)..........................10-21
• 10.4.8 NOTIFICATION OF MODIFICATION OF SERVICE/RESOURCE ON APPOINTMENT (EVENT S19) ..................10-21
• 10.4.9 NOTIFICATION OF CANCELLATION OF SERVICE/RESOURCE ON APPOINTMENT (EVENT S20) .................10-22
• 10.4.10 NOTIFICATION OF DISCONTINUATION OF SERVICE/RESOURCE ON APPOINTMENT (EVENT S21) ............10-22
• 10.4.11 NOTIFICATION OF DELETION OF SERVICE/RESOURCE ON APPOINTMENT (EVENT S22)..........................10-22

3. HL7 v2 ADT - encounter paradigm

Additional Considerations

1. This technical framework should be applicable to multiple implementation technologies, such as barcodes, RF-ID tags, RTLS systems, ultrasound solutions, etc.
2. Other IHE domains, especially ITI, may be interested in working on this jointly.
3. Other non-IHE coordination - other standards-based organizations may also be very interested in partnering with IHE PCD in the development of this profile, including AAMI.

Discussion

Technological Risks

• An assessment needs to be made regarding technologies currently in use to determine the best technologies for the profile developer's initial focus. Note: When this area was first assessed by PCD in the 2005 time frame, there was so little standardization that it was deemed best to defer working on this area to a future date.