From cff7788eadad5d6e8d8f3a193578b4df99e2ad34 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 29 May 2025 10:31:11 -0700 Subject: [PATCH 01/13] Update CP-DEV-018 title, rationale and content. --- CPs/draft/cp-dev-018.html | 145 +++++++++++++++++++++++++------------- asciidoc/cp-dev-018.adoc | 107 +++++++++++++++++----------- 2 files changed, 162 insertions(+), 90 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index 7730707..c2f55fd 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -464,7 +464,7 @@

Tracking Information

Date of last update:

-

2025-03-20

+

2025-05-29

Person Assigned:

@@ -484,7 +484,7 @@

Change Proposal Summary Informatio -

OBR-7/8 and PRT-11/12 semantics for DEV-51 and DEV-52 for corrected, deleted and wrong

+

Clarifying requirements and semantics for DEV-51 and DEV-52 for corrected, deleted and wrong message indicator

Submitter’s Name(s) and e-mail address(es):

@@ -510,11 +510,11 @@

Change Proposal Summary Informatio

Volume(s) and Section(s) affected:

-

PCIM TI, Sections A.1.2.4 and A.1.2.6

+

PCIM TI, Sections A.1.2.4, A.1.2.5 and A.1.2.6

Rationale for Change:

-

While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations wwere also identified to be clarified and/or updated. It was agreed on in the PCIM WG to clarify the requirements around interpretation of these fields in a CP.

+

While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to support corrections for patient identity changes for merges, unmerges, id changes and contact moves. It was agreed on in the PCIM WG to clarify the requirements around interpretation of these fields in a CP.

This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issue.

@@ -525,40 +525,13 @@

Change Proposal Summary Informatio -

Section A.1.2.4 in PCIM TI - OBR - Observation Request, update the text to clarify population of OBR-7/8 on deleted, corrected and wrong scenarios:

- - - -
-

Existing Text:

-
-
-

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.

-
- -
-
-

Proposed Text:

-
-
-

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.

-
- --- - - - +

Section A.1.2.6 in PCIM TI - OBR - Observation Request, Table A.1.2.6-3 update to clarify interpretation of PRT-11 on deleted, corrected and wrong scenarios:

Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation, update the table to to remove the participation status of deleted and to allow patient :

Existing Table:

-
-

Table A.1.2.6-3: PRT-11 Interpretation

-
@@ -614,9 +587,6 @@

Change Proposal Summary Informatio

Proposed Table:

-
-

Table A.1.2.6-3: PRT-11 Interpretation

-

@@ -643,16 +613,10 @@

Change Proposal Summary Informatio

- + - - - - - - - + + + +

C-Corrected

n/a

Corrected time that the device-patient association is asserted to have been established.

Corrected time that the device-patient association is asserted to have been established, if the correction is for a 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 device-patient association is confirmed to have been established. @@ -673,7 +637,96 @@

Change Proposal Summary Informatio

Section A.1.2.6 in PCIM TI - OBR - Observation Request, Table A.1.2.6-4 update to clarify interpretation of PRT-12 on deleted, corrected and wrong scenarios:

Section A.1.2.5 in PCIM TI - OBX - Observation, Table A.1.2.5-3 update to clarify correction reasons:

+
+

Existing Table:

+
+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StatusHL7 DescriptionAdaptation

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.

+ +
+
+

Proposed Table:

+
+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +
StatusHL7 DescriptionAdaptation

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. Corrections of start/end times and patient identity are allowed.

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.
@@ -743,10 +796,6 @@

Change Proposal Summary Informatio 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. @@ -762,7 +811,7 @@

Change Proposal Summary Informatio diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index d3d3ac6..7878657 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,7 +17,7 @@ |Draft |Date of last update: -|2025-03-20 +|2025-05-29 |Person Assigned: |Eldon Metz @@ -30,7 +30,7 @@ [cols="1,1"] |=== -2+^|*OBR-7/8 and PRT-11/12 semantics for DEV-51 and DEV-52 for corrected, deleted and wrong* +2+^|*Clarifying requirements and semantics for DEV-51 and DEV-52 for corrected, deleted and wrong message indicator* |Submitter’s Name(s) and e-mail address(es): |Eldon Metz, emetz@innovisionmedical.com @@ -50,11 +50,11 @@ Device-Patient Association Reporter |PCIM Profile TI (PCIM TI) revision 2.2, dated 2024-12-05 |Volume(s) and Section(s) affected: -|PCIM TI, Sections A.1.2.4 and A.1.2.6 +|PCIM TI, Sections A.1.2.4, A.1.2.5 and A.1.2.6 2+|Rationale for Change: -While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations wwere also identified to be clarified and/or updated. It was agreed on in the PCIM WG to clarify the requirements around interpretation of these fields in a CP. +While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to support corrections for patient identity changes for merges, unmerges, id changes and contact moves. It was agreed on in the PCIM WG to clarify the requirements around interpretation of these fields in a CP. This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issue. @@ -62,43 +62,20 @@ This Change Proposal (CP) proposes changes to PCIM TI to implement the profile c |=== -| _Section A.1.2.4 in PCIM TI - OBR - Observation Request_, update the text to clarify population of OBR-7/8 on deleted, corrected and wrong scenarios: - -|=== - -[.text-left] -[underline]#Existing Text:# - -[.text-left] -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. - -|=== - -|=== -[.text-left] -[underline]#Proposed Text:# - -[.text-left] -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. - -|=== - -| _Section A.1.2.6 in PCIM TI - OBR - Observation Request_, *Table A.1.2.6-3* update to clarify interpretation of PRT-11 on deleted, corrected and wrong scenarios: +| _Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation_, update the table to to remove the participation status of deleted and to allow patient : |=== [.text-left] [underline]#Existing Table:# -**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. +| Unusual. Time that the person in this role observed the person/device in the AUT role asserting the association. | C-Corrected @@ -128,9 +105,6 @@ If null, most recently asserted/corrected time has been confirmed. |=== [.text-left] [underline]#Proposed Table:# - -**Table A.1.2.6-3: PRT-11 Interpretation** - |=== | *Participation Status* | *AUT* | *EQUIP* | *RO* @@ -142,13 +116,9 @@ Time that the person in this role observed the person/device in the AUT role ass | C-Corrected | n/a -| Corrected time that the device-patient association is asserted to have been established. +| Corrected time that the device-patient association is asserted to have been established, if the correction is for a 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 @@ -161,10 +131,67 @@ If null, most recently asserted/corrected time has been confirmed. | n/a | Time that the person in this role declared the association to be erroneous. |=== +|=== + +| _Section A.1.2.5 in PCIM TI - OBX - Observation_, *Table A.1.2.5-3* update to clarify correction reasons: |=== -| _Section A.1.2.6 in PCIM TI - OBR - Observation Request_, *Table A.1.2.6-4* update to clarify interpretation of PRT-12 on deleted, corrected and wrong scenarios: +[.text-left] +[underline]#Existing Table:# + +|=== +| *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. +|=== + +|=== + +|=== +[.text-left] +[underline]#Proposed Table:# + +|=== +| *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. Corrections of start/end times and patient identity are allowed. + +| 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. |=== @@ -233,10 +260,6 @@ person/device in the AUT role asserting the disassociation.+++++++++++ ++++++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. From 8f5d390d7b473653011f0ae92532dbb9301eb312 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 29 May 2025 10:31:31 -0700 Subject: [PATCH 02/13] Update build.gradle to generate HTML for CP-DEV-018. --- .ci/asciidoc-converter/build.gradle | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.ci/asciidoc-converter/build.gradle b/.ci/asciidoc-converter/build.gradle index 975d899..d5463da 100644 --- a/.ci/asciidoc-converter/build.gradle +++ b/.ci/asciidoc-converter/build.gradle @@ -13,13 +13,13 @@ repositories { asciidoctor { sourceDir file('../../asciidoc') sources { - include 'IHE_DEV_Suppl_PCIM.adoc' - include 'IHE_DEV_Suppl_PCIM_Use_Cases.adoc' + include 'index.adoc' include 'cp-dev-016.adoc' include 'cp-dev-017.adoc' + include 'cp-dev-018.adoc' include 'cp-dev-019.adoc' - - include 'index.adoc' + include 'IHE_DEV_Suppl_PCIM.adoc' + include 'IHE_DEV_Suppl_PCIM_Use_Cases.adoc' } resources { from(sourceDir) { From 1f118be14e7c081d8681a606791208289133cfe9 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Tue, 23 Sep 2025 11:40:27 -0700 Subject: [PATCH 03/13] Add Jacob's use case #4 and example #5 to CP-DEV-018. --- asciidoc/cp-dev-018.adoc | 75 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 74 insertions(+), 1 deletion(-) diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 7878657..55126bd 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,7 +17,7 @@ |Draft |Date of last update: -|2025-05-29 +|2025-09-23 |Person Assigned: |Eldon Metz @@ -62,6 +62,79 @@ This Change Proposal (CP) proposes changes to PCIM TI to implement the profile c |=== +| _7.4.2 PCIM TI - Use Cases_, add use case #4 to help explain how correcting a patient identify for a merge can be handled: + +|=== + +[.text-left] +[underline]#Proposed Use Case:# + +[.text-left] +==== 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. + +|=== + +| _A.3 PCIM TI - Example Messages_, add example #5 to futher illustrate how correcting a patient identify for a merge can be handled: + +|=== + +[.text-left] +[underline]#Proposed Example:# + +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) +.... + +|=== + | _Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation_, update the table to to remove the participation status of deleted and to allow patient : |=== From 4d32014555f930ab0e5b24cefa1cca17fd3805c9 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Tue, 23 Sep 2025 11:47:10 -0700 Subject: [PATCH 04/13] Fix bullets in 7.4.2.4.1. --- asciidoc/cp-dev-018.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 55126bd..dc5cba5 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -77,6 +77,7 @@ This Change Proposal (CP) proposes changes to PCIM TI to implement the profile c 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 From ec488e94aa104dd2aac166685a856d83c406fd4c Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Mon, 29 Sep 2025 14:05:39 -0700 Subject: [PATCH 05/13] Expand DEV-51 semantics with correctable params tables, pulling from use case into message semantic sections. Add reference to MEMLS in 7.6. --- CPs/draft/cp-dev-018.html | 248 +++++++++++++++++++++++++++++++++++++- asciidoc/cp-dev-018.adoc | 102 ++++++++++++++-- 2 files changed, 340 insertions(+), 10 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index c2f55fd..f178388 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -464,7 +464,7 @@

Tracking Information

Date of last update:

-

2025-05-29

+

2025-09-29

Person Assigned:

@@ -525,6 +525,248 @@

Change Proposal Summary Informatio +

7.4.2 PCIM TI - Use Cases, add use case #4 to help explain how correcting a patient identify for a merge can be handled:

+ + + +
+

Proposed Use Case:

+
+
+

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(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.

+
+ +++ + + + + + +

7.6 PCIM TI - PCIM Cross Profile Considerations, add text after the ADT section that references the use of MEMLS for device and patient location tracking

+
+

Proposed Text:

+
+
+

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.

+
+ +++ + + + + + +

3.51.4.1.2 in PCIM TI - Message Semantics, update the first bullet to include considerations for patient identity corrections:

+
+

Existing Text:

+
+
+

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.

    +
    • +
+
+
+

Proposed Text:

+
+
+

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. Implementations should account for cases where the patient identity for an 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.

    +
    • +
+
+ +++ + + + + + +

3.51.4.1.2 in PCIM TI - Message Semantics, add another subsection, 3.51.4.1.3 Correction Semantics to specify the semantics of corrections:

+
+

Proposed Text:

+
+
+

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

+
+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterSemantics

Begin Time

Changes to the begin time of an active association shall trigger a correction.

Patient ID

Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43).

User ID (RO, AUT)

Changes to the user ID of the validating person 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

+
+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterSemantics

Begin Time

Changes to the begin time of an active association shall trigger a correction.

End Time

Changes to the end time of an active association shall trigger a correction.

Patient ID

Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43).

User ID (RO, AUT)

Changes to the user ID of the validating person may trigger a correction.

Location

Changes to the beginning or ending location of the association may trigger a correction.

+
+

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.

+
+ +++ + + + + + +

A.3 PCIM TI - Example Messages, add example #5 to futher illustrate how correcting a patient identify for a merge can be handled:

+
+

Proposed Example:

+
+
+

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)
+
+
+ +++ + + @@ -809,9 +1051,11 @@

Change Proposal Summary Informatio + + diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index dc5cba5..77b9016 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,7 +17,7 @@ |Draft |Date of last update: -|2025-09-23 +|2025-09-29 |Person Assigned: |Eldon Metz @@ -76,13 +76,6 @@ This Change Proposal (CP) proposes changes to PCIM TI to implement the profile c 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. @@ -97,6 +90,99 @@ Upon completion of this use case, the association record identifying the patient |=== +| _7.6 PCIM TI - PCIM Cross Profile Considerations_, add text after the ADT section that references the use of MEMLS for device and patient location tracking + +|=== + +[.text-left] +[underline]#Proposed Text:# + +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. + +|=== + +| _3.51.4.1.2 in PCIM TI - Message Semantics_, update the first bullet to include considerations for patient identity corrections: + +|=== + +[.text-left] +[underline]#Existing Text:# + +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. + +[.text-left] +[underline]#Proposed Text:# + +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. Implementations should account for cases where the patient identity for an 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. + +|=== + +| _3.51.4.1.2 in PCIM TI - Message Semantics_, add another subsection, 3.51.4.1.3 Correction Semantics to specify the semantics of corrections: + +|=== + +[.text-left] +[underline]#Proposed Text:# + +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 +|Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43). + +|User ID (RO, AUT) +|Changes to the user ID of the validating person 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 an active association shall trigger a correction. + +|End Time +|Changes to the end time of an active association shall trigger a correction. + +|Patient ID +|Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43). + +|User ID (RO, AUT) +|Changes to the user ID of the validating person may trigger a correction. + +|Location +|Changes to the beginning or ending location of the association may trigger a correction. + +|=== + +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. + +|=== + | _A.3 PCIM TI - Example Messages_, add example #5 to futher illustrate how correcting a patient identify for a merge can be handled: |=== From 3ebbde8e07bab37bad65440232438112c6af1663 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 2 Oct 2025 10:02:57 -0700 Subject: [PATCH 06/13] Apply changes from WG meeting on 10/2/2025. --- CPs/draft/cp-dev-018.html | 22 +++++++++++----------- asciidoc/cp-dev-018.adoc | 20 ++++++++++---------- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index f178388..193cb3c 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -525,7 +525,7 @@

Change Proposal Summary Informatio

- +

Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation, update the table to to remove the participation status of deleted and to allow patient :

7.4.2 PCIM TI - Use Cases, add use case #4 to help explain how correcting a patient identify for a merge can be handled:

7.4.2 PCIM TI - Use Cases, add use case #4 to help explain how correcting an existing verified association would work:
@@ -549,7 +549,7 @@
7.4.2.4.2 Process Flow
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.

+

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.

@@ -561,7 +561,7 @@
7.4.2.4.4 Main Flow
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.

+

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.

@@ -619,7 +619,7 @@
7.4.2.4.5 Post-conditions
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. Implementations should account for cases where the patient identity for an 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.

+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 of the patient identity to the Manager.

