Difference between revisions of "PCD Brief Profile Proposal 2009 PoC ID Management"

Latest revision as of 14:04, 5 October 2009

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

...TBD...

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

This technical framework should be applicable to multiple implementation technologies, such as barcodes, RF-ID tags, RTLS systems, ultrasound solutions, etc.
Other IHE domains, especially ITI, may be interested in working on this jointly.
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.

@@ Line 12: / Line 12: @@
 ==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.
-Patient Care Devices (PCD) hold valuable information about the treatment being delivered to patients. Device  Observation Reporters (DOR)  publishes this valuable information to Device Observation Consumers (DOC) that  use this valuable data to complete the medical record  documentation for patients. However, this data published by  the DOR requires a patient identifier be available either within the message or  through a separate mapping function  maintained by the DOR. 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.
-Currently, IHE PCD group assumes the device has been assigned the correct patient identifier. 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.
-I propose that we include an optional patient association transaction that would complete the needs around the  patient to device association.
+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==
+===...TBD...===
-''<Feel free to add a second use case scenario demonstrating how it “should” work.  Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.>''
+===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:
+[[Image:IHE_PCD_CCoM_FSM_Diag_2007_r1.png|frame|center]]
 ==Standards & Systems==
@@ Line 31: / Line 32: @@
 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:
-<HL7 v2 R30>
+:1.  HL7 v2 ORU^R30 (Ch. 7, a la POCT)
-<hl7 V2 ADT - encounter paradigm>
-<HL7 v2 Ch. 10 approach - scheduling & resource allocation>
-<CCoM>
-===Additional Considerations===
+: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 ==
 :# This technical framework should be applicable to '''''multiple implementation technologies''''', such as barcodes, RF-ID tags, RTLS systems, ultrasound solutions, etc.
 :# '''''Other IHE domains''''', especially ITI, may be interested in working on this jointly.
 :# '''''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==
@@ Line 46: / Line 54: @@
 ===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.
+:* 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.