Skip to content

Apply CP style changes based on Bill H's approach. Generate HTML. #4

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.

Sign up for GitHub

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

Merged
eldonmetz merged 2 commits into from
Mar 17, 2023
Merged

Apply CP style changes based on Bill H's approach. Generate HTML. #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bdab342
Apply CP style changes based on Bill H's approach. Generate HTML.
eldonmetz Mar 17, 2023
b2b800e
Add cp_nn4 xref to CP work list.
eldonmetz Mar 17, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
166 changes: 117 additions & 49 deletions CPs/cp_nn6.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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"]
|===
Expand All @@ -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"]
|===
Expand All @@ -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"]
|===
Expand All @@ -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"]
|===
Expand All @@ -158,105 +162,159 @@ 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"]
|===
|Actors|Transactions|Initiator or Responder|Optionality|Reference

|===
[.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"]
|===
Expand Down Expand Up @@ -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"]
|===
Expand All @@ -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.
Expand Down
Loading