@@ -663,8 +663,8 @@
7.4.2.4.5 Post-conditions
- - + + @@ -689,19 +689,19 @@
7.4.2.4.5 Post-conditions
- + - + - - + + @@ -1055,7 +1055,7 @@
7.4.2.4.5 Post-conditions
diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 77b9016..dbb378b 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -62,7 +62,7 @@ This Change Proposal (CP) proposes changes to PCIM TI to implement the profile c |=== -| _7.4.2 PCIM TI - Use Cases_, add use case #4 to help explain how correcting a patient identify for a merge can be handled: +| _7.4.2 PCIM TI - Use Cases_, add use case #4 to help explain how correcting an existing verified association would work: |=== @@ -80,13 +80,13 @@ A Device-Patient Association Reporter asserts a correction to a verified device- 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. +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 and giving the up-to-date start time of the association is updated in the Device-Patient Association Manager. +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. |=== @@ -125,7 +125,7 @@ The significant content of the message is the following: 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. Implementations should account for cases where the patient identity for an 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. +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 of the patient identity to the Manager. |=== @@ -149,8 +149,8 @@ Corrections should be sent from the Device-Patient Association Reporter to the D |Patient ID |Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43). -|User ID (RO, AUT) -|Changes to the user ID of the validating person may trigger a correction. +|Participant (RO, AUT) +|Changes to a participant may trigger a correction. |Location |Changes to the beginning location of the association may trigger a correction. @@ -163,16 +163,16 @@ Corrections should be sent from the Device-Patient Association Reporter to the D |Parameter|Semantics |Begin Time -|Changes to the begin time of an active association shall trigger a correction. +|Changes to the begin time of a completed association shall trigger a correction. |End Time -|Changes to the end time of an active association shall trigger a correction. +|Changes to the end time of a completed association shall trigger a correction. |Patient ID |Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43). -|User ID (RO, AUT) -|Changes to the user ID of the validating person may trigger a correction. +|Participant (RO, AUT) +|Changes to a participant may trigger a correction. |Location |Changes to the beginning or ending location of the association may trigger a correction. From b337c1bed5e60afed715f665ed6de22c1160b05a Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Fri, 17 Oct 2025 06:42:03 -0700 Subject: [PATCH 07/13] Text refinements from 10/16/2025 WG discussion. --- asciidoc/cp-dev-018.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index dbb378b..7e35cf6 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -147,7 +147,7 @@ Corrections should be sent from the Device-Patient Association Reporter to the D |Changes to the begin time of an active association shall trigger a correction. |Patient ID -|Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43). +|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. @@ -169,7 +169,7 @@ Corrections should be sent from the Device-Patient Association Reporter to the D |Changes to the end time of a completed association shall trigger a correction. |Patient ID -|Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43). +|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. From b56997a290156cc713aafa588806ad95f697c7db Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Tue, 28 Oct 2025 12:43:36 -0700 Subject: [PATCH 08/13] Integrate initial proposal text and examples for "Wrong" associations. --- CPs/draft/cp-dev-018.html | 145 ++++++++++++++++++++++++++++++++++---- asciidoc/cp-dev-018.adoc | 96 +++++++++++++++++++++++-- 2 files changed, 221 insertions(+), 20 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index 193cb3c..d59e6f2 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -464,7 +464,7 @@

Tracking Information

 - + @@ -510,7 +510,7 @@

Change Proposal Summary Informatio

- + - + + + +

Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43).

User ID (RO, AUT)

Changes to the user ID of the validating person may trigger a correction.

Participant (RO, AUT)

Changes to a participant may trigger a correction.

Location

Begin Time

Changes to the begin time of an active association shall trigger a correction.

Changes to the begin time of a completed association shall trigger a correction.

End Time

Changes to the end time of an active association shall trigger a correction.

Changes to the end time of a completed association shall trigger a correction.

Patient ID

Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43).

User ID (RO, AUT)

Changes to the user ID of the validating person may trigger a correction.

Participant (RO, AUT)

Changes to a participant may trigger a correction.

Location

Date of last update:

2025-09-29

2025-10-28

Person Assigned:

Volume(s) and Section(s) affected:

PCIM TI, Sections A.1.2.4, A.1.2.5 and A.1.2.6

PCIM TI, Sections 7.4, 3.51, A.3 and A.1.2.5 and A.1.2.6

Rationale for Change:

@@ -629,7 +629,53 @@
7.4.2.4.5 Post-conditions

3.51.4.1.2 in PCIM TI - Message Semantics, add another subsection, 3.51.4.1.3 Correction Semantics to specify the semantics of corrections:

7.4.2 PCIM TI - Use Cases, add use case #5 to help explain how declaring a "wrong" association works:

+
+

Proposed Use Case:

+
+
+
+
+

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.3 in PCIM TI - Message Semantics, add another subsection, 3.51.4.1.3 Correction Semantics to specify the semantics of corrections:
@@ -660,7 +706,7 @@
7.4.2.4.5 Post-conditions

Patient ID

-

Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43).

+

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)

@@ -697,7 +743,7 @@
7.4.2.4.5 Post-conditions

Patient ID

-

Only changeable if human is semantically the same. Otherwise, it is a “Wrong” association and needs to be marked as such. This solves the real-world problem of patient merges ADT A40, ID change (e.g. EMPI deduplication ADT A47), unmerge (ADT A43).

+

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)

@@ -718,7 +764,29 @@
7.4.2.4.5 Post-conditions
-

A.3 PCIM TI - Example Messages, add example #5 to futher illustrate how correcting a patient identify for a merge can be handled:

+

