Point-of-Care Identity Management (PCIM)
-Revision 2.3 — Trial Implementation
+Revision 2.4 — Trial Implementation
++++ -Date: November 6, 2025 +Date: May 7, 2026 Author: IHE Devices Technical Committee @@ -48,8 +48,7 @@ Email: dev@ihe.net 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 November 6, 2025 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 is published on May 7, 2026 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. @@ -521,6 +520,42 @@ A Device-Patient Association Consumer originates a message to the Device-Patient 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.4.2.4 Use Case #4 Correcting Verified Associations + +===== 7.4.2.4.1 Description + +A Device-Patient Association Reporter asserts a correction to a verified device-patient association to a Device-Patient Association Manager. + +===== 7.4.2.4.2 Process Flow +This use case is driven by an authorized user taking an action that alters one of the key parameters of an existing verified device-patient association. This should be based on first-person awareness of the situation at the point-of-care. For example, if a device-patient association is created and verified for a patient retroactively and the effective begin time of the association isn't back-dated appropriately, an authorized user may manually alter the begin time of the association, which should trigger a correction. This can also be a result of other system actions. For example, if a device-patient association was initiated for a device with a fixed location upon transferring the patient into the associated bed, and the effective time of the transfer is changed, a correction should be sent to update the effective begin time of the association. + +===== 7.4.2.4.3 Pre-conditions +An existing verified device-patient association is to be corrected. The patient has been assigned a 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 the patient and device have been collected and verified by an authorized person. The patient has already been associated with a device. + +===== 7.4.2.4.4 Main Flow +The Device-Patient Association Reporter originates a message with the specific information on the association, including the parameters that were corrected. + +===== 7.4.2.4.5 Post-conditions +Upon completion of this use case, the association record identifying the patient and the associated device now contains the corrected information in the Device-Patient Association Manager. + +==== 7.4.2.5 Use Case #5 Wrong Associations + +===== 7.4.2.5.1 Description +A Device-Patient Association Reporter asserts that a previously-reported device-patient association is wrong to a Device-Patient Association Manager. + +===== 7.4.2.5.2 Process Flow +This use case is driven by an authorized user marking an existing device-patient association as being wrong. This should be based on first-person awareness of the situation at the point-of-care. For example, if a device-patient association is created and verified for a patient, but the device selected for the association was the wrong device, an authorized user may delete the association, which should trigger a message indicating that the association is wrong. + +===== 7.4.2.5.3 Pre-Conditions +An existing verified device-patient association is to be deleted or otherwise indicated to be wrong. The device-patient association has already been reported to the Device-Patient Association Manager. + +===== 7.4.2.5.4 Main Flow +The Device-Patient Association Reporter originates a message with the specific information on the wrong association. + +===== 7.4.2.5.5 Post-conditions +Upon completion of this use case, the association record identifying the patient and associated device is marked as wrong in the Device-Patient Association Manager. + + == 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. @@ -539,6 +574,8 @@ As patient demographics and ADT information (e.g., patient location) are often i 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. +A Device-Patient Association Reporter or Device-Patient Association Consumer should utilize the MEMLS profile if the most up-to-date location information is needed. + == 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. @@ -612,11 +649,13 @@ This message is triggered when a logical connection between a device and a parti The significant content of the message is the following: +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. +Note that any code identifiable with an individual patient must by secured from misuse in accordance with applicable legal and policy procedures. Implementations should account for cases where the patient identity may change as a result of chart corrections. This should trigger the sending of a correction message of the patient identity to the Manager for active associations known to the reporter. This may also trigger the sending of a correction message to the Manager for completed associations. - 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. @@ -647,6 +686,61 @@ Examples of application level errors that can occur during device patient associ If the checks are passed, the Manager establishes a record of the beginning or ending of the association and the effective time. +===== 3.51.4.1.3 Correction Semantics + +Corrections should be sent from the Device-Patient Association Reporter to the Device-Patient Association Manager when a key parameter for an existing device association has changed. The considerations around which parameters should initiate corrections may differ for active vs completed associations. + +**Table 3.51.4.1.3-1: Correctable Parameters for Active Associations** +[%autowidth] +|=== +|Parameter|Semantics + +|Begin Time +|Changes to the begin time of an active association shall trigger a correction. + +|Patient ID +|Changes to the Patient ID should trigger a correction if the human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the use-case of patient merges (ADT A40), ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43), or contact move (ADT A45). + +|Participant (RO, AUT) +|Changes to a participant may trigger a correction. + +|Location +|Changes to the beginning location of the association may trigger a correction. + +|=== + +**Table 3.51.4.1.3-2: Correctable Parameters for Completed Associations** +[%autowidth] +|=== +|Parameter|Semantics + +|Begin Time +|Changes to the begin time of a completed association shall trigger a correction. + +|End Time +|Changes to the end time of a completed association shall trigger a correction. + +|Patient ID +|Changes to the Patient ID should trigger a correction if the human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the use-case of patient merges (ADT A40), ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43), or contact move (ADT A45). + +|Participant (RO, AUT) +|Changes to the participants for the dissociation event may trigger a correction. Note, changes to the participants at the time of the beginning association event are not correctable. + +|Location +|Changes to the ending location of the association may trigger a correction. Note, changes to the beginning location of a completed association are not correctable. + +|=== + +The device identifier and the association unique instance identifier SHALL NOT be changed in a correction message. All correction messages shall reference the association unique instance identifier from the original message in OBR-29.2. + +===== 3.51.4.1.4 Wrong Semantics + +An existing device-patient association should be asserted as "Wrong" from the Device-Patient Association Reporter to the Device-Patient Association Manager whenever either the device or the patient that was reported with the association was wrong. All messages asserting an existing device-patient association as wrong shall reference the association unique instance identifier in OBR-29.2 that was sent in OBR-3 of the original message that asserted the association. +A new association with the valid patient may be asserted after the Wrong has been reported. + +Note that there are chart correction use cases where the Device-Patient Association Reporter's understanding of the identity of the patient changes but the human who is associated to the device is semantically the same (such as with a patient merge). In these cases, the patient identity change may be handled either by correcting the patient identity for the existing association as described in section 3.51.4.1.3 above or by marking the existing association as wrong and re-asserting the association. The new assertion shall have a new association unique instance identifier in OBR-3 and includes the corrected patient identity. + + |=== |Editor: Insert in Section 3 of DEV TF-2 as new Section 3.52 |=== @@ -702,6 +796,8 @@ The manager must send this message to all configured Consumer instances with mat This message is triggered when a validated association or disassociation is received. +===== 3.52.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. @@ -724,6 +820,16 @@ 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. +===== 3.52.4.1.3 Correction Semantics + +Correction reports must be sent from the Device-Patient Association Manager to Device-Patient Association Consumers when they are validated. See table 3.51.4.1.3-1 and table 3.51.4.1.3-2 for correctable parameters that may be reported for active and completed associations. + +===== 3.52.4.1.4 Wrong Semantics + +An existing device-patient association should be reported as "Wrong" from the Device-Patient Association Manager to the Device-Patient Association Consumer whenever either the device or the patient that was reported with the association was wrong. All messages reporting an existing device-patient association as wrong shall reference the association unique instance identifier in OBR-29.2 that was sent in OBR-3 of the original message that reported the association. + +When a device-patient association is reported to be "Wrong", any device data that was reported for that device-patient association should also be deleted or flagged for review in any consumers that are using the device-patient association to file received device data to the patient. Device-Patient Association Consumers that are also device data reporter actors shall stop including the wrong patient identifier in outgoing messages as soon as it receives the Wrong association report. + |=== |Editor: Insert in Section 3 of DEV TF-2 as new Section 3.19 |=== @@ -740,8 +846,6 @@ If this message is not supported, MSA-1 shall contain the value CR, ERR-3 (HL7 E === 3.19.2 Actor Roles - TBD - **Figure 3.19.2-1: Use Case Diagram** @@ -1029,7 +1133,7 @@ In this profile, the PV1 segment is used to convey patient location information 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). +It gives the timestamp of the earliest participant involvement (OBR-7) and the latest participant involvement (OBR-8). **Table A.1.2.4-1: OBR Fields** @@ -1069,7 +1173,9 @@ It gives the timestamp of the beginning of the association (OBR-7), and when it |=== 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. +Each report consists of two or more 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 all 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 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 @@ -1142,10 +1248,6 @@ See Table A.1.2.5-3: OBX-11 Values. | 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. @@ -1159,6 +1261,7 @@ Can only be changed with a corrected association record. | 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) @@ -1351,7 +1454,8 @@ Additional device identifiers, such as an IEEE EUI-64 may also be contained in t **Table A.1.2.6-3: PRT-11 Interpretation** |=== -| *Participation Status* | *AUT* | *EQUIP* | *RO* +| *Participation →* + +*Status* | *AUT* | *EQUIP* | *RO* | R-Asserted | Time that the person/device asserted the association between the patient and device. @@ -1360,61 +1464,57 @@ Additional device identifiers, such as an IEEE EUI-64 may also be contained in t 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/device asserted the correction to the association between the patient and device. +| Corrected time that the device-patient association is asserted to have been established, if the correction is for an association time change, otherwise the original time. | 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 person/device validated the association between the patient and device at the time it was asserted. | 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 +| Time that the person/device in this role declared the association between the patient and device to be erroneous. | 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+++ | ++++++