Resolved issues for document "IHE_Suppl_DEV_Profile_Monitored_Communication.docx"

[PeterKranich]

Resolved issues for document "IHE_Suppl_DEV_Profile_Monitored_Communication.docx"; new version 1.4

Closes #28, #29, #30

📑 Description

• Removed transaction DEV54 and reformatted sections accordingly
• Updated message forrmat requirement: utilized HL7 message structure shall be ORU_R44
• Updated the message examples according to the new message structure
• Updated version to 1.4 and date to 15-July-2025

✅ Checks

• My pull request adheres to the code style of this project
• My code requires changes to the documentation
• I have updated the documentation as required
• All the tests have passed
• I have selected a committee co-chair to review the PR

ℹ Additional Information

All changes are marked with change bars in the document

[PeterKranich]

@kelliaso: hi, Kurt, I was not sure who else I should add to the reviewers' list. I could not find Monroe and Rob in the github reviewers list for this repository. Please feel free to add more reviewers.

[JavierEspina]

@kelliaso: hi, Kurt, I was not sure who else I should add to the reviewers' list. I could not find Monroe and Rob in the github reviewers list for this repository. Please feel free to add more reviewers.

@ToddCooper , could you please add Monroe and Rob to this Github repo? ... or give me / all five DEV-level co-Chairs "IHE superpowers" to be able to do it?

[JavierEspina]

1. In Table 14.1-1 I would expect to see a row for the reporter and a row for the consumer, both supporting DEV-53, the former as initiator and the latter as responder
2. In Figure 14.1-1 the "Acknowledge Heartbeat Message" line could be deleted. In this kind actor diagrams (for other DEV TF Profiles) acknowledgements are not typically depicted. They are in flow charts (such as Figure 14.4.2.2-1 or Figure 3.53.4-1, where the depicted acks definitely make sense).

Otherwise the changes made appear to correctly address DEV (PCMC) issues 28-30. Review approval by either Kurt or Monroe or Rob recommended.

[monroepattillo]

I believe PHASE should be thoroughly utilized - START for initial message of a reporter to consumer pairing, CONTINUE for each subsequent unchanged poll, UPDATE should poll parameters be updated (which would also be a poll), and END for when the pairing is ended by the reporter.
Additionally, I believe the poll period should appear as an OBX segment instance value in each poll message.
I initially thought that poll reset could be implied by reporter reception of a receipt ack of an unrelated profile. While this would reduce the number of explicit poll message on the network and mitigate its loading, this approach might not provide what is intended when the receipt ack sending system implemented multiple software actors on one system. If the intent of the poll is to assure that specifically the poll software is functioning this might not accomplish this requirement. Whether or not receipt acks of other profiles should be implied poll acks might best be left as a deployment configuration item. If the PCMC profile consumer actor is implemented as its own software application, it will not provide the requisite actor readiness status. If the intent is to verify communication with the receiving software (consumer/manager) of specific profiles then we might want to revisit PCMC as an event trigger observation within each protocol which it is intended to support. An ICMP non-IHE PING will verify destination IP receiver and the network path to get to it, as well as the round-trip time. If the goal is to verify meaningful communication with the poll receiving profile actor then maybe it should be within each profile as an indicated trigger event within each profile.
For all except ACM endpoint communication verification only 1 message type and 1 receipt ACK should be needed, an application ACK should not be needed. Unless it is through pre-configuration, not sure how poll reporter would know identification (PIN) of population of endpoint communication devices and how the poll reporter would know ACM AM actor internal assignments to know which is pertinent to current duty shift for which patients. If it did know the PIN of the endpoint to be verified it would need to include this in the end to end poll request using a PRT segment instance to identify it. The poll would need to be mapped by the ACM AC actor into a WCTP "poll of endpoint application" message to verify internal workings of app on endpoint communication device and to avoid clinicians needing to respond to them (and wanting to disable the "feature" after being required to respond to the 3rd poll in a few minutes).
Wen referring to acknowledgment HL7 message used to respond to polls, use the phrases "receipt acknowledgement" (which is intended to be used) and "application acknowledgement" (which is not intended to be used).
The interoperability mechanisms (standards, profiles, protocols, actors, transactions, content, triggers, responses) by which a gateway reporter manages communication status with the devices and systems for which it is responsible should be states as out of scope for this profile.
IHE Dev profiles typically group with the ITI domain consistent time profile to assure accurate timestamps in messages and to sustain message to message chronological ordering in actor logging.