3.51.4.1.4 in PCIM TI - Message Semantics, add another subsection, 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 #5 to illustrate how correcting a patient identify for a merge can be handled:
@@ -756,10 +824,11 @@
7.4.2.4.5 Post-conditions
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) +PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3004^1||20160726064500 +
+
+

(Acknowledgement messages not shown)

@@ -767,7 +836,57 @@
7.4.2.4.5 Post-conditions
- + + + +

Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation, update the table to to remove the participation status of deleted and to allow patient :

A.3 PCIM TI - Example Messages, add example #6 to illustrate declaring 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)

+
+ +++ + + +

Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation, update the table to to remove the participation status of deleted and to allow corrections and wrong declarations for the AUT role:
@@ -854,7 +973,7 @@
7.4.2.4.5 Post-conditions

C-Corrected

-

n/a

+

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 a association time change, otherwise the original time.

Time that the person in this role issued the correction.

@@ -867,7 +986,7 @@
7.4.2.4.5 Post-conditions

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.

@@ -1055,7 +1174,7 @@
7.4.2.4.5 Post-conditions
diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 7e35cf6..7d2bfa5 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,7 +17,7 @@ |Draft |Date of last update: -|2025-09-29 +|2025-10-28 |Person Assigned: |Eldon Metz @@ -50,7 +50,7 @@ Device-Patient Association Reporter |PCIM Profile TI (PCIM TI) revision 2.2, dated 2024-12-05 |Volume(s) and Section(s) affected: -|PCIM TI, Sections A.1.2.4, A.1.2.5 and A.1.2.6 +|PCIM TI, Sections 7.4, 3.51, A.3 and A.1.2.5 and A.1.2.6 2+|Rationale for Change: @@ -129,7 +129,34 @@ Note that any code identifiable with an individual patient must by secured from |=== -| _3.51.4.1.2 in PCIM TI - Message Semantics_, add another subsection, 3.51.4.1.3 Correction Semantics to specify the semantics of corrections: +| _7.4.2 PCIM TI - Use Cases_, add use case #5 to help explain how declaring a "wrong" association works: + +|=== + +[.text-left] +[underline]#Proposed Use Case:# + +[.text-left] + +==== 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.3 in PCIM TI - Message Semantics_, add another subsection, 3.51.4.1.3 Correction Semantics to specify the semantics of corrections: |=== @@ -183,7 +210,22 @@ The device identifier and the association unique instance identifier SHALL NOT b |=== -| _A.3 PCIM TI - Example Messages_, add example #5 to futher illustrate how correcting a patient identify for a merge can be handled: +| _3.51.4.1.4 in PCIM TI - Message Semantics_, add another subsection, 3.51.4.1.4 Wrong Semantics to specify the semantics of wrong associations: + +|=== + +[.text-left] +[underline]#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 #5 to illustrate how correcting a patient identify for a merge can be handled: |=== @@ -216,13 +258,53 @@ OBR|||15404649-0001|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||2016072606300 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) + +|=== + +| _A.3 PCIM TI - Example Messages_, add example #6 to illustrate declaring an association is wrong: + +|=== + +[.text-left] +[underline]#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) + |=== -| _Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation_, update the table to to remove the participation status of deleted and to allow patient : +| _Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation_, update the table to to remove the participation status of deleted and to allow corrections and wrong declarations for the AUT role: |=== @@ -275,7 +357,7 @@ If null, most recently asserted/corrected time has been confirmed. Time that the person in this role observed the person/device in the AUT role asserting the association. | C-Corrected -| n/a +| 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 a association time change, otherwise the original time. | Time that the person in this role issued the correction. @@ -287,7 +369,7 @@ 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. |=== From 5d98a61b09de405e3d871e00c36cb2ced4215509 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 30 Oct 2025 10:08:31 -0700 Subject: [PATCH 09/13] Edits applied during 10/30 WG session. --- CPs/draft/cp-dev-018.html | 22 ++++++++++++++++------ asciidoc/cp-dev-018.adoc | 16 +++++++++++----- 2 files changed, 27 insertions(+), 11 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index d59e6f2..490f8d9 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -854,7 +854,7 @@
7.4.2.5.5 Post-conditions
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
+OBR|||15404852|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726220000|20160726221500
 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
@@ -974,12 +974,12 @@
7.4.2.5.5 Post-conditions

C-Corrected

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 a association time change, otherwise the original time.

+

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.

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.

@@ -998,7 +998,7 @@
7.4.2.5.5 Post-conditions
-

Section A.1.2.5 in PCIM TI - OBX - Observation, Table A.1.2.5-3 update to clarify correction reasons:

+

Section A.1.2.5 in PCIM TI - OBX - Observation, Table A.1.2.5-3 update to remove "Deleted" status option:

@@ -1070,7 +1070,7 @@
7.4.2.5.5 Post-conditions

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. Corrections of start/end times and patient identity are allowed.

+

Record coming over is a correction and thus replaces a validated association.

F

@@ -1091,6 +1091,16 @@
7.4.2.5.5 Post-conditions
+ +++ + + + + + +

Section A.1.2.6 in PCIM TI - PRT — Participation (Observation Participation), Table A.1.2.6-4 update to remove "Deleted" status option:

Existing Table:

