diff --git a/CPs/cp_nn6.adoc b/CPs/cp_nn6.adoc index 9377abc..6518b40 100644 --- a/CPs/cp_nn6.adoc +++ b/CPs/cp_nn6.adoc @@ -29,7 +29,7 @@ [cols="1,1"] |=== -2+^|PCIM Foundational Changes +2+^|*PCIM Foundational Changes* |Submitter’s Name(s) and e-mail address(es): |Eldon Metz, emetz@innovisionmedical.com @@ -67,12 +67,13 @@ This Change Proposal (CP) proposes changes to implement profile clarifications a |=== -[.text-left] - -=== *1 Section Appendix A – Actor Summary Definitions*, _modify the definitions in the table on line 213 as shown below and also adding the acroynm text in the name column and a new OID column._: +|=== +| _Section Appendix A_ *Actor Summary Definitions*, _modify the definitions in the table on line 213 as shown below and also adding the acroynm text in the name column and a new OID column_: -==== [underline]#Existing Table:# +|=== +[.text-left] +[underline]#Existing Table:# [cols="1,1"] |=== @@ -91,8 +92,8 @@ This Change Proposal (CP) proposes changes to implement profile clarifications a |A system (including the device itself) or person that, when the device is setup for use by a Device-Patient Association Manager, uniquely identifies a device instance that may participate in device-patient associations. |=== - -==== [underline]#Proposed Table:# +[.text-left] +[underline]#Proposed Table:# [cols="1,1,1"] |=== @@ -112,10 +113,13 @@ This Change Proposal (CP) proposes changes to implement profile clarifications a |=== -=== *2 Section Appendix B – Transaction Summary Definitions*, _modify the table on line 218 to update the transcation names, definitions and numbers_: +|=== + +|_Section Appendix B_ *Transaction Summary Definitions*, _modify the table on line 218 to update the transcation names, definitions and numbers_: +|=== [.text-left] -==== [underline]#Existing Table:# +[underline]#Existing Table:# [cols="1,1"] |=== @@ -135,7 +139,7 @@ This Change Proposal (CP) proposes changes to implement profile clarifications a |=== [.text-left] -==== [underline]#Proposed Table:# +[underline]#Proposed Table:# [cols="1,1,1"] |=== @@ -158,22 +162,30 @@ This Change Proposal (CP) proposes changes to implement profile clarifications a |=== -=== *3 PCIM Actors, Transactions, and Content Modules*, _replace Figure 7.1-1 on page 13 with updated actor name, number and definitions_: +|=== + +|*PCIM Actors, Transactions, and Content Modules*, _replace Figure 7.1-1 on page 13 with updated actor name, number and definitions_: + +|=== [.text-left] -==== [underline]#Existing Figure:# +[underline]#Existing Figure:# image::original-actor-transaction-diagram.png[] [.text-left] -==== [underline]#Proposed Figure:# +[underline]#Proposed Figure:# image::proposed-actor-transaction-diagram.png[] -=== *4 PCIM Actors, Transactions, and Content Modules*, _replace Table 7.1-1 PCIM Profile – Actors and Transactions on page 14 with updated actor names, transactions and optionality value_: +|=== + +|*PCIM Actors, Transactions, and Content Modules*, _replace Table 7.1-1 PCIM Profile – Actors and Transactions on page 14 with updated actor names, transactions and optionality value_: + +|=== [big red yellow-background]*WIP* [.text-left] -==== [underline]#Original Table:# +[underline]#Original Table:# [cols="1,1,1,1,1"] |=== @@ -181,82 +193,128 @@ image::proposed-actor-transaction-diagram.png[] |=== [.text-left] -==== [underline]#Proposed Table:# +[underline]#Proposed Table:# [cols="1,1,1,1"] |=== |Actors|Transactions|Initiator or Responder|Optionality|Reference +|=== |=== -[.text-left] -=== *5 Section 7.1.1.1 Device-Patient Association Reporter*, _change the paragraph on line 270_: +|_Section 7.1.1.1_ *Device-Patient Association Reporter*, _change the paragraph on line 270_: + +|=== -==== [underline]#Existing Text:# +[underline]#Existing Text:# + +[.text-left] The Device-Patient Association Reporter represents a system or person that is asserts that a given device is attached or removed from a specific patient. For each such event, the unique Patient ID, Device ID, and timestamp must be reported. -==== [underline]#Proposed Text:# -The Device-Patient Association Reporter represents a system that asserts that a given device is associated or disassociated with a specific patient. For each such event, the unique Patient ID, Device ID, and timestamp of the beginning of association or end of association shall be reported. If a location is known, it should be included in the report. If the report is validated, the report observation shall be marked final, otherwise it shall be marked as requiring validation. +[underline]#Proposed Text:# [.text-left] -=== *6 Section 7.1.1.2 Device-Patient Association Manager*, _change the paragraph on line 274_: +The Device-Patient Association Reporter represents a system that asserts that a given device is associated or disassociated with a specific patient. For each such event, the unique Patient ID, Device ID, and timestamp of the beginning of association or end of association shall be reported. If a location is known, it should be included in the report. If the report is validated, the report observation shall be marked final, otherwise it shall be marked as requiring validation. + +|=== -==== [underline]#Existing Text:# +|_Section 7.1.1.2_ *Device-Patient Association Manager*, _change the paragraph on line 274_: + +|=== + +[underline]#Existing Text:# + +[.text-left] The Device-Patient Association Manager represents a system that collects and persists information on what devices are currently or were connected to patients within a defined scope, such as a clinical unit, at a given time, and can communicate these associations as query responses, event notifications, or both. -==== [underline]#Proposed Text:# -The Device-Patient Association Manager represents a system that collects and persists -information on devices currently associated with patients within a defined scope, such as a clinical unit and shall communicate validated associations as query responses, event notifications, or both if requested. The system is responsible for resolving conflicts and shall provide an HMI for validating association assertions that require validation and resolving conflicts. [big red yellow-background]*Add an out-of-scope statement that describes the possibility of an actor that provides retrospective capabilities and why that makes sense)* +[underline]#Proposed Text:# [.text-left] -=== *7 Section 7.1.1.3 Device-Patient Association Consumer*, _change the paragraph on line 279_: +The Device-Patient Association Manager represents a system that collects and persists information on devices currently associated with patients within a defined scope, such as a clinical unit and shall communicate validated associations as query responses, event notifications, or both if requested. The system is responsible for resolving conflicts and shall provide an HMI for validating association assertions that require validation and resolving conflicts. [big red yellow-background]*Add an out-of-scope statement that describes the possibility of an actor that provides retrospective capabilities and why that makes sense)* -==== [underline]#Existing Text:# +|=== + +|_Section 7.1.1.3_ *Device-Patient Association Consumer*, _change the paragraph on line 279_: + +|=== + +[underline]#Existing Text:# + +[.text-left] The Device-Patient Association Consumer represents a system or person that is has a requirement to receive information on what devices are or were connected to which patients. A common example is a critical care system that charts device observations for a patient. -==== [underline]#Proposed Text:# +[underline]#Proposed Text:# + +[.text-left] The Device-Patient Association Consumer represents a system that needs to receive information on what devices are associated with which patients. Common examples are a medical device or critical care system that charts device observations for a patient. The system may receive association updates in real-time, if desired. [big red yellow-background]*Do we need to add text to capture multiple devices attached to a patient through other devices, e.g. Physio Mon with a EtCO2, Ventilator connection* +|=== + +|_Section 7.1.1.4_ *Device-Registrant*, _delete the paragraph on line 283_ or change to reference MEMDMC?: + +|=== + [.text-left] -=== *8 Section 7.1.1.4 Device-Registrant*, _delete the paragraph on line 283_ or change to reference MEMDMC?: +[underline]#Existing Text:# -==== [underline]#Existing Text:# +[.text-left] The Device Registrant represents a system or person that maintains the list of medical devices that can be connected to a patient. The list entry for each device typically includes the device type, location (may not apply if the device is mobile), and unique identity. -==== [underline]#Proposed Text:# +[underline]#Proposed Text:# + +[.text-left] [big red yellow-background]*The MEMDMC DMIR is an actor that enables automated contributions to the list of medical devices that can be associated with a patient. The list entry for each device typically includes the device type, location (may not apply if the device is mobile), model, manufacturer and unique identity.* +|=== + +|_Section 7.1.1.4_ *Device-Registrant*, delete the two paragraphs starting at line 287 and tie them into an MEMDMC reference_: + +|=== + [.text-left] -=== *9 Section 7.1.1.4 Device-Registrant*, delete the two paragraphs starting at line 287 and tie them into an MEMDMC reference: +[underline]#Existing Text:# -==== [underline]#Existing Text:# +[.text-left] Where this is a person, it is most likely hospital staff that is interacting directly with the Device- Patient Association Manager through its user interface. Where it is a system, it may be a comprehensive device inventory system, a “gateway” system, or even the device itself. - -==== [underline]#Proposed Text:# +[.text-left] +[underline]#Proposed Text:# + [big red yellow-background]*The MEMDMC DMIR may automated device registration. The DMIR may be a “gateway” system or medical device itself.* +|=== + +|*PCIM Actor Options*, change the first two paragraphs starting at line 293 to address the change in optionality and options: + +|=== + [.text-left] -=== *10 PCIM Actor Options*, change the first two paragraphs starting at line 293 to address the change in optionality and options: +[underline]#Existing Text:# -==== [underline]#Existing Text:# +[.text-left] The Device-Patient Association Consumer has two options available for receiving data from the Device-Patient Association Manager. The first option is to query the Manager for a snapshot of current associations, either by sending a patient identifier and receiving back the associated device(s) or by sending a device identifier and receiving back the associated patient. The second option is to receive an unsolicited continuous stream of association and disassociation events from the Manager as they occur. The Device-Patient Association Manager should support sending data via both methods, and the Device-Patient Association Consumer may support one or both methods. Options that may be selected for each actor in this profile, if any, are listed in the Table 7.2-1. Dependencies between options, when applicable, are specified in notes. -==== [underline]#Proposed Text:# +[.text-left] +[underline]#Proposed Text:# + +[.text-left] The Device-Patient Association Consumer may optionally query the Device-Patient Association Manager for configuration and filtering of patient association status in real-time. The query to the Manager results in an immediate delivery from the manager of the active associations based on the query filter criteria. The Consumer then receives an unsolicited continuous stream of association and disassociation events. The Device-Patient Association Manager may support the query option. Options that may be selected for each actor in this profile, if any, are listed in the Table 7.2-1. Dependencies between options, when applicable, are specified in notes. -[.text-left] -=== *11 PCIM Actor and Options*, change the table near line 303: +|=== + +|*PCIM Actor and Options*, _change the table near line 303_: + +|=== [.text-left] -==== [underline]#Existing Table:# +[underline]#Existing Table:# [cols="1,1,1"] |=== @@ -288,7 +346,7 @@ Options that may be selected for each actor in this profile, if any, are listed |=== [.text-left] -==== [underline]#Proposed Table:# +[underline]#Proposed Table:# [cols="1,1,1"] |=== @@ -308,17 +366,27 @@ Options that may be selected for each actor in this profile, if any, are listed |=== -[.text-left] -=== *12 Snapshot Option*, move and alter text to address change in quey approach and option status in section 3.19, addressed later in this CP: +|=== -[.text-left] -=== *13 Subscription Option*, re-number to 7.2.1 and update to reflect query option changes: +|*Snapshot Option*, _move and alter text to address change in quey approach and option status in section 3.19, addressed later in this CP_: -==== [underline]#Existing Text:# +|=== + +|=== + +|*Subscription Option*, _re-number to 7.2.1 and update to reflect query option changes_: + +|=== + +[.text-left] +[underline]#Existing Text:# +[.text-left] The snapshot option applies to query and response interactions between Device-Patient Association Consumer and Device-Patient Association Manager and specifies that the query response desired is a continuing subscription to changes in device-patient associations. A Device-Patient Association Consumer that supports this option shall formulate its request in the form described in Section 3.19. -==== [underline]#Proposed Text:# +[.text-left] +[underline]#Proposed Text:# +[.text-left] The query option applies to query and response interactions between Device-Patient Association Consumer and Device-Patient Association Manager and specifies that the query response desired is a filtered real-time delivery of changes in device-patient associations. A Device-Patient Association Consumer that supports this option shall formulate its request in the form described in Section 3.19. diff --git a/CPs/html/cp_nn4.html b/CPs/html/cp_nn4.html index 8acda88..e059938 100644 --- a/CPs/html/cp_nn4.html +++ b/CPs/html/cp_nn4.html @@ -487,7 +487,7 @@

Change Proposal Summary Informatio -

PCIM Device-Patient Association Manager Error Responses

+

PCIM Device-Patient Association Manager Error Responses

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

@@ -521,13 +521,226 @@

Change Proposal Summary Informatio + +++ + + + + + +

Section 3.17.4.1.2 Message Semantics Add the following new section after this section on page 24:

+
+

Section 3.17.4.2 Device-Patient Association Acknowledgment

+
+
+

The Device-Patient Association Manager validates the message and responds with a commit level acknowledgment message (ACK^R01^ACK). If an error condition is detected and if MSH-16 (Application Acknowledgement Type) in the ORU^R01^ORU_R01 message is valued as "ER" or "AL", the Device-Patient Association Manager responds with an application acknowledgment message (ACK^R01^ACK).

+
+
+

If the message is accepted by the Device-Patient Association Manager, the commit acknowledgment will contain the value CA in MSA-1. If not, the commit acknowledgment will contain either CR or CE, based upon HL7 enhanced acknowledgment rules (see HL7 v2.6, Section 2.9.3.2).

+
+
+

Message acceptance is based on:

+
+
+ +
+
+

If MSH-16 (Application Acknowledgement Type) is valued as "ER" or "AL", the Device-Patient Association Manager may report an application acknowledgement error using the application acknowledgement message (ACK^R01^ACK) for errors such as:

+
+
+ +
+
+

If the message from the Device-Patient Association Reporter is rejected, the application acknowledgement will contain the value AR or AE in MSA-1, based upon HL7 enhanced acknowledgment rules (see 1140 HL7 v2.6, Section 2.9.2.2). The reason for rejection is provided in the ERR segment.

+
+ +++ + + + + + +

Section 3.18.4.2 Device-Patient Disassociation Acknowledgment, Replace the existing text with additional detail on error reporting:

+
+

Existing Text:

+
+
+

The reply to the Device-Patient Association Report is an ordinary HL7 Acknowledgment.

+
+
+

Proposed Text:

+
+
+

The Device-Patient Association Manager responds to the Device-Patient Association Reporter using commit and application acknowledgments in a similar manner to PCD-17 requests. See section 3.17.4.2.

+
+
+

If MSH-16 (Application Acknowledgement Type) is valued as "ER" or "AL", the Device-Patient Association Manager may report an application acknowledgement error using the application acknowledgement Message (ACK^R01^ACK) for errors such as:

+
+
+ +
+ +++ + + + + + +

A.1.2.1 MSH Message Header, Replace the existing text with the following:

+
+

Existing Text:

+
+
+

Since this message is effectively an unsolicited observation report, the contents of the MSH segment follow the specifications for [PCD-01] in PCD-TF-2 Appendix B.1, except that MSH-21 is valued “IHE_PCD_017^IHE PCD^1.3.6.1.4.1.19376.1.6.4.17^ISO” to identify it as a message representing a device-patient association.

+
+
+

Proposed Text:

+
+
+

Since this message is effectively an unsolicited observation report, the contents of the MSH segment follow the specifications for [PCD-01] in PCD-TF-2 Appendix B.1 with the following exceptions:

+
+
+ +
+ +++ + + + + + +

A.1.2.6 PRT - Participation (Observation Participation), Add the following two new section after this section on page 41:

+
+

A.1.2.7 MSA – Message Acknowledgment Segment

+
+
+

See PCD-TF-2 Appendix B.2.

+
+
+

A.1.2.8 ERR – ERR Segment

+
+
+

Refer to PCD-TF-2 Appendix B.3 for general usage notes on the ERR segment.

+
+
+

The list of error codes that can occur during the processing of PCD-17 and PCD-18 messages are listed below. The application acknowledgment received from the Device-Patient Association Manager should contain the Code and Text in ERR-5.1 and ERR-5.2 respectively. ERR-5.9 can also be used to contain additional text related to the error.

+
+
+

Note that the definition of the range of error codes available for use by this profile is TBD. It is assumed that error codes will start at the lower limit of the range and be incremented by one as new error codes are added.

+
+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeTextExample

Lower limit + 1

Other error

Used when other errors are not applicable.

Lower limit + 2

Unknown device

Specified device is unknown.