[monroepattillo]

In section 14.4.2.1 Use Case #1: Reliable Alert Distribution, replace the sentence with something more aligned with the ACM profile, such as...
Reported alerts (physiologic alarms, technical alarms, advisories) from an Alert Communication Management (ACM) Alert Reporter (AR) actor needs to be disseminated reliably to ACM Alert Communicator (AC) associated endpoint communication devices (various types of pagers, phones, tablets, badges, watches, computers, etc.) as actionable, for message and procedural response by doctors, clinicians, and other alert event assigned staff.

[monroepattillo]

Section 14.4.2.1.2 Reliable Alert Distribution Process Flow
Not sure the ACM actors should be referenced without associated with the PCMC actors. Maybe something like the ACM AR actor acting as a PCMC PCD REPORTER actor sends the heartbeat message. And the ACM AM actor acting as a PCMC PCD CONSUMER actor responds to the heartbeat message.

[monroepattillo]

Section 14.5 PCMC Security Consideration
Replace paragraph with common IHE Devices ITI domain associated security considerations paragraph.

[monroepattillo]

Section 3.53.4.1 Send Heartbeat Message [DEV-53]
DEV-53 is now its own transaction. It is no longer an "in-line" alert (ACM PCD-04) event.

[monroepattillo]

Section 3.53.4.1.2 Message Semantics, line 479
Another old reference to "in-line" alert.

[monroepattillo]

Line 485, segment OBX Field content table, row OBX-11, Note column, add justification for "F" value, such as...
Final (F) is indicated so as to avoid encumbering clinical staff with review and confirmation effort for a system-to-system internal event that is not patient physiology associated and occurs in high volumes over the course of a staff shift.

[monroepattillo]

FYI - While the alarm standard indicates alarm annunciation to a responsible clinician within 10 seconds, deployments for physiologic alarm notifications for life critical events (asystole) are typically 5 seconds or less, and the ACM AM typically only receives the PCD-04 Report Alert from the AR after about 5 of those 10 seconds so that the physiologic monitor can create the before to event to after ECG waveform, leaving the ACM solution (AM, AC, endpoint) about 2 seconds to get the alert notification to an actionable clinician. If the alert dissemination to the primary recipient is undeliverable or is not endpoint acknowledged as received within 2 seconds or is not responded to by the clinician (Accept, Reject) within 2 seconds, the AM sends it to the secondary which accounts for 6 out of 10 seconds.

[PeterKranich]

1. In Table 14.1-1 I would expect to see a row for the reporter and a row for the consumer, both supporting DEV-53, the former as initiator and the latter as responder
2. In Figure 14.1-1 the "Acknowledge Heartbeat Message" line could be deleted. In this kind actor diagrams (for other DEV TF Profiles) acknowledgements are not typically depicted. They are in flow charts (such as Figure 14.4.2.2-1 or Figure 3.53.4-1, where the depicted acks definitely make sense).

Otherwise the changes made appear to correctly address DEV (PCMC) issues 28-30. Review approval by either Kurt or Monroe or Rob recommended.

@JavierEspina I agree with #1. In the last WG meeting I was told to leave the acknowledge HB Msg action. Let's discuss this in the next review meeting.

[PeterKranich]

I believe PHASE should be thoroughly utilized - START for initial message of a reporter to consumer pairing, CONTINUE for each subsequent unchanged poll, UPDATE should poll parameters be updated (which would also be a poll), and END for when the pairing is ended by the reporter.

@monroepattillo: this is defined in section 3.53.4.1.2 Message Semantics along with corresponding examples.

[PeterKranich]

Additionally, I believe the poll period should appear as an OBX segment instance value in each poll message.