@@ -1174,7 +1184,7 @@
7.4.2.5.5 Post-conditions
diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 7d2bfa5..797dc87 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -279,7 +279,7 @@ At 22:00, Nurse Diesel connected patient Harrison to a continuous physiological 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 +OBR|||15404852|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726220000|20160726221500 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 @@ -358,12 +358,12 @@ Time that the person in this role observed the person/device in the AUT role ass | C-Corrected | 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 a association time change, otherwise the original time. +| 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. | 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. @@ -375,7 +375,7 @@ If null, most recently asserted/corrected time has been confirmed. |=== |=== -| _Section A.1.2.5 in PCIM TI - OBX - Observation_, *Table A.1.2.5-3* update to clarify correction reasons: +| _Section A.1.2.5 in PCIM TI - OBX - Observation_, *Table A.1.2.5-3* update to remove "Deleted" status option: |=== @@ -419,7 +419,7 @@ Can only be changed with a corrected association record. | 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. Corrections of start/end times and patient identity are allowed. +| Record coming over is a correction and thus replaces a validated association. | F | Final results; @@ -437,6 +437,12 @@ Can only be changed with a corrected association record. |=== +|=== + +| _Section A.1.2.6 in PCIM TI - PRT — Participation (Observation Participation)_, *Table A.1.2.6-4* update to remove "Deleted" status option: + +|=== + [.text-left] [underline]#Existing Table:# From 42268731971890a882f9b3bf6a6813b295701270 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 30 Oct 2025 10:23:45 -0700 Subject: [PATCH 10/13] Add Jacob to submitter/assignment. Re-order use case section. Update last update date. --- CPs/draft/cp-dev-018.html | 109 ++++++++++++++++++++------------------ asciidoc/cp-dev-018.adoc | 69 ++++++++++++------------ 2 files changed, 92 insertions(+), 86 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index 490f8d9..437346f 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -464,11 +464,11 @@

Tracking Information

Date of last update:

-

2025-10-28

+

2025-10-30

-

Person Assigned:

-

Eldon Metz

+

Person(s) Assigned:

+

Eldon Metz, Jacob Braschler

@@ -487,10 +487,13 @@

Change Proposal Summary Informatio

Clarifying requirements and semantics for DEV-51 and DEV-52 for corrected, deleted and wrong message indicator

-

Submitter’s Name(s) and e-mail address(es):

+

Submitter’s Name(s) and e-mail address(es):

Eldon Metz, emetz@innovisionmedical.com

+

Jacob Braschler, jbraschl@epic.com

+ +

Submission Date:

TBD

@@ -514,8 +517,8 @@

Change Proposal Summary Informatio

Rationale for Change:

-

While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to support corrections for patient identity changes for merges, unmerges, id changes and contact moves. It was agreed on in the PCIM WG to clarify the requirements around interpretation of these fields in a CP.

-

This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issue.

+

While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to add text for corrections for not only time but also for patient identity changes for merges, unmerges, id changes and contact moves. It was also oted that it was necessary to add text for handling of wrong associations. Additional use cases and examples were added to more clearly explain both how to correct associations and declare them as wrong.

+

This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issues.

@@ -569,6 +572,52 @@

7.4.2.4.5 Post-conditions
+

7.4.2 PCIM TI - Use Cases, add use case #5 to help explain how declaring a "wrong" association works:

+ + + +
+

Proposed Use Case:

+
+ + +
+

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.

+
+ +++ + + @@ -629,52 +678,6 @@
7.4.2.4.5 Post-conditions
- - - -

7.6 PCIM TI - PCIM Cross Profile Considerations, add text after the ADT section that references the use of MEMLS for device and patient location tracking

7.4.2 PCIM TI - Use Cases, add use case #5 to help explain how declaring a "wrong" association works:

-
-

Proposed Use Case:

-
-
-
-
-

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.

-
- --- - - @@ -1184,7 +1187,7 @@
7.4.2.5.5 Post-conditions
diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 797dc87..1941d70 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,10 +17,10 @@ |Draft |Date of last update: -|2025-10-28 +|2025-10-30 -|Person Assigned: -|Eldon Metz +|Person(s) Assigned: +|Eldon Metz, Jacob Braschler |=== @@ -32,8 +32,9 @@ 2+^|*Clarifying requirements and semantics for DEV-51 and DEV-52 for corrected, deleted and wrong message indicator* -|Submitter’s Name(s) and e-mail address(es): -|Eldon Metz, emetz@innovisionmedical.com +.2+|Submitter’s Name(s) and e-mail address(es): +|Eldon Metz, emetz@innovisionmedical.com +|Jacob Braschler, jbraschl@epic.com |Submission Date: | TBD @@ -54,9 +55,9 @@ Device-Patient Association Reporter 2+|Rationale for Change: -While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to support corrections for patient identity changes for merges, unmerges, id changes and contact moves. It was agreed on in the PCIM WG to clarify the requirements around interpretation of these fields in a CP. +While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to add text for corrections for not only time but also for patient identity changes for merges, unmerges, id changes and contact moves. It was also oted that it was necessary to add text for handling of wrong associations. Additional use cases and examples were added to more clearly explain both how to correct associations and declare them as wrong. -This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issue. +This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issues. |=== @@ -88,6 +89,34 @@ The Device-Patient Association Reporter originates a message with the specific i ===== 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 PCIM TI - Use Cases_, add use case #5 to help explain how declaring a "wrong" association works: + +|=== + +[.text-left] +[underline]#Proposed Use Case:# + +[.text-left] + +==== 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. + + |=== | _7.6 PCIM TI - PCIM Cross Profile Considerations_, add text after the ADT section that references the use of MEMLS for device and patient location tracking @@ -127,32 +156,6 @@ 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. 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 of the patient identity to the Manager. -|=== - -| _7.4.2 PCIM TI - Use Cases_, add use case #5 to help explain how declaring a "wrong" association works: - -|=== - -[.text-left] -[underline]#Proposed Use Case:# - -[.text-left] - -==== 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. |=== From fd2cb68be284e0a7781eac4932baeb4d0ce8fdc7 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 13 Nov 2025 10:03:51 -0800 Subject: [PATCH 11/13] Updates on Wrong text during WG discussion on 11/13. --- CPs/draft/cp-dev-018.html | 6 +++--- asciidoc/cp-dev-018.adoc | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index 437346f..4ee806c 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -464,7 +464,7 @@

