Skip to content

Conversation

@eldonmetz
Copy link
Collaborator

Closes # 110,117

πŸ“‘ Description

Update TI based on feedback for corrections and deletion capabilities.

βœ… Checks

  • My pull request adheres to the code style of this project
  • My code requires changes to the documentation
  • I have updated the documentation as required
  • All the tests have passed
  • I have selected a committee co-chair to review the PR

β„Ή Additional Information

@eldonmetz eldonmetz requested review from TomKowal and kelliaso May 29, 2025 17:33
@eldonmetz eldonmetz changed the title Cp dev 018 CP-DEV-018 May 29, 2025
Copy link

@jbraschler jbraschler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As previously discussed, I'd like to suggest the following additions to clarify corrections use cases as part of this CP:

In 7.4.2 Use Cases:

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.

An action is taken in the Device-Patient Association Reporter's system that corrects one of the key parameters of an existing verified device-patient association. The following key parameters SHALL trigger a correction if changed during the course of an active device association:
β€’ Effective begin time of the association
β€’ Effective end time of the association

Other parameters of the verified device-patient association MAY trigger correction based on the requirements of the specific implementation. For example, if chart correction actions can be taken in the Device-Patient Association Reporter system that change the patient's unique identifier while the patient has an active device-patient association, AND that change is not being communicated to the Device-Patient Association Manager using other means, such as an HL7 ADT message, a correction message will communicate the correction to the patient's identifying information.

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(s) 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 and giving the up-to-date start time of the association is updated in the Device-Patient Association Manager.

In A.3 Example Messages:

Example 5:
Patient record Trauma, Unknown represents a patient of unknown identity who is admitted to the ICU after a vehicle accident. At 06:30, Nurse Diesel connected the patient to a continuous physiological monitor with ID MON6789. At 06:45, she records the association on the Critical Care application. As she is an RN and has witnessed and entered the association in the Critical Care system, this is considered a validated association.

MSH|^~&|CritCare||AssocMgr||20160726064502||ORU^R01^ORU_R01|94e03d4|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|||AB60005^^^A^PI||TRAUMA^UNKNOWN^^^^^L
PV1||E|3 WEST ICU^3004^1
OBR|||15404649|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726063000|20160726064500
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^3004^1|MON6789^^231A8456B1CB2484^EUI-64|20160726063000
PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3004^1||20160726064500

(Acknowledgement messages not shown)

At 08:00, the patient's identity has been ascertained to be patient Benjamin Davis, who has an existing record in the Critical Care system. Working with Health Information Management, it is determined to be safe to merge the temporary trauma record with the patient's existing permanent patient record. The merge is performed in the Critical Care system, and a correction for the verified association is sent to the device manager containing the updated patient information in PID. A unique identifier for the correction event is sent in OBR-3, and the association identifier that was sent in OBR-3 for the original association message is sent in OBR-29.2. Additionally, the observation status in OBX-11 is sent as "C" to indicate the event is a correction to a verified association.

MSH|^~&|CritCare||AssocMgr||20160726082502||ORU^R01^ORU_R01|94e05d9|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|||AB40001^^^A^PI||DAVIS^BENJAMIN^C^^^^L
PV1||E|3 WEST ICU^3004^1
OBR|||15404649-0001|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726063000|20160726064500|||||||||||||||||||||^15404649
OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC||||||C
PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 West ICU^3004^1|MON6789^^231A8456B1CB2484^EUI-64|20160726063000
PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3004^1||20160726064500

(Acknowledgement messages not shown)

@jbraschler
Copy link

Noting some options here for where to add additional language around the use of additional profiles (e.g., PAM/ADT, PDQm/FHIR, etc.) for managing patient identity between a Device Association Reporter and Device Association Manager.

In Section 7.6 PCIM Cross Profile Considerations
A Device-Patient Association Manager should use the ITI Patient Administration Management Profile to proactively update patient demographics and identity in lieu of correcting the patient identity for associations using PCIM.

In Section 3.51.4.1.2 Message Semantics
Implementations should account for cases where the patient identity for an active association may change as a result of chart corrections, preferably using the ITI Patient Administration Management profile, or by correcting the patient identity for the association using PCIM.

@jbraschler
Copy link

jbraschler commented Oct 21, 2025

Proposed updates for "Wrong" associations in CP-DEV-018:

7.4.2 Use Cases, add an additional use case subsection, 7.4.2.5 Wrong Associations:

Proposed Text:

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 device-patient association is deleted or otherwise indicated to be wrong in the Device-Patient Association Reporter. 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, including the association unique instance identifier in OBR-29.2 that was sent in OBR-3 of the initial message that asserted the 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.

3.51.4.1.2 PCIM TI - Message Semantics, add another sub-section, 3.51.4.1.4 Wrong Semantics to specify the semantics of wrong associations:

Proposed Text:

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.

When a device-patient association is asserted 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.

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.

A.3 PCIM TI - Example Messages, add example #6 to illustrate asserting an association is wrong:

Proposed Example:

Example 6:
At 22:00, Nurse Diesel connected patient Harrison to a continuous physiological monitor with ID MON5568. At 22:15, she records the association in the Critical Care application, but she selects MON5569 from the pick list by mistake. As she is an RN and has witnessed and entered the association on the Critical Care system, this is considered a validated association.

MSH|^~&|CritCare||AssocMgr||20160726221502||ORU^R01^ORU_R01|95e03fa|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|||AB60009^^^A^PI||HARRISON^D^F^^^^L
PV1||E|3 WEST ICU^3002^1
OBR|||15404852|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726220000|20160726220000
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^3002^1|MON5569^^231A8456B1CB2491^EUI-64|20160726220000
PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3002^1||20160726221500

(Acknowledgement messages not shown)

At 22:20, Nurse Diesel notices that the physiological monitor data isn't flowing into the Critical Care system as expected and discovers that the device originally associated with the patient is wrong. She deletes the association for MON5569 from patient Harrison in the Critical Care system, which originates a message to the Device-Patient Association Manager indicating that the previously reported association is wrong. A unique identifier for the deletion event is sent in OBR-3, and the association unique instance identifier that was sent in OBR-3 for the original association is in OBR-29.2. Additionally, the observation status in OBX-11 is sent as "W" to indicate the association is wrong.

MSH|^~&|CritCare||AssocMgr||20160726222135||ORU^R01^ORU_R01|95e0405|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|||AB60009^^^A^PI||HARRISON^D^F^^^^L
PV1||E|3 WEST ICU^3002^1
OBR|||15404852-0001|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726222000|20160726222000|||||||||||||||||||||^15404852
OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC||||||W
PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 West ICU^3002^1|MON5569^^231A8456B1CB2491^EUI-64|
PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3002^1||20160726222000

(Acknowledgement messages not shown)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants