Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
The current proposal for PCIM as a "happy path" has a Reporter, Manager, and Consumer in the ecosystem that it would be used in. There may be situations where there are actors who can report association assertions, and actors who can consume association assertions, but the facility does not have a manager on site to handle these assertions.

Describe the solution you'd like
If it was a supported workflow in the standard to allow reporters to directly communicate to consumers (only in the absence of a manager), we could still reap some benefits of PCIM even with the missing value of the manager.

Describe alternatives you've considered
The alternative would be telling customers/facilities that they need to have all three actors in the equation to make use of PCIM functionality.

Additional context
Epic, as an example, doesn't want to handle all of the responsibilities of a manager, but can still handle some of the logic a manager does, but solely wants to be a "reporter" in PCIM lingo. Pump vendors could still receive DEV-51 messages or maybe DEV-51-as-a-52? Haha.

Create interaction diagrams to be included for each of the three transactions.

Expand the foundational CP to address identified issues in the DEV-19 message transaction section.

Issues:

• Change section title to Filter Device-Patient Associations [DEV-19]
• Update to reflect we are filtering only be device (do not include patient or time)
• Ensure we consistently reference manager to consumer in ordering and message flow direction
• Ensure the text states that a manager to consumer connection has initial association state passed in first
• Remove "response" for any description of association records, the DEV-19 response is only an ACK, but the result is initial and ongoing DEV-52 messages sent from manager to consumer

Paragraph 760 (in original PCIM spec, carried over into Foundational spec). Is this section still relevant as is? Not sure what this means in the context of the new PCIM?
“A device association can be reported as a point-in-time event, in which case a separate disassociate message is not required to delineate the end of the association. Alternatively, the association event message can convey a duration during which the association was in effect. The latter is equivalent to an associate/disassociate message pair and may be preferable for short duration associations (e.g., spot vitals collection).”

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Process suggestion: Use GitHub Issues for suggesting proposed changes and tracking work on proposed changes

Proposed edits:

High Level Overview table

• DPAC -- Add mention of pre-configured filters
• IHE wide glossary -- contact Mary for latest IHE-DEV glossary. Don't use the word glossary -- proposed name changed Appendix D -- Definitions

7 PCIM --- remove acute-care

• Diagram -- add reference to 7.1.1.4 under MEM DMC annotation ???

7.1.1.1 Change:

• first sentence: ... device is associated or disassociated with a specific patient, or an update to an existing association.
• last sentence: ..., the report observation status field shall be marked final, ...

7.1.1.3

• Change to: The actor initially receives current association status followed by updates in real-time.

7.1.1.4

Change title to: Device Registration

• In first sentence state:
  The list of medical devices that can be associated with the patient may be pre-configured or automated with MEM DMC DMIR.
• Clarify second paragraph, first sentence.
  Change to: The IHE DMC DMIR may facilitate automated device registration.
• Examples for DMIR. model, manufacturer, serial number, end point (IP address, port)

7.2

• First sentence:
  Reverse DPAM and DPAC filtering references

7.2.1

• Table 7.2.1 remove reference for reporter.
• Paragraph: Reverse DPAC and DPAM order in sentence.

7.4

• In use case example titles, change Query to Filter
• Description section before Flow section

7.4.2.1.1

• Title change to: Process Flow
• Second sentence: The --> This

7.4.2.1.3

• typo: device identify to device identity

7.4.2.3.1

• reverse position of DPAC and DPAM

7.4.2.4

• Drop this use case

7.7

• add 7.7.1 with existing text with expectation of added out of scope examples

This work list item is already written as a CP in a word document. This issue serves as a tracker to convert this word document to Ascii doc, add a link to it on the Work List, and submit for approval. Please refer to the change proposal linked for details on the CP itself.

I reviewed both documents today (July 17th). My comments:

1. Appendix A updates: Switch places of DPAC and DPAM in table. Reflects workflow better and matches original PCIM Spec changes.
2. Appendix A: DPAM description: “…delivers records that match device-patient association queries…” to “..delivers records that match device patient association subscription query filter…”?
3. Section 7.4 Do we need a use case for updating an existing device-patient association?
4. Section 3.19.4.2 Message Semantics: It looks like the original text, rather than the updated test made it into the PCIM Foundational PDF file.
5. Section 3.19.4.2.1 Trigger Events: Some updated text missing from the PCIM Foundational PDF file.
6. Table A.1.1-1 Report Device Patient Association: “{“ row: Replace “..for each device…” to “…for the device…”?
7. Paragraph 760 (in original PCIM spec, carried over into Foundational spec). Is this section still relevant as is? Not sure what this means in the context of the new PCIM?
   “A device association can be reported as a point-in-time event, in which case a separate disassociate message is not required to delineate the end of the association. Alternatively, the association event message can convey a duration during which the association was in effect. The latter is equivalent to an associate/disassociate message pair and may be preferable for short duration associations (e.g., spot vitals collection).”
8. Section A.1.2.6 PRT: Change “There will be PRT messages identifying the device, responsible observer…” to “There will be PRT segments identifying the device, responsible observer,….”.
9. Section A.2.3.2-3 QPD Segment: Update second paragraph “…so that for example, a patient identifier and a device identifier specification…” to “…so that for example, a patient location and a device identifier specification
10. A.4 Example Messages, Example 2 (Nurse Ratched/McMurphy). First sentence after sample message hints that the unvalidated assertion will be sent to the DPAC (“The Association Manager may then broadcast this information to subscribers…..”).
11. A.4 Example Message, Example 3: Foundational CP contains an example QPD segment showing a query by PID.3.1.

· Section 3.52.4.1, 2nd sentence should have some indication that only those messages that meet the filter criteria, if specified, will be sent

· Section 3.19, 3rd paragraph: The sentence beginning with "If the DEV-19 transaction is not supported, ..." doesn't make sense to me, especially the reference to "...and the network connection is lost".

o Is the original intent of this to say that if the manager doesn't support DEV-19 then it should just become a normal feed of all associations?

· Contradiction:
o Table 3.52.2-1, Actor Roles, Device-Patient Association Consumer: "The consumer initially receives current association status followed by updates in realtime on a connection established by the Manager. It may optionally send a filter dynamically in the form a HL7 query or that filter may be pre-configured.
§ This makes it sound like the filter is sent on the connection that was established from the Manager to the Consumer

o Section 3.19.4.1.3, Expected Actions, 2nd paragraph: "one practical method is for the Device-Patient Association Manager to maintain an open TCP listen port to accepts connections from one or more Device- Patient Association Consumer clients and then to open an individual TCP connection with each requester that persists as long as the client is connected and the query is valid"

· Inconsistency:
o Section A.1 uses "Communicate Device-Patient Association and Disassociation"

o Table A.1.1-1 uses "Report Device Patient Association", and text below the table uses "Communicate Device-Patient Association" and "Report Device-Patient Association"

· Section A.1.2.5, "OBX - Observation (for Patient ID)": the section name is confusing, as the OBX isn't used to identify the patient involved

· Table A.1.2.5-1, field 3, Description column: should not be MDCX

· PRT-10 Participation Device (EI), paragraph 1, something is missing near the end: "...but in any case must contain See details in the"

· Section A.2.3.2, "QPD Segment": what is CSC data type? Should this be QSC?

· Section A.2.4, RCP Segment: "RCP-4 Execution and Delivery Time is required when RCP-1 contains the value of RCP-1 D (Deferred)."

o The second RCP-1 should not be present

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

human and device (, vs and)

Issues/comments found when reviewing the latest version of the PCIM Foundational CP:

1. 3.17.4.1.2 Line 793: "Message Grammer" -> "Message Semantics"
2. 3.17.4.1.2 Message semantics - line 511 changes
   "an application-level acknowledgment may be sent to the Reporter after the association or disassociation is validated at the Manager"
   to
   "an application-level acknowledgment may be sent to the Reporter after the association or disassociation is processed the Manager"
   "Examples of errors that can occur during device patient association processing include the following"
   to
   "Examples of application level errors that can occur during device patient association processing include the following"
3. 3.52.4.1.1 Trigger Events: Reference to Appendix 0 -> "See Appendix 0 for details of HL7 V2 messages."
4. 3.19.2 Actor Roles: Device-Patient Association Consumer Role description in table:
   "Establishes an real-time message reporting subscription"
   to
   "Establishes a real-time message reporting subscription"
5. Volume 2 Namespace Additions: Existing Table doesn't match spec, Proposed Table missing OID's and references.
6. A.4 Example Messages, modify the OBR segment on line 988 on page 50:
   "69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE ^MDC"
   to
   "69136^MDC_OBS_ASSOCIATION_PATIENT_DEVICE^MDC"
7. Line 1055: MSH segment missing fields i.e., character set, message type and OID

I read through the latest PCIM Foundational CP and have a couple of questions (not necessarily issues). I think the doc looks great otherwise.
Questions:

1. Table 3.52.2-1 Actor Roles: “…The Manager must send current associations for all devices…..after a connection is established”. Question: The Manager will always do this when a network connection is established, whether it supports DEV-19 or not? In other words, if a Consumer uses DEV-19 to filter messages, and the Manager supports DEV-19, the Consumer will get DEV-52 messages for all associations when it connects to Manager be default, then get DEV-52 for all filtered associations when it sends the DEV-19 to the Manager?
2. Section 3.52.4.1.1 Trigger Events: “On receipt of the messages, the consumer system checks for valid syntax and …” For points 2 “device is a member of registered device instances and has no conflicting associations” and point 3 “patient is a known person in appropriate status (e.g., admitted)” the Consumer may not know if the patient is admitted or assume the Manager is the source of truth when it comes to patient association conflicts. Should the Consumer override the current patient association in this case and return normal ACK or send NACK to the Manager when this occurs? Or was the association conflict referring to another type of conflict e.g., Consumer knows that the pump is associated with a patient via a PCD-03 (PIV) request at the time the DEV-52 for it arrived?
3. Section A.1.3 Application Acknowledgment. Error codes start at Lower Limit +1. I thought a change was made earlier to have the codes start at Lower Limit.

Tie this in with the upcoming error codes PR.

Have Process Flow follow Description to match the sections order of the other use cases in the NN6 document

Section A.2.3, first sentence below Table A.2.3-2: why does it refer to "ORU^R01 Message Structure in PCD TF-2"? And what section in TF-2?

• Table 7.1-1 Change "Report Device-Patient Association or Disassociation" to "Assert Device-Patient Association or Disassociation"
• 7.4.2.2 Change "point of care" to "point-of-care"
• 7.4.2.2.4 Capitalize reporter in Device-Patient Association Reporter (look elsewhere too, be consistent)
• Indicate once verified by a user, the message can be final or corrected.
• A.2.3-1 Fix text in Response Characteristics and Based on Segment pattern rows (PCD-17 and response text is obsolete)
• Fix initiator or responder column
• Fix awkward "serve/serves" wording issues

As part of the DEV-51 transaction, it would be good to discuss the set of criteria that the DPAM actor can enforce to:

• Fully accept DEV-51
• Partially accept DEV-51, or
• Reject DEV-51

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Merge CP #4 text into CP #1, updating sections as necessary due to changes in structure and content in current state of foundational CP.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.
• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.
• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

'The system design must assure that errors are indicated to the appropriate human user(s) in an effective and timely manner so that action can be taken'. Add sentence to reference the possibility of using a technical alert, but that it is out of scope in this document to go further.

During the Spring 2023 IHE PCD Face to Face, we discussed the current capabilities of the DEV-19 query. To set up a filter with current specifications, you would need to know the patient's ID or location information. If I just want a feed of "all of my devices" or "all of my devices at this facility", I don't have that option and it'd be nice to have.

Describe the solution you'd like
During the DEV-19 query, I should be able to also specify adding a filter criteria to MSH-5 and MSH-6. (this is interesting because I'm sending as MSH-3/4 during the query, but I'd be the receiver on the DEV-52 messages.

Describe alternatives you've considered
n/a

Additional context
n/a

Typos:
Table A.1.1-1, the {} brackets should be removed because there is only one association per message

Could be replaced with “—ASSOCIATION begin” and “—ASSOCIATION end”
Section A.1.2.4, “Order Request” should be “Observation Request”
Section A.1.3, should the first entry be simply “Lower limit”?
Section A.2.3.1
Why is this reference to DEV-52 in the section for DEV-19?
Table A.2.3.2-3, what HL7 message MSH.5 and MSH.6 refer to?
Table A.2.4-2
“Field Seq” values 5 and 6 should be 4 and 5
A.4
Example 1:
The first ORU^R01, the second “AL” should be in MSH-16, not MSH-17
The first commit level ACK is missing MSH-10 (Message Control ID)
Example 2:
The 2nd PRT (for AUT)
PRT-1 should be “2”
PRT-11 should be the ID of the nurse
Example 3:
The first MSH segment has all kinds of problems
In RCP segment, ‘N’ should be in RCP-5, not RCP-6
Where did the “HL7005” come from in the QID segment?
Example 4:
Same as Example 2
3.19.4.2.2, Message Semantics
What does this mean: “The message is made up of a frame identifying the message, a read-back of the query filter parameters of the request, and a commit level acknowledgement.”
What happens if PV1-3 and PRT-10 for EQUIP don’t match?
Applies to both DEV-51 and DEV-52
Shouldn’t the App ACK for DEV-51 have its own unique Message Type (MSH-9) instead of ACK^R01^ACK?
Sockets
Which side establishes the connection for DEV-52?
Wording in Section 3.19 is ambiguous: “…the Device-Patient Association Manager shall send DEV-52 messages for all current Device-Patient associations to the Device-Patient Association Consumer when network connectivity is restored.”
The connectivity could be restored by either side making a connection
In wording at the end of A.2.3, it appears the manager makes the connection to the consumer, and any filter parameters previously received in a DEV-19 must be persisted and applied when a new connection is established
“If the connection is lost, the manager must continue to try and establish a new connection to the consumer, always sending the current device-patient association events matching the filter once the connection is re-established.”
When first established, will all current associations be sent?
How does this relate to DEV-19? Is DEV-19 only applicable after the initial firehose of all associations?
See also text in A.2.4, beginning with “will receive all existing associations when the connection is first established that meet the desired filter specification to get the starting state.”
What socket is DEV-19 sent on?
Consider adding some way to identity the device type in the DEV-51 and DEV-52 messages
Example: Use MDC_DEV_PUMP_INFUS_VMD for all infusion pumps, regardless of LVP or syringe
Otherwise we will need to figure out a way to identify our pumps from all other devices that will have associations, likely through a serial number lookup, which is not as efficient as being able to immediately discard associations from other device types
It would also allow for the possibility of being able to have device type as a filter option

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Nicolas suggested we have to define a new template to do this correctly. This could take a while.

• Manager - HMI to validate and to perform conflict resolution.
• Reporter - Qualify authority to assert. State that the authority necessary by reporter does not need to be double verified by manager. But do state that the Reporter must include and log the responsible authority when this occurs.
• Add status field (requires validation vs final) as a requirement for reporter to properly populate.