Tracking Information

 - + @@ -778,7 +778,7 @@
7.4.2.5.5 Post-conditions

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.

+

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. 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. To correct a "Wrong" association, a new association 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.

@@ -1187,7 +1187,7 @@
7.4.2.5.5 Post-conditions
diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 1941d70..9f96d92 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,7 +17,7 @@ |Draft |Date of last update: -|2025-10-30 +|2025-11-13 |Person(s) Assigned: |Eldon Metz, Jacob Braschler @@ -222,7 +222,7 @@ The device identifier and the association unique instance identifier SHALL NOT b 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. +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. 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. To correct a "Wrong" association, a new association 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. From 3c3b7de809fb4357b0df4f24764f0a2bc4a84df0 Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 4 Dec 2025 09:33:26 -0800 Subject: [PATCH 12/13] Add "Wrong Semantics" sections for DEV-[51,52]. --- asciidoc/cp-dev-018.adoc | 40 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 36 insertions(+), 4 deletions(-) diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index 9f96d92..eb3a1f1 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,7 +17,7 @@ |Draft |Date of last update: -|2025-11-13 +|2025-12-04 |Person(s) Assigned: |Eldon Metz, Jacob Braschler @@ -51,7 +51,7 @@ Device-Patient Association Reporter |PCIM Profile TI (PCIM TI) revision 2.2, dated 2024-12-05 |Volume(s) and Section(s) affected: -|PCIM TI, Sections 7.4, 3.51, A.3 and A.1.2.5 and A.1.2.6 +|PCIM TI, Sections 7.4, 3.51, 3.52, A.3 and A.1.2.5 and A.1.2.6 2+|Rationale for Change: @@ -221,11 +221,43 @@ The device identifier and the association unique instance identifier SHALL NOT b [underline]#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. 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. To correct a "Wrong" association, a new association may be asserted after the Wrong has been reported. +To correct a "Wrong" association, a new association 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. +|=== + +| _3.52.4.1.2 in PCIM TI - Message Semantics_, add subsection header 3.52.4.1.2 Message Semantics right before the sentence "The signicant content of the message is the following" in section 3.52.4.1.1: + +|=== + + +|=== + +| _3.52.4.1.3 in PCIM TI - Message Semantics_, add subsection 3.52.4.1.3 Correction Semantics to specify the semantics of correctable associations: + +|=== + +[.text-left] +[underline]#Proposed Text:# + + +Correction reports must be sent from the Device-Patient Association Manager to Device-Patient Association Consumers when they are reported. 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 in PCIM TI - Message Semantics_, add subsection 3.51.4.1.4 Wrong Semantics to specify the semantics of wrong associations: + +|=== + +[.text-left] +[underline]#Proposed Text:# + +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. + + |=== | _A.3 PCIM TI - Example Messages_, add example #5 to illustrate how correcting a patient identify for a merge can be handled: From f7ae2bd0f1165418184604b6b599d3f491386b2d Mon Sep 17 00:00:00 2001 From: Eldon Metz Date: Thu, 11 Dec 2025 10:07:37 -0800 Subject: [PATCH 13/13] Corrected and wrong semantics, preconditions/mainflow text updates. Edits made during WG session. --- CPs/draft/cp-dev-018.html | 65 ++++++++++++++++++++++++++++++++------- asciidoc/cp-dev-018.adoc | 18 +++++------ 2 files changed, 63 insertions(+), 20 deletions(-) diff --git a/CPs/draft/cp-dev-018.html b/CPs/draft/cp-dev-018.html index 4ee806c..c2183f9 100644 --- a/CPs/draft/cp-dev-018.html +++ b/CPs/draft/cp-dev-018.html @@ -464,7 +464,7 @@

Tracking Information

 - + @@ -513,11 +513,11 @@

Change Proposal Summary Informatio

- + @@ -598,13 +598,13 @@
7.4.2.5.2 Process Flow
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.

+

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, including the association unique instance identifier in OBR-29.2 that was sent in OBR-3 of the initial message that asserted the association.

+

The Device-Patient Association Reporter originates a message with the specific information on the wrong association.

@@ -668,7 +668,7 @@
7.4.2.5.5 Post-conditions
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. 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 of the patient identity to the Manager.

+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.

@@ -775,13 +775,56 @@
7.4.2.5.5 Post-conditions

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.

+

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.

-

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. 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. To correct a "Wrong" association, a new association 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.

+
+