@monroepattillo: the periodicity of the heartbeat message is defined in section 3.53.4.1.2 Message Semantics along with corresponding examples. The periodicity is part of every heartbeat message.

[PeterKranich]

I initially thought that poll reset could be implied by reporter reception of a receipt ack of an unrelated profile. While this would reduce the number of explicit poll message on the network and mitigate its loading, this approach might not provide what is intended when the receipt ack sending system implemented multiple software actors on one system. If the intent of the poll is to assure that specifically the poll software is functioning this might not accomplish this requirement. Whether or not receipt acks of other profiles should be implied poll acks might best be left as a deployment configuration item. If the PCMC profile consumer actor is implemented as its own software application, it will not provide the requisite actor readiness status. If the intent is to verify communication with the receiving software (consumer/manager) of specific profiles then we might want to revisit PCMC as an event trigger observation within each protocol which it is intended to support.

@monroepattillo: that is a good point. I tend to define the heartbeat message as an independent message not mixed up with heartbeat with messages from other profiles (e.g. DEC, ACM, etc.).

However, this does not solve the problem if the heartbeat is intended for a certain application using the same network connection. We could define that this would require separate connections for different profiles - e.g. one for DEC, one for ACM, etc. We could also add information about profile to which the heartbeat relates to in an additional field e.g. the OBX-15 Producer's ID could contain the OID of the profile or transaction. In this case, there would be multiple heartbeat messages - once per profile (application).

[PeterKranich]

In section 14.4.2.1 Use Case #1: Reliable Alert Distribution, replace the sentence with something more aligned with the ACM profile, such as... Reported alerts (physiologic alarms, technical alarms, advisories) from an Alert Communication Management (ACM) Alert Reporter (AR) actor needs to be disseminated reliably to ACM Alert Communicator (AC) associated endpoint communication devices (various types of pagers, phones, tablets, badges, watches, computers, etc.) as actionable, for message and procedural response by doctors, clinicians, and other alert event assigned staff.

@monroepattillo: Agreed - I changed this for the next version.

[PeterKranich]

Reported alerts (physiologic alarms, technical alarms, advisories) from an Alert Communication Management (ACM) Alert Reporter (AR) actor needs to be disseminated reliably to ACM Alert Communicator (AC) associated endpoint communication devices (various types of pagers, phones, tablets, badges, watches, computers, etc.) as actionable, for message and procedural response by doctors, clinicians, and other alert event assigned staff.

@monroepattillo: much better than mine - I changed this for the next version.

[PeterKranich]

Section 14.5 PCMC Security Consideration Replace paragraph with common IHE Devices ITI domain associated security considerations paragraph.

@monroepattillo: I copied that from the PCIM profile:
7.5 PCIM Security Considerations
This profile itself does not impose specific requirements for authentication, encryption, or 430 auditing, leaving these matters to site-specific policy or agreement based on careful risk analysis taking into account the security and privacy sensitivity of the patient and device-patient association content being handled. The IHE PCD Technical Framework identifies security requirements across all PCD profiles.

Shouldn't we rather stay consistent with other supplements?

[PeterKranich]

Section 3.53.4.1 Send Heartbeat Message [DEV-53] DEV-53 is now its own transaction. It is no longer an "in-line" alert (ACM PCD-04) event.

and

Section 3.53.4.1.2 Message Semantics, line 479 Another old reference to "in-line" alert.

@monroepattillo: I was not sure about that: yes, it is its own transaction, but it is formatted as an "in-line" alert event!?

[kelliaso]

Line 485: In the table on page 23, OBX-8 has 3 values for abnormal flags. Use of OBX-8 components has been deprecated with new implementations using separate OBX segments. As of HL7 2.7, OBX-8 has been changed to Interpretation Codes.

[kelliaso]

We need to review the Actor names, they should be what the actor is doing, not include Profile name. PCMC Actors could be Device Heartbeat Reporter, Device Heartbeat Consumer. Similar to Device Observation Reporter, Device Observation Consumer.

[ToddCooper]

@kelliaso ...

We need to review the Actor names, they should be what the actor is doing, not include Profile name. PCMC Actors could be Device Heartbeat Reporter, Device Heartbeat Consumer. Similar to Device Observation Reporter, Device Observation Consumer.

My guess is that the DCC review (think Kevin O'D.) would encourage even shortening it to Heartbeat Reporter / Consumer (or similar) since technically, actor names should be reusable across profiles, including in other domains! Of course, this works well too.

[PeterKranich]

Line 485, segment OBX Field content table, row OBX-11, Note column, add justification for "F" value, such as... Final (F) is indicated so as to avoid encumbering clinical staff with review and confirmation effort for a system-to-system internal event that is not patient physiology associated and occurs in high volumes over the course of a staff shift.

@monroepattillo: This is also defined by the "in-line" event format definition, but it is fine for me to add your proposed note - I added it for the next version.

[PeterKranich]

FYI - While the alarm standard indicates alarm annunciation to a responsible clinician within 10 seconds, deployments for physiologic alarm notifications for life critical events (asystole) are typically 5 seconds or less, and the ACM AM typically only receives the PCD-04 Report Alert from the AR after about 5 of those 10 seconds so that the physiologic monitor can create the before to event to after ECG waveform, leaving the ACM solution (AM, AC, endpoint) about 2 seconds to get the alert notification to an actionable clinician. If the alert dissemination to the primary recipient is undeliverable or is not endpoint acknowledged as received within 2 seconds or is not responded to by the clinician (Accept, Reject) within 2 seconds, the AM sends it to the secondary which accounts for 6 out of 10 seconds.

@monroepattillo: 10 seconds requirement came from the particular alarm standard for electrocardiographs. We had some discussions with other people in the alarm standard working group. Vitor Vicente Antunes, who is our alarm export in Philips HPM and also member of the working group, came to the conclusion that this requirement didn't apply for a distributed alarm event. The requirement is more intended for the alarm announcement directly at the electrocardiograph. If we want to discuss this further I can invite Vitor for the discussion.

[PeterKranich]

Line 485: In the table on page 23, OBX-8 has 3 values for abnormal flags. Use of OBX-8 components has been deprecated with new implementations using separate OBX segments. As of HL7 2.7, OBX-8 has been changed to Interpretation Codes.

@kelliaso: I used this values from the "in-line" event definition defined by Paul Schluter. If there is no need to stick with the "in-line" event format, I can change this to something else.

[PeterKranich]

We need to review the Actor names, they should be what the actor is doing, not include Profile name. PCMC Actors could be Device Heartbeat Reporter, Device Heartbeat Consumer. Similar to Device Observation Reporter, Device Observation Consumer.

@kelliaso, @ToddCooper: fine with me. The original intention was to insert the Heartbeat as an "in-line" event in other IHE profiles but my understanding now is that we all tend to a separate Heartbeat message. In this case, we can define more specific actor names.

[GongliW]

While the PCMC profile primarily describes bidirectional communication between Heartbeat Reporter and Heartbeat Consumer, many medical devices, especially legacy, low-power, or highly secure systems, may only support unidirectional communication, where the device can send data but cannot receive commands or acknowledgments.

So, maybe we can consider “Start-Only Watchdog Model for Unidirectional Communication”?

In unidirectional environments, the “start_only” event phase of the heartbeat message can be used as a periodic watchdog signal. Each signal acts as a discrete confirmation of device health within a predefined timeout window. The Heartbeat Consumer monitors the arrival of these signals and infers device status based on their presence or absence, triggering alerts if expected signals are missed.

I understand the limitations of such an implementation. For example, the periodicity and timeout values should be carefully selected based on the criticality of the device and the clinical workflow requirements. However, I think this approach could broaden the applicability of PCMC across a wider range of medical device connectivity scenarios.

[monroepattillo]

Gongli, This would imply the sender is using other than HL7 v2.x (upon which PCMC is based) which is transported via a TCP/IP socket connection which utilizes two-way communication. A heartbeat communication profile that can only send and not receive (to confirm heartbeat receipt and response) would mean it is the responsibility of the heartbeat consumer to discern whether the sender is alive or not via sender producing periodic one-way heartbeat messages and the sender would have no ability to discern whether or not the consumer is connected and operational. I’ve seen something like this in ACM for nurse call systems. Prior to nurse call event message being gateway transported on TCP/IP HL7 v2.x ACM PCD-04, the serial communication is one-way, alert originator (nurse call system) sends, but does not receive commands. ACM AM vendor actors implement a “haven’t heard from recently” internally initiated alert which is out of scope for ACM. I am aware of communication applications, not using HL7 v2.x (meaning not using TCP/IP) meaning not two-way communication, and not bidirectional communication (socket) initiation, with report only actors (on simple one-way serial interfaces) that periodically send and do not support receive, not even simple acknowledements. Just not sure that is the PCMC profile target audience, but I could be wrong. Regards, Monroe Pattillo IHE DEV PCD PC Co-Chair Emeritus Member IEEE, IHE IHE ACM, MEM DMC & LS Working Group Lead Practical Health Interoperability, LLC Managing Member Mobile 954-850-7405 E-mail ***@***.*** ***@***.***> From: Gongli Wang ***@***.***> Sent: Wednesday, October 8, 2025 1:21 PM To: IHE/DEV ***@***.***> Cc: Monroe Pattillo ***@***.***>; Mention ***@***.***> Subject: Re: [IHE/DEV] Resolved issues for document "IHE_Suppl_DEV_Profile_Monitored_Communication.docx" (PR #31) <https://avatars.githubusercontent.com/u/150687485?s=20&v=4> GongliW left a comment (IHE/DEV#31) <#31 (comment)> While the PCMC profile primarily describes bidirectional communication between Heartbeat Reporter and Heartbeat Consumer, many medical devices, especially legacy, low-power, or highly secure systems, may only support unidirectional communication, where the device can send data but cannot receive commands or acknowledgments. So, maybe we can consider “Start-Only Watchdog Model for Unidirectional Communication”? In unidirectional environments, the “start_only” event phase of the heartbeat message can be used as a periodic watchdog signal. Each signal acts as a discrete confirmation of device health within a predefined timeout window. The Heartbeat Consumer monitors the arrival of these signals and infers device status based on their presence or absence, triggering alerts if expected signals are missed. I understand the limitations of such an implementation. For example, the periodicity and timeout values should be carefully selected based on the criticality of the device and the clinical workflow requirements. However, I think this approach could broaden the applicability of PCMC across a wider range of medical device connectivity scenarios. — Reply to this email directly, view it on GitHub <#31 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5XNKARHIAPWCNVVUWNBBT3WVBZNAVCNFSM6AAAAACBRDSJFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBSGUZDQMJRGY> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AJ5XNKGNDONSFQE43EETF3L3WVBZNA5CNFSM6AAAAACBRDSJFSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWJTVEHI.gif> Message ID: ***@***.*** ***@***.***> >

[witkowb1]

Hi,
I've reviewed with internal Baxter folks and we collectively have some questions/concerns/asks:

1. For Gateway HR examples, there's one example that has one device. A gateway can manage literally thousands of devices. How will this look for n > 1 devices? How many devices will fit in one DEV-53?

2. Say an HR sends a heartbeat and doesn't get an acknowledgement. Is there guidance on "how many" non-acks should occur before you say that communications are down/the HC is not responding and thus need to generate a technical alarm?

3. At line 375 it's mentioned that patient/location are not included in PCMC. Can we make a mention as to where those would otherwise be handled? Not specifically which other transactions but mostly that "other transactions take responsibility for tracking/updating" those things.

4. The term INOP is used which some folks understand what it means, but others do not, can we define this somewhere?

5. For Heartbeat Reporter we indicate what that role does. Throughout the document we refer to individual device, gateway proxy, etc. It might be clearer to list the types of HRs in the definition so that it is clear what those are referring to when referenced in use cases. It might also be useful for the Heartbeat Consumer to list some examples of what might be a consumer of these transactions.

6. In a separate email chain with you, you had provided some scenario diagrams for different use cases. Would it be useful to include something like that here?

[monroepattillo]

Brian, Queuing these up (CC’ing ACM WG) for discussion during this Thursday’s 11AM ET ACM WG session which is where we’ve been discussing PCMC. Regards, Monroe Pattillo IHE DEV PCD PC Co-Chair Emeritus Member IEEE, IHE IHE ACM, MEM DMC & LS Working Group Lead Practical Health Interoperability, LLC Managing Member Mobile 954-850-7405 E-mail ***@***.*** ***@***.***> From: witkowb1 ***@***.***> Sent: Friday, October 17, 2025 1:52 PM To: IHE/DEV ***@***.***> Cc: Monroe Pattillo ***@***.***>; Mention ***@***.***> Subject: Re: [IHE/DEV] Resolved issues for document "IHE_Suppl_DEV_Profile_Monitored_Communication.docx" (PR #31) <https://avatars.githubusercontent.com/u/160271212?s=20&v=4> witkowb1 left a comment (IHE/DEV#31) <#31 (comment)> Hi, I've reviewed with internal Baxter folks and we collectively have some questions/concerns/asks: 1. For Gateway HR examples, there's one example that has one device. A gateway can manage literally thousands of devices. How will this look for n > 1 devices? How many devices will fit in one DEV-53? 2. Say an HR sends a heartbeat and doesn't get an acknowledgement. Is there guidance on "how many" non-acks should occur before you say that communications are down/the HC is not responding and thus need to generate a technical alarm? 3. At line 375 it's mentioned that patient/location are not included in PCMC. Can we make a mention as to where those would otherwise be handled? Not specifically which other transactions but mostly that "other transactions take responsibility for tracking/updating" those things. 4. The term INOP is used which some folks understand what it means, but others do not, can we define this somewhere? 5. For Heartbeat Reporter we indicate what that role does. Throughout the document we refer to individual device, gateway proxy, etc. It might be clearer to list the types of HRs in the definition so that it is clear what those are referring to when referenced in use cases. It might also be useful for the Heartbeat Consumer to list some examples of what might be a consumer of these transactions. 6. In a separate email chain with you, you had provided some scenario diagrams for different use cases. Would it be useful to include something like that here? — Reply to this email directly, view it on GitHub <#31 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5XNKBFZO52G6JTUDWHP6T3YEUC7AVCNFSM6AAAAACBRDSJFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMJWGUZDGNBUGA> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AJ5XNKDWHBXMXU3MEWU3QWL3YEUC7A5CNFSM6AAAAACBRDSJFSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWLUQBLA.gif> Message ID: ***@***.*** ***@***.***> >

[PeterKranich]

While the PCMC profile primarily describes bidirectional communication between Heartbeat Reporter and Heartbeat Consumer, many medical devices, especially legacy, low-power, or highly secure systems, may only support unidirectional communication, where the device can send data but cannot receive commands or acknowledgments.

So, maybe we can consider “Start-Only Watchdog Model for Unidirectional Communication”?

In unidirectional environments, the “start_only” event phase of the heartbeat message can be used as a periodic watchdog signal. Each signal acts as a discrete confirmation of device health within a predefined timeout window. The Heartbeat Consumer monitors the arrival of these signals and infers device status based on their presence or absence, triggering alerts if expected signals are missed.

I understand the limitations of such an implementation. For example, the periodicity and timeout values should be carefully selected based on the criticality of the device and the clinical workflow requirements. However, I think this approach could broaden the applicability of PCMC across a wider range of medical device connectivity scenarios.

@GongliW: Thanks for your comments. IMHO, no mutual reliable communication can be established in this case. When a low-power sensor wakes up every 5 minutes and reports its data (vital signs, alerts, etc.) to the consumer, but cannot receive the state of the consumer, it does not know if the consumer can process the data as intended (e.g. disseminate alerts to the caregiver's smart phones) between the reporting intervals. When the consumer knows the schedule of the data reports, it can only detect missing data when the time expired.
The idea of the PCMC is that both participants can mutually detect if the communication between them is reliable, even if there are currently no critical data to be reported and processed.

[PeterKranich]

Hi, I've reviewed with internal Baxter folks and we collectively have some questions/concerns/asks:

1. For Gateway HR examples, there's one example that has one device. A gateway can manage literally thousands of devices. How will this look for n > 1 devices? How many devices will fit in one DEV-53?
2. Say an HR sends a heartbeat and doesn't get an acknowledgement. Is there guidance on "how many" non-acks should occur before you say that communications are down/the HC is not responding and thus need to generate a technical alarm?
3. At line 375 it's mentioned that patient/location are not included in PCMC. Can we make a mention as to where those would otherwise be handled? Not specifically which other transactions but mostly that "other transactions take responsibility for tracking/updating" those things.
4. The term INOP is used which some folks understand what it means, but others do not, can we define this somewhere?
5. For Heartbeat Reporter we indicate what that role does. Throughout the document we refer to individual device, gateway proxy, etc. It might be clearer to list the types of HRs in the definition so that it is clear what those are referring to when referenced in use cases. It might also be useful for the Heartbeat Consumer to list some examples of what might be a consumer of these transactions.
6. In a separate email chain with you, you had provided some scenario diagrams for different use cases. Would it be useful to include something like that here?

@witkowb1: thanks for your comments. Please find my two cents below:

1. Technically, the gateway has two implementation choices in this case:
   a. it sends individual heartbeat messages on behalf of each individual pump and forwards the consumer state back to the particular pump. This would produce a lot of heartbeat messages.
   b. the gateway detects connection failures to its connected devices and sends e.g. "Pump 1 disconnected" alert messages to the alert manager. The heartbeat message only monitors the communication between the gateway and the consumer. When the gateway does not send heartbeats any longer, the consumer needs to know which devices are affected. If a gateway is responible for all pumps on "ICU West" and "ICU North" and if there is no heartbeat any longer, the alert manager may send a message "No alerts from all pumps available" to all caregivers which are assigned to "ICU West" and "ICU North" but not to caregivers which are assigned to "ICU East" and "ICU South".
2. This is an implementation/risk management decision of the individual device vendors. The device could show a low priority inop first and after 3 missing heartbeat acks it escalates the inop to a high priority.
3. Sure, I can mention that in a note that patient/location information are provided in other DEV profiles when reporting patient related data. Actually, we could also send these information with heartbeat message which are related to individual devices (or gateways which pass through heartbeat messages from their connected devices), but for the moment, we made the decision that the heartbeat message will not contain any patient/location information.
4. Ok - I thought this is a well-known term for technical issues ("inoperabel"). I can add this to the glossary.
5. I tried to describe the aggregation gateway vs. proxy gateway in the document including examples. Let's talk about how I can improve this in the next meeting.
6. Sure, I made these sketches in VISIO. I should probably use the drawing feature in Word, so that others can change it later.

[engelbert65]

Is there a reason why the term "receipt acknowledgement" is used instead of "accept acknowledgment", which is how it is referred to in HL7 table 0008?

[PeterKranich]

Is there a reason why the term "receipt acknowledgement" is used instead of "accept acknowledgment", which is how it is referred to in HL7 table 0008?

@engelbert65: this was a request from Monroe. I assume that the descriptions of the transactions are implementation-agnostic. In this case, the response on the request is an acknowledgement independent of the actually used message format.

[GongliW]

Thanks Monroe and Peter for the responses.

Agree that TCP/IP is inherently two-way communication, and that ACK/NACK is the only reliable mechanism to ensure data reception.

Beyond the use cases described in current PCMC, I think there are other scenarios where ACK/NACK is not necessary. For example, in a real-time surveillance system, it makes no sense using ACK/NACK, because if a message is missed the first time, it's already too late, the system will simply move on. Since the objective of the system is not building up a record of the patient's condition over time but just displaying what the patient condition right now, which is different from patient documentation in an EMR where we want as complete as possible a record in the flowsheet. In such case, surveillance system needs monitor the heartbeat to ensure the communication link remains active, but the reporter will simply ignore ACK/NACK even if received, since no actions will be triggered at the reporter side.

However, this may be outside the scope of PCMC, as you indicated.