Lower limit + 3

Unknown patient

Specified patient is unknown.

Lower limit + 4

Device is associated with another patient

A device-patient association or disassociation request was received, but the device specified in the request is associated with a different patient.

Lower limit + 5

Device is not associated with a patient

A device-patient disassociation request was received, but the device specified in the request is not associated with a patient.

Lower limit + 6

Unknown location

Specified location is unknown.

Lower limit + 7

Device-Patient association rejected.

Device-Patient Association Reporter sent an unvalidated Device-Patient association request (OBX-11 is not equal to \‘F\’). Association request was rejected by the participating user.

Lower limit + 8

User is unauthorized.

Participating user is unauthorized to perform request.

Lower limit + 9

Unknown user

Participating user is not known by the Device-Patient Association Manager.

diff --git a/CPs/html/cp_nn6.html b/CPs/html/cp_nn6.html index d6c6f5e..0234444 100644 --- a/CPs/html/cp_nn6.html +++ b/CPs/html/cp_nn6.html @@ -487,7 +487,7 @@

Change Proposal Summary Informatio -

PCIM Foundational Changes

+

PCIM Foundational Changes

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

@@ -526,10 +526,19 @@

Change Proposal Summary Informatio -
-

1 Section Appendix A – Actor Summary Definitions, modify the definitions in the table on line 213 as shown below and also adding the acroynm text in the name column and a new OID column.:

-
-

Existing Table:

+ +++ + + + + + +

Section Appendix A Actor Summary Definitions, modify the definitions in the table on line 213 as shown below and also adding the acroynm text in the name column and a new OID column:

+
+

Existing Table:

+
@@ -560,9 +569,9 @@

Existing Table:

+
+

Proposed Table:

-
-

Proposed Table:

@@ -594,12 +603,19 @@

Proposed Table:

+ +++ + + + + + +

Section Appendix B Transaction Summary Definitions, modify the table on line 218 to update the transcation names, definitions and numbers:

+
+

Existing Table:

-
-
-

2 Section Appendix B – Transaction Summary Definitions, modify the table on line 218 to update the transcation names, definitions and numbers:

-
-

Existing Table:

@@ -630,9 +646,9 @@

Existing Table:

+
+

Proposed Table:

-
-

Proposed Table:

@@ -667,34 +683,40 @@

Proposed Table:

+ +++ + + + + + +

PCIM Actors, Transactions, and Content Modules, replace Figure 7.1-1 on page 13 with updated actor name, number and definitions:

+
+

Existing Figure: +image::original-actor-transaction-diagram.png[]

+
+

Proposed Figure: +image::proposed-actor-transaction-diagram.png[]

-
-

3 PCIM Actors, Transactions, and Content Modules, replace Figure 7.1-1 on page 13 with updated actor name, number and definitions:

-
-

Existing Figure:

-
-
-original actor transaction diagram -
-
-
-
-

Proposed Figure:

-
-
-proposed actor transaction diagram -
-
-
-
-
-

4 PCIM Actors, Transactions, and Content Modules, replace Table 7.1-1 PCIM Profile – Actors and Transactions on page 14 with updated actor names, transactions and optionality value:

+ +++ + + + + + +

PCIM Actors, Transactions, and Content Modules, replace Table 7.1-1 PCIM Profile – Actors and Transactions on page 14 with updated actor names, transactions and optionality value:

WIP

-
-

Original Table:

+
+

Original Table:

+
@@ -713,9 +735,9 @@

Original Table:

+
+

Proposed Table:

-
-

Proposed Table:

@@ -732,109 +754,157 @@

Proposed Table:

-
-
-
-

5 Section 7.1.1.1 Device-Patient Association Reporter, change the paragraph on line 270:

-
-

Existing Text:

+ +++ + + + + + +

Section 7.1.1.1 Device-Patient Association Reporter, change the paragraph on line 270:

-

The Device-Patient Association Reporter represents a system or person that is asserts that a given device is attached or removed from a specific patient. For each such event, the unique Patient ID, Device ID, and timestamp must be reported.

+

Existing Text:

+
+

The Device-Patient Association Reporter represents a system or person that is asserts that a given device is attached or removed from a specific patient. For each such event, the unique Patient ID, Device ID, and timestamp must be reported.

-
-

Proposed Text:

-

The Device-Patient Association Reporter represents a system that asserts that a given device is associated or disassociated with a specific patient. For each such event, the unique Patient ID, Device ID, and timestamp of the beginning of association or end of association shall be reported. If a location is known, it should be included in the report. If the report is validated, the report observation shall be marked final, otherwise it shall be marked as requiring validation.

-
+

Proposed Text:

+
+

The Device-Patient Association Reporter represents a system that asserts that a given device is associated or disassociated with a specific patient. For each such event, the unique Patient ID, Device ID, and timestamp of the beginning of association or end of association shall be reported. If a location is known, it should be included in the report. If the report is validated, the report observation shall be marked final, otherwise it shall be marked as requiring validation.

-
-

6 Section 7.1.1.2 Device-Patient Association Manager, change the paragraph on line 274:

-
-

Existing Text:

+ +++ + + + + + +

Section 7.1.1.2 Device-Patient Association Manager, change the paragraph on line 274:

-

The Device-Patient Association Manager represents a system that collects and persists information on what devices are currently or were connected to patients within a defined scope, such as a clinical unit, at a given time, and can communicate these associations as query responses, event notifications, or both.

+

Existing Text:

+
+

The Device-Patient Association Manager represents a system that collects and persists information on what devices are currently or were connected to patients within a defined scope, such as a clinical unit, at a given time, and can communicate these associations as query responses, event notifications, or both.

-
-

Proposed Text:

-

The Device-Patient Association Manager represents a system that collects and persists -information on devices currently associated with patients within a defined scope, such as a clinical unit and shall communicate validated associations as query responses, event notifications, or both if requested. The system is responsible for resolving conflicts and shall provide an HMI for validating association assertions that require validation and resolving conflicts. Add an out-of-scope statement that describes the possibility of an actor that provides retrospective capabilities and why that makes sense)

-
+

Proposed Text:

+
+

The Device-Patient Association Manager represents a system that collects and persists information on devices currently associated with patients within a defined scope, such as a clinical unit and shall communicate validated associations as query responses, event notifications, or both if requested. The system is responsible for resolving conflicts and shall provide an HMI for validating association assertions that require validation and resolving conflicts. Add an out-of-scope statement that describes the possibility of an actor that provides retrospective capabilities and why that makes sense)

-
-

7 Section 7.1.1.3 Device-Patient Association Consumer, change the paragraph on line 279:

-
-

Existing Text:

+ +++ + + + + + +

Section 7.1.1.3 Device-Patient Association Consumer, change the paragraph on line 279:

+

Existing Text:

+
+

The Device-Patient Association Consumer represents a system or person that is has a requirement to receive information on what devices are or were connected to which patients. A common example is a critical care system that charts device observations for a patient.

-
-
-

Proposed Text:

-

The Device-Patient Association Consumer represents a system that needs to receive information on what devices are associated with which patients. Common examples are a medical device or critical care system that charts device observations for a patient. The system may receive association updates in real-time, if desired. Do we need to add text to capture multiple devices attached to a patient through other devices, e.g. Physio Mon with a EtCO2, Ventilator connection

+

Proposed Text:

+
+

The Device-Patient Association Consumer represents a system that needs to receive information on what devices are associated with which patients. Common examples are a medical device or critical care system that charts device observations for a patient. The system may receive association updates in real-time, if desired. Do we need to add text to capture multiple devices attached to a patient through other devices, e.g. Physio Mon with a EtCO2, Ventilator connection

+ +++ + + + + + +

Section 7.1.1.4 Device-Registrant, delete the paragraph on line 283 or change to reference MEMDMC?:

+
+

Existing Text:

-
-

8 Section 7.1.1.4 Device-Registrant, delete the paragraph on line 283 or change to reference MEMDMC?:

-
-

Existing Text:

-
+

The Device Registrant represents a system or person that maintains the list of medical devices that can be connected to a patient. The list entry for each device typically includes the device type, location (may not apply if the device is mobile), and unique identity.

-
-
-

Proposed Text:

-

The MEMDMC DMIR is an actor that enables automated contributions to the list of medical devices that can be associated with a patient. The list entry for each device typically includes the device type, location (may not apply if the device is mobile), model, manufacturer and unique identity.

+

Proposed Text:

+
+

The MEMDMC DMIR is an actor that enables automated contributions to the list of medical devices that can be associated with a patient. The list entry for each device typically includes the device type, location (may not apply if the device is mobile), model, manufacturer and unique identity.

+ +++ + + + + + +

Section 7.1.1.4 Device-Registrant, delete the two paragraphs starting at line 287 and tie them into an MEMDMC reference_:

+
+

Existing Text:

-
-

9 Section 7.1.1.4 Device-Registrant, delete the two paragraphs starting at line 287 and tie them into an MEMDMC reference:

-
-

Existing Text:

-
+

Where this is a person, it is most likely hospital staff that is interacting directly with the Device- Patient Association Manager through its user interface. Where it is a system, it may be a comprehensive device inventory system, a “gateway” system, or even the device itself.

+
+

Proposed Text:

-
-

Proposed Text:

The MEMDMC DMIR may automated device registration. The DMIR may be a “gateway” system or medical device itself.

+ +++ + + + + + +

PCIM Actor Options, change the first two paragraphs starting at line 293 to address the change in optionality and options:

+
+

Existing Text:

-
-
-

10 PCIM Actor Options, change the first two paragraphs starting at line 293 to address the change in optionality and options:

-
-

Existing Text:

-
+

The Device-Patient Association Consumer has two options available for receiving data from the Device-Patient Association Manager. The first option is to query the Manager for a snapshot of current associations, either by sending a patient identifier and receiving back the associated device(s) or by sending a device identifier and receiving back the associated patient. The second option is to receive an unsolicited continuous stream of association and disassociation events from the Manager as they occur. The Device-Patient Association Manager should support sending data via both methods, and the Device-Patient Association Consumer may support one or both methods. Options that may be selected for each actor in this profile, if any, are listed in the Table 7.2-1. Dependencies between options, when applicable, are specified in notes.

+
+

Proposed Text:

-
-

Proposed Text:

-
+

The Device-Patient Association Consumer may optionally query the Device-Patient Association Manager for configuration and filtering of patient association status in real-time. The query to the Manager results in an immediate delivery from the manager of the active associations based on the query filter criteria. The Consumer then receives an unsolicited continuous stream of association and disassociation events. The Device-Patient Association Manager may support the query option.