3.51.4.1.3 in PCIM TI - Message Semantics, add another subsection, 3.51.4.1.3 Correction Semantics to specify the semantics of corrections:

Date of last update:

2025-10-30

2025-11-13

Person(s) Assigned:

Date of last update:

2025-11-13

2025-12-11

Person(s) Assigned:

Volume(s) and Section(s) affected:

PCIM TI, Sections 7.4, 3.51, A.3 and A.1.2.5 and A.1.2.6

PCIM TI, Sections 7.4, 3.51, 3.52, A.3 and A.1.2.5 and A.1.2.6

Rationale for Change:

-

While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to add text for corrections for not only time but also for patient identity changes for merges, unmerges, id changes and contact moves. It was also oted that it was necessary to add text for handling of wrong associations. Additional use cases and examples were added to more clearly explain both how to correct associations and declare them as wrong.

+

While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to add text for corrections for not only time but also for patient identity changes for merges, unmerges, id changes and contact moves. It was also noted that it was necessary to add text for handling of wrong associations. Additional use cases and examples were added to more clearly explain both how to correct associations and declare them as wrong.

This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issues.
+++ + + + + + +

3.52.4.1.2 in PCIM TI - Message Semantics, add subsection header 3.52.4.1.2 Message Semantics right before the sentence "The significant content of the message is the following" in section 3.52.4.1.1:

+ +++ + + + + + +

3.52.4.1.3 in PCIM TI - Message Semantics, add subsection 3.52.4.1.3 Correction Semantics to specify the semantics of correctable associations:

+
+

Proposed Text:

-

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.

+

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 in PCIM TI - Message Semantics, add subsection 3.51.4.1.4 Wrong Semantics to specify the semantics of wrong associations:

+
+

Proposed Text:

+
+
+

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.

@@ -889,7 +932,7 @@
7.4.2.5.5 Post-conditions
- +

Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation, update the table to to remove the participation status of deleted and to allow corrections and wrong declarations for the AUT role:

Table A.1.2.6-3 in PCIM TI - PRT-11 Interpretation, update the table to to remove the participation status of deleted and to allow corrections and wrong declarations for the AUT role:
@@ -1187,7 +1230,7 @@
7.4.2.5.5 Post-conditions
diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/cp-dev-018.adoc index eb3a1f1..e76f76a 100644 --- a/asciidoc/cp-dev-018.adoc +++ b/asciidoc/cp-dev-018.adoc @@ -17,7 +17,7 @@ |Draft |Date of last update: -|2025-12-04 +|2025-12-11 |Person(s) Assigned: |Eldon Metz, Jacob Braschler @@ -55,7 +55,7 @@ Device-Patient Association Reporter 2+|Rationale for Change: -While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to add text for corrections for not only time but also for patient identity changes for merges, unmerges, id changes and contact moves. It was also oted that it was necessary to add text for handling of wrong associations. Additional use cases and examples were added to more clearly explain both how to correct associations and declare them as wrong. +While anticipating production deployment and during analsysis of edge cases, it was noted that it was unclear what OBR-7/8 should be for deleted, corrected and wrong scenarios in DEV-51 (Communicate Association State) and DEV-52 (Report Association State) transactions. While reviewing this, PRT-11/12 interpretations were also identified to be clarified and/or updated. It was also noted that it was necessary to add text for corrections for not only time but also for patient identity changes for merges, unmerges, id changes and contact moves. It was also noted that it was necessary to add text for handling of wrong associations. Additional use cases and examples were added to more clearly explain both how to correct associations and declare them as wrong. This Change Proposal (CP) proposes changes to PCIM TI to implement the profile clarifications and positions for the above issues. @@ -108,10 +108,10 @@ A Device-Patient Association Reporter asserts that a previously-reported device- 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. +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, including the association unique instance identifier in OBR-29.2 that was sent in OBR-3 of the initial message that asserted the association. +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. @@ -154,7 +154,7 @@ The significant content of the message is the following: 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. 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 of the patient identity to the Manager. +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. |=== @@ -221,13 +221,13 @@ The device identifier and the association unique instance identifier SHALL NOT b [underline]#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. -To correct a "Wrong" association, a new association may be asserted after the Wrong has been reported. +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. |=== -| _3.52.4.1.2 in PCIM TI - Message Semantics_, add subsection header 3.52.4.1.2 Message Semantics right before the sentence "The signicant content of the message is the following" in section 3.52.4.1.1: +| _3.52.4.1.2 in PCIM TI - Message Semantics_, add subsection header 3.52.4.1.2 Message Semantics right before the sentence "The significant content of the message is the following" in section 3.52.4.1.1: |=== @@ -242,7 +242,7 @@ Note that there are chart correction use cases where the Device-Patient Associat [underline]#Proposed Text:# -Correction reports must be sent from the Device-Patient Association Manager to Device-Patient Association Consumers when they are reported. 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. +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. |=== @@ -339,7 +339,7 @@ PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3002^1||20160726222000 |=== -| _Table A.1.2.6.3 in PCIM TI - PRT-11 Interpretation_, update the table to to remove the participation status of deleted and to allow corrections and wrong declarations for the AUT role: +| _Table A.1.2.6-3 in PCIM TI - PRT-11 Interpretation_, update the table to to remove the participation status of deleted and to allow corrections and wrong declarations for the AUT role: |===