-
Notifications
You must be signed in to change notification settings - Fork 0
CP-DEV-018 #118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
CP-DEV-018 #118
Conversation
jbraschler
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As previously discussed, I'd like to suggest the following additions to clarify corrections use cases as part of this CP:
In 7.4.2 Use Cases:
7.4.2.4 Use Case #4 Correcting Verified Associations
7.4.2.4.1 Description
A Device-Patient Association Reporter asserts a correction to a verified device-patient association to a Device-Patient Association Manager.
An action is taken in the Device-Patient Association Reporter's system that corrects one of the key parameters of an existing verified device-patient association. The following key parameters SHALL trigger a correction if changed during the course of an active device association:
β’ Effective begin time of the association
β’ Effective end time of the association
Other parameters of the verified device-patient association MAY trigger correction based on the requirements of the specific implementation. For example, if chart correction actions can be taken in the Device-Patient Association Reporter system that change the patient's unique identifier while the patient has an active device-patient association, AND that change is not being communicated to the Device-Patient Association Manager using other means, such as an HL7 ADT message, a correction message will communicate the correction to the patient's identifying information.
7.4.2.4.2 Process Flow
This use case is driven by an authorized user taking an action that alters one of the key parameters of an existing verified device-patient association. This should be based on first-person awareness of the situation at the point-of-care. For example, if a device-patient association is created and verified for a patient retroactively and the effective begin time of the association isn't back-dated appropriately, an authorized user may manually alter the begin time of the association, which should trigger a correction. This can also be a result of other system actions. For example, if a device-patient association was initiated for a device with a fixed location upon transferring the patient into the associated bed, and the effective time of the transfer is changed, a correction should be sent to update the effective begin time of the association.
7.4.2.4.3 Pre-conditions
An existing verified device-patient association is to be corrected. The patient has been assigned a unique identifier at registration which has been collected and verified at the point-of-care. Device identity has been registered for use. The identities of the patient and device(s) have been collected and verified by an authorized person. The patient has already been associated with a device.
7.4.2.4.4 Main Flow
The Device-Patient Association Reporter originates a message with the specific information on the association, including the parameters that were corrected.
7.4.2.4.5 Post-conditions
Upon completion of this use case, the association record identifying the patient and the associated device and giving the up-to-date start time of the association is updated in the Device-Patient Association Manager.
In A.3 Example Messages:
Example 5:
Patient record Trauma, Unknown represents a patient of unknown identity who is admitted to the ICU after a vehicle accident. At 06:30, Nurse Diesel connected the patient to a continuous physiological monitor with ID MON6789. At 06:45, she records the association on the Critical Care application. As she is an RN and has witnessed and entered the association in the Critical Care system, this is considered a validated association.
MSH|^~&|CritCare||AssocMgr||20160726064502||ORU^R01^ORU_R01|94e03d4|P|2.6|||AL|AL|USA||||IHE_DEV_051^IHE PCD^1.3.6.1.4.1.19376.1.6.1.51.1^ISO
PID|||AB60005^^^A^PI||TRAUMA^UNKNOWN^^^^^L
PV1||E|3 WEST ICU^3004^1
OBR|||15404649|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726063000|20160726064500
OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC||||||F
PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 West ICU^3004^1|MON6789^^231A8456B1CB2484^EUI-64|20160726063000
PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3004^1||20160726064500
(Acknowledgement messages not shown)
At 08:00, the patient's identity has been ascertained to be patient Benjamin Davis, who has an existing record in the Critical Care system. Working with Health Information Management, it is determined to be safe to merge the temporary trauma record with the patient's existing permanent patient record. The merge is performed in the Critical Care system, and a correction for the verified association is sent to the device manager containing the updated patient information in PID. A unique identifier for the correction event is sent in OBR-3, and the association identifier that was sent in OBR-3 for the original association message is sent in OBR-29.2. Additionally, the observation status in OBX-11 is sent as "C" to indicate the event is a correction to a verified association.
MSH|^~&|CritCare||AssocMgr||20160726082502||ORU^R01^ORU_R01|94e05d9|P|2.6|||AL|AL|USA||||IHE_DEV_051^IHE PCD^1.3.6.1.4.1.19376.1.6.1.51.1^ISO
PID|||AB40001^^^A^PI||DAVIS^BENJAMIN^C^^^^L
PV1||E|3 WEST ICU^3004^1
OBR|||15404649-0001|69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC|||20160726063000|20160726064500|||||||||||||||||||||^15404649
OBX|1|CWE|68487^MDC_ATTR_EVT_COND^MDC||198332^MDC_EVT_ASSOCIATION_PATIENT_DEVICE^MDC||||||C
PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 West ICU^3004^1|MON6789^^231A8456B1CB2484^EUI-64|20160726063000
PRT|2|UC||AUT^AUT^HL70912|58793^Diesel^N||||3 WEST ICU^3004^1||20160726064500
(Acknowledgement messages not shown)
|
Noting some options here for where to add additional language around the use of additional profiles (e.g., PAM/ADT, PDQm/FHIR, etc.) for managing patient identity between a Device Association Reporter and Device Association Manager. In Section 7.6 PCIM Cross Profile Considerations In Section 3.51.4.1.2 Message Semantics |
β¦use case into message semantic sections. Add reference to MEMLS in 7.6.
|
Proposed updates for "Wrong" associations in CP-DEV-018: 7.4.2 Use Cases, add an additional use case subsection, 7.4.2.5 Wrong Associations: Proposed Text: 7.4.2.5 Use Case #5 Wrong Associations 7.4.2.5.2 Process Flow 7.4.2.5.3 Pre-Conditions 7.4.2.5.4 Main Flow 7.4.2.5.5 Post-conditions 3.51.4.1.2 PCIM TI - Message Semantics, add another sub-section, 3.51.4.1.4 Wrong Semantics to specify the semantics of wrong associations: Proposed Text: An existing device-patient association should be asserted as "Wrong" from the Device-Patient Association Reporter to the Device-Patient Association Manager whenever either the device or the patient that was reported with the association was wrong. All messages asserting an existing device-patient association as wrong shall reference the association unique instance identifier in OBR-29.2 that was sent in OBR-3 of the original message that asserted the association. When a device-patient association is asserted to be "Wrong", any device data that was reported for that device-patient association should also be deleted or flagged for review in any consumers that are using the device-patient association to file received device data to the patient. Note that there are chart correction use cases where the Device-Patient Association Reporter's understanding of the identity of the patient changes but the human who is associated to the device is semantically the same (such as with a patient merge). In these cases, the patient identity change may be handled either by correcting the patient identity for the existing association as described in section 3.51.4.1.3 above or by marking the existing association as wrong and re-asserting the association. The new assertion shall have a new association unique instance identifier in OBR-3 and includes the corrected patient identity. A.3 PCIM TI - Example Messages, add example #6 to illustrate asserting an association is wrong: Proposed Example: Example 6: 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 (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 (Acknowledgement messages not shown) |
Re-order use case section. Update last update date.
Edits made during WG session.
Closes # 110,117
π Description
Update TI based on feedback for corrections and deletion capabilities.
β Checks
βΉ Additional Information