Options that may be selected for each actor in this profile, if any, are listed in the Table 7.2-1. Dependencies between options, when applicable, are specified in notes.

+ +++ + + + + + +

PCIM Actor and Options, change the table near line 303:

+
+

Existing Table:

-
-
-

11 PCIM Actor and Options, change the table near line 303:

-
-

Existing Table:

@@ -881,9 +951,9 @@

Existing Table:

+
+

Proposed Table:

-
-

Proposed Table:

@@ -915,24 +985,37 @@

Proposed Table:

+ +++ + + + + + +

Snapshot Option, move and alter text to address change in quey approach and option status in section 3.19, addressed later in this CP:

+ +++ + + + + + +

Subscription Option, re-number to 7.2.1 and update to reflect query option changes:

+
+

Existing Text:

-
-
-

12 Snapshot Option, move and alter text to address change in quey approach and option status in section 3.19, addressed later in this CP:

- -
-
-

13 Subscription Option, re-number to 7.2.1 and update to reflect query option changes:

-
-

Existing Text:

-
+

The snapshot option applies to query and response interactions between Device-Patient Association Consumer and Device-Patient Association Manager and specifies that the query response desired is a continuing subscription to changes in device-patient associations. A Device-Patient Association Consumer that supports this option shall formulate its request in the form described in Section 3.19.

+
+

Proposed Text:

-
-

Proposed Text:

-
+

The query option applies to query and response interactions between Device-Patient Association Consumer and Device-Patient Association Manager and specifies that the query response desired is a filtered real-time delivery of changes in device-patient associations.

@@ -941,12 +1024,10 @@

Proposed Text:

-
-
diff --git a/CPs/html/index.html b/CPs/html/index.html index 987563d..ac50069 100644 --- a/CPs/html/index.html +++ b/CPs/html/index.html @@ -449,69 +449,88 @@

CP Worklist

----+++++ - + - - - - + + + + + + + + + + + + + + - + + + @@ -521,7 +540,7 @@

CP Worklist

diff --git a/CPs/index.adoc b/CPs/index.adoc index 567f8d1..3f65057 100644 --- a/CPs/index.adoc +++ b/CPs/index.adoc @@ -29,7 +29,7 @@ DEV-52 |PCIM Device-Patient Association Manager Error Responses |NN4 -| +|xref:cp_nn4.adoc[NN4] |Draft |Bill Haralson (William.Haralson@icumed.com)

Description

CP #

Status

Author

DescriptionCP #TransactionsStatusAuthor

PCIM OBR Universal Service Identifier and Begin/End Time Stamps

NN1

DEV-51
+DEV-52

Draft

Eldon Metz (emetz@innovisionmedical.com)

PCIM Single Device Per Association/Disassociation Report Clarification

NN2

DEV-51

Draft

Eldon Metz (emetz@innovisionmedical.com)

PCIM Deterministic Snapshot and Real-Time Query Results

NN3

Draft

Eldon Metz (emetz@innovisionmedical.com)

PCIM Device-Patient Association Manager Error Responses

NN4

NN4

Draft

Bill Haralson (William.Haralson@icumed.com)

Adding an Optional Order ID to PCIM Transactions

NN5

DEV-51
+DEV-52

Draft

Tom Kowalczyk (Tom.Kowalczyk@BBraunUSA.com)

PCIM Foundational

NN6

DEV-51
+DEV-52
+DEV-19

In-progress

Eldon Metz (emetz@innovisionmedical.com)

DEV-51/52 and OBX-11 semantics (association error resolution scenarios)

NN7

DEV-51
+DEV-52

Assigned

Chris Mathes (cmathes@epic.com)

DEV-52 semantics and structure

DEV-51 and DEV-52 semantics and structure

NN8

DEV-51
+DEV-52

Assigned

Ali Nakoulima (ali.nakoulima@oracle.com)

Commit level and application level acknowledgement requirements

NNX

TBD

TBD