PCIMProfile.txt

Integrating the Healthcare Enterprise 




IHE Patient Care Device Domain
Technical Framework Supplement

Point-of-Care Identity Management 
(PCIM)



Draft in preparation for Public Comment


Date:		<Issue Date>
Author:	IHE PCD Technical Committee, PCIM Work Group
Email:		pcd@ihe.net


Foreword
This is a supplement to the IHE Patient Care Device Domain Technical Framework <V7.0>. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.
This supplement is published on <Issue Date> for Public Comment. Comments are invited and may be submitted at http://www.ihe.net/<domain>/<domain>comments.cfm. In order to be considered in development of the Trial Implementation version of the supplement, comments must be received by <Month XX, 201X>. 
This supplement describes changes to the existing technical framework documents. 
?Boxed? instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume.
Amend section X.X by the following:
Where the amendment adds text, make the added text bold underline. Where the amendment removes text, make the removed text bold strikethrough. When entire new sections are added, introduce with editor?s instructions to ?add new text? or similar, which for readability are not bolded or underlined.

General information about IHE can be found at: www.ihe.net.
Information about the IHE Patient Care Device domain can be found at: http://www.ihe.net/Domains/index.cfm.
Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at: http://www.ihe.net/About/process.cfm and http://www.ihe.net/profiles/index.cfm.
The current version of the IHE Patient Care Device Domain Technical Framework can be found at: http://www.ihe.net/Technical_Framework/index.cfm.
<Comments may be submitted on IHE Technical Framework templates any time at http://ihe.net/ihetemplates.cfm. Please enter comments/issues as soon as they are found. Do not wait until a future review cycle is announced.


Table of Contents
Introduction to this Supplement	5
Open Issues and Questions	5
Closed Issues	6
General Introduction	7
Appendix A - Actor Summary Definitions	7
Appendix B - Transaction Summary Definitions	7
Glossary	7
Volume 1 ? Profiles	10
7 Point-of-Care Identity Management (PCIM) Profile	10
7.1 PCIM Actors, Transactions, and Content Modules	10
7.1.1 Actor Descriptions and Actor Profile Requirements	12
7.1.1.1 Device-Patient Association Reporter	12
7.1.1.2 Device-Patient Association Manager	12
7.1.1.3 Device-Patient Association Consumer	12
7.1.1.4 Device Registrant	12
7.2 Actor Options	12
7.3 Required Actor Groupings	13
7.4 Overview	13
7.4.1 Concepts	13
7.4.2 Use Cases	13
7.4.2.1 Use Case #1: Associating Device with Patient	13
7.4.2.1.1 Use Case #1 Associating Device with Patient: Process Flow	13
7.4.2.1.2 Use Case Description	13
7.4.2.1.3 Pre-conditions:	14
7.4.2.1.4 Main Flow:	14
7.4.2.1.5 Post-conditions:	14
7.4.2.2 Use Case #2: Disassociating Device From Patient	14
7.4.2.2.1 Description	14
7.4.2.2.2 Process Flow	14
7.4.2.3 Query for the Devices for a Patient	15
7.4.2.3.1 Description	15
7.4.2.3.2 Process Flow	15
7.4.2.4 Use Case #4 Query the Associated Patient for a Device	15
7.4.2.4.1 Description	15
7.4.2.4.2 Process Flow	15
7.4.2.5 Use Case #5 Device Registrant Registers a Device with the Device-Patient Association Manager	15
7.4.2.5.1 Description	15
7.4.2.5.2 Process Flow	15
7.4.2.6 Use Case #6 Query the Device Registrant for a list of candidate devices for an association	15
7.5 Security Considerations in the Use of This Proposed Profile	15
7.5.1 General IHE PCD Guidance	16
7.5.2 Risk Assessment and Mitigation for Device-Patient Association Profile	16
7.6 Cross Profile Considerations	16
Volume 2 ? Transactions	17
3.17 Assert Device-Patient Association [PCD-17]	17
3.17.1 Scope	17
3.17.2 Actor Roles	17
3.17.3 Referenced Standards	17
3.17.4 Interaction Diagram	17
3.17.4.1 Device-Patient Association Report	17
3.17.4.1.1 Trigger Events	18
3.17.4.1.2 Message Semantics	18
3.18 Assert Device-Patient Disassociation [PCD-18]	18
3.18.1 Scope	18
3.18.2 Actor Roles	19
3.18.3 Referenced Standards	19
3.18.4 Interaction Diagram	19
3.18.4.1 Device-Patient Disassociation Report	19
3.18.4.1.1 Trigger Events	19
3.18.4.1.1 Message Semantics	20
3.18.4.1.2 Expected Actions	20
3.18.4.2 Device-Patient Disassociation Acknowledgement	20
3.18.5 Security Considerations	20
3.19 Query Device-Patient Associations [PCD-19]	20
3.19.1 Scope	20
3.19.2 Actor Roles	20
3.19.3 Referenced Standards	21
3.19.4 Interaction Diagram	21
3.19.4.1 Device-Patient Association Query	21
3.19.4.1.1 Trigger Events	21
3.19.4.1.2 Message Semantics	22
3.19.4.1.3 Expected Actions	22
3.19.4.2 Device-Patient Association Query Response	22
3.19.4.2.1 Trigger Events	22
3.19.4.2.2 Message Semantics	22
3.19.4.2.3 Expected Actions	22
3.19.5 Security Considerations	22
3.20 Register Device [PCD-20]	23
3.20.1 Scope	23
3.20.2 Actor Roles	23
3.20.3 Referenced Standards	23
3.20.4 Interaction Diagram	24
3.20.4.1 MFN - Master File Notification - General	24
3.20.4.1.1 Trigger Events	24
3.20.4.1.2 Message Semantics	24
3.20.4.1.3 Expected Actions	24
3.20.4.2 ACK - General Acknowledgement	24
3.20.4.2.1 Trigger Events	25
3.20.4.2.2 Message Semantics	25
3.20.4.2.3 Expected Actions	25
3.20.5 Security Considerations	25
3.20.5.1 Security Audit Considerations	25
Appendix A. Proposed Messages	26
A.1 Report Device-Patient Association	26
A.1.1 Message Structure	26
A.1.2 Segments	26
A.1.2.1 MSH ? Message Header	26
A.1.2.2 PID ? Patient Identification	26
A.1.2.3 PV1 Patient Visit Information	27
A.1.2.4 OBR ? Order Request	27
A.1.2.5 OBX ? Observation (for Patient ID)	27
A.1.2.6 PRT ? Participation (Observation Participation)	28
A.2 Example Messages	30
A.3 Device-Patient Association Query Message	32
A.3.1 Scope	32
A.3.2 Use Case Roles	32
A.3.3 Device-Patient Association Query Message	33
A.3.3.1 MSH Segment	33
A.3.3.2 QPD Segment	33
A.4 Device-Patient Association Query Response Message	34
A.4.1 MSH Segment	35
A.4.2 MSA Segment	35
A.4.3 QAK Segment	35
A.4.4 QPD Segment	35
A.4.5 Remaining Segments	35
A.5 Register Deviceevice	35
A.5.1 Message Structure	36
A.5.2 Segments	36
A.5.2.1 MSH ? Message Header	36
A.5.2.2 MFI ? Master File Identification Segment	36
A.5.2.3 MFE ? Master File Entry	36
A.5.2.4 PRT ? Participation Information Segment	37

Introduction to this Supplement
This Supplement to the IHE Patient Care Device Technical Frameworks adds the rationale and implementation details of the Point-of-Care Identity Management Profile to the Framework, providing a means for standards-based exchange between systems of information collected and confirmed at the point of care tracking the set of medical devices originating observations about each patient. 
Open Issues and Questions
The work group solicits feedback on workflow effects and problems found in analyzing the profile and in trial implementation.
Closed Issues
Discuss differences from previous approaches based on ADT messages: will be faster, closer to the actual events than ADT feeds, which have a different purpose and are often not well synchronized with actual events at the point-of-care. Will enable devices, device controllers and a variety of other hospital systems to flexibly exchange information, publish or subscribe to change notifications.
General Introduction
Update the following Appendices to the General Introduction as indicated below. Note that these are not appendices to Volume 1.
Appendix A - Actor Summary Definitions
Add the following actors to the IHE Technical Frameworks General Introduction list of Actors:

Actor
Definition
Device-Patient Association Reporter
A system or person that asserts a device-patient association, disassociation, or attributes related to either such as current state or starting and ending times..
Device-Patient Association Manager
A system that records, manages, and serves records of device-patient associations.
Device-Patient Association Consumer
A system or person that queries a Device-Patient Association Manager for device-patient association records, either as a snapshot of current associations or as a subscription for ongoing updates.
Device Registrant
A system (including the device itself) or person that, when the device is set up for use by a Device-Patient Association Manager, uniquely identifies a device instance that may participate in device-patient associations.
Appendix B - Transaction Summary Definitions
Add the following transactions to the IHE Technical Frameworks General Introduction list of Transactions:

Transaction
Definition
Assert Device-Patient Association
A Device-Patient Association Reporter asserts to a Device-Patient Association Manager that a device has been associated with a patient, or updates data concerning a reported assertion.
Assert Device-Patient Disassociation
A Device-Patient Association Reporter asserts to a Device-Patient Association Manager that the association between a device and a patient has been terminated.
Query Device-Patient Associations
A Device-Patient Association Consumer sends a query to a Device-Patient Association Manager concerning the devices associated with a patient or set of patients currently or at a stated past time. The Device-Patient Association Manager responds with the requested information.
Register Device
A Device Registrant sends, updates, or deletes a record of identifying information on a device instance for storage and use by the Device-Patient Association Manager.
Glossary
Add the following glossary terms to the IHE Technical Frameworks General Introduction Glossary:
Glossary Term
Definition
Assertion
A statement that a certain premise is true, for example that a device has been prepared to collect data about a patient.
Binding
A process of associating two related elements of information.
Biometrics
A measurable physical characteristic or personal behavioral trait used to recognize the identity, or verify the claimed identity of a person.
Direct Association
A patient association established by the observation and recording of a physical connection of a device to the patient.
Direct Device-Patient Association Assertion
A claim of direct device-patient association based on evidence.
Indirect Device-Patient Association
A patient association asserted on the basis of a common attribute shared by a device and patient, such as a location.
Location-based Assertion
An assertion of an association between two objects (e.g. a patient and a device, device-to-device, patient-to-caregiver), based solely upon the co-location (e.g. same room and bed) of these two objects.
Observation-Patient Association
The assignment of a device measurement/parameter to a specific patient. Observation - patient associations are established through the connection relationship of a unique patient to a unique device at the point in time that the measurement was recorded by the device.
Device-Patient Association Conflict Notification
A message from a particular clinical IT system that it detects an inconsistency between different identity assertions. For example, a device and an intermediary system may be simultaneously asserting that a single data stream represents two different patients.
Device-Patient Record Linkage
The process of binding and/or associating a discrete patient record to a discrete device record.
Precondition
"What the system under analysis will ensure is true before letting the use case start."
Receiving System
In the context of PCIM, any system which is a consumer of device-patient association or observation messages, such as an electronic medical record system, device gateway, or a device at the point of care.
Record
The discrete representation of a specific and unique patient or the device in either the reporting or consuming system's database.
Strong Identity Assertion
A presumption of patient or device unique recognition using multiple factors that provides a high degree of accuracy and certainty (e.g., barcode, biometric).
Strong Identity Factors
An identifier designed to be unique (applies to only one person) and consistent over the appropriate domain for at least throughout the visit or encounter, for example, Medical Record Number or National ID number.
Unique Device Identifier
In the US, a unique identifier for a medical device that is recognized by the US FDA and which has a part that identifies the maker and model of the device (DI) and a part that identifies the particular instance of the device. More generally, any identifier which allows a particular device to be uniquely identified.
Weak Identity Assertion
A presumption of patient or device unique recognition using factors that provides a low degree of accuracy and certainty (e.g., name, location).
Weak Identity Factors
Factors which can contribute to identification, but typically are not unique to patient; for example, name, sex, date of birth.
Volume 1 ? Profiles
Add to Section ?
7 Point-of-Care Identity Management (PCIM) Profile
The Point-of-Care Identity Management (PCIM) Profile is a Transport Profile specifying HL7 v2 standard messaging for devices and IT systems at an acute-care point-of-care to exchange and synchronize information about the identity of specific devices collecting clinical information about a specific patient, to:
* Assist in the reliable association of the collected data to the proper patient record, based on first-hand observation and data entry by a person at the point of care, specifically designed to avoid wrong attribution of data from before or after the period of actual measurement on the patient.
* Assist in maintaining a correct ?census? of devices that frequently move between patients such as infusion pumps, and mechanical ventilators.
The messaging defined provides for capable devices to originate messages asserting association and disassociation to a particular patient, for human interface software components to afford users the opportunity to originate or confirm association or disassociation assertions, for one or more systems to receive and persist device-patient association information, to distribute reporting messages or receive and respond to queries about such associations.
7.1 PCIM Actors, Transactions, and Content Modules
This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A at http://www.ihe.net/Technical Framework/index.cfm.
Figure 7.1-1 shows the actors directly involved in the Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines.

Figure 7.1-1:  Actor Diagram

Table 7.1-1 lists the transactions for each actor directly involved in the Profile. To claim compliance with this Profile, an actor shall support all required transactions (labeled ?R?) and may support the optional transactions (labeled ?O?). 
Table 7.1-1:  Profile - Actors and Transactions
Actors
Transactions 
Optionality
Reference
Device-Patient Association Reporter
Report Device-Patient Association
R
PCD TF-2: 3.17

Report Device-Patient Disassociation
R
PCD TF-2: 3.18
Device-Patient Association Consumer
Query Device-Patient Associations
O
PCD TF-2: 3.19
Device Registrant 
Report Registered Device Details
R
PCD TF-2: 3.20
7.1.1 Actor Descriptions and Actor Profile Requirements
Requirements are documented in Transactions (Volume 2) and Content Modules (Volume 3). This section documents any additional requirements on profile?s actors.
7.1.1.1 Device-Patient Association Reporter
The Device-Patient Association Reporter actor 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.
7.1.1.2 Device-Patient Association Manager
The Device-Patient Association Manager actor represents a system that collects and persists information on what devices are or were connected to which 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.
7.1.1.3 Device-Patient Association Consumer
The Device-Patient Association Consumer actor 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. 
7.1.1.4 Device Registrant
The Device Registrant actor 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. 
The Device Registrant announces when a device is placed in or taken out of service, is relocated, and other events as required.
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. 
7.2 Actor Options
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.
7.3 Required Actor Groupings 
There are no required actor groupings specified in the Point-of-Care Identity Management (PCIM) profile.
7.4 Overview
7.4.1 Concepts
Properly validated associations between devices, and patients that the devices are sourcing observations for, are an essential underpinning for clinical surveillance and clinical decision support systems. Patient safety depends on certainty that the values being charted do not have gaps, or worse, data from the wrong patient.
This profile provides standards-based messages for communications about the beginning, end, and current state of intervals in which a device is associated with a particular patient. It uses HL7 version 2 messages, still the most common pattern in healthcare institutions for similar information such as patient demographics. It does not specify a particular configuration of systems for its functions, but rather describes roles which may be assigned to different systems according to the workflow in the institution. For example, selection of the patient and the devices could be accomplished on a module of an electronic medical record system, on a medical device such as a physiological monitor or ventilator with appropriate communication and display capabilities, or on a hand carried device controlling another healthcare information system.
7.4.2  Use Cases
7.4.2.1 Use Case #1: Associating Device with Patient
A Device-Patient Association Reporter asserts a device-patient association to a Device-Patient Association Manager.
7.4.2.1.1 Use Case #1 Associating Device with Patient: Process Flow
This use case can be driven by an authorized user responsible for entering, verifying, or both, the beginning and ending of an association between a device and a particular patient. The should be based on first person awareness of the situation at the point of care. Automatic Identification and Data Capture methods such as barcodes or RFID should be used to assist the workflow and increase data reliability to the maximum feasible extent. In certain circumstances and with appropriate risk analysis, the association may be automatically generated. For example, a device with its own ?admission? process, the act of manipulating the user interface at the point of care to ?admit? a patient to the device may be deemed a patient-safe way of generating validated information of this device-patient association. For another example, a device with a fixed location and a known patient associated with the location may be appropriate to originate a device-patient association.
These means of identification are specific to the clinical environment in question, and standard procedures of risk analysis at the institution should be applied to assure that patient safety is adequately protected.
7.4.2.1.2 Use Case Description
An authorized person at the point of care and able to see the patient and the devices has gathered and checked the unique identifying information for a patient and one or more devices that are designated to originate observations on that patient. Before being sent, the information is displayed to the operator for verification. Once verified, a message is originated by the Association with the following information:
* Patient identifier unique within the scope of the institution
* Method of data capture (for example, scanned device bar code and patient wrist band, fixed device location, etc.)
* Time parameters (typically effective begin time of the association. In the case where only a single set of observation from the device is expected, as for a spot-check monitor, the end time of the association is simultaneous with the beginning time)
* Authorized performing participant
7.4.2.1.3 Pre-conditions:
Patient is to be associated with a device for clinical observations. Patient has been assigned unique identifier at registration which has been collected and verified at the point of care. Device identify has been registered for use. The identities of patient and device(s) have been collected and verified by an authorized person.
7.4.2.1.4 Main Flow:
Device-Patient Association reporter originates a message with the specific information on the association and its time of beginning. When such an association message is received, the manager system is responsible for determining if any conflicting information is in the system and generating an appropriate error message to assist the responsible personnel in resolving the conflict.
7.4.2.1.5 Post-conditions:
After completion of this use case, an association record identifying the patient and the associated device and giving the start time of the association is created and persisted by the Device-Patient Association Manager.
7.4.2.2 Use Case #2: Disassociating Device From Patient
7.4.2.2.1 Description
At the time the device is no longer set up to make observations on the patient, the Device-Patient Association Reporter originates a message conveying this information to the Device-Patient Association Manager. It should be noted that even though this may be a less salient event at the point of care, completeness and accuracy of disassociation is as important to an accurate record and proper association of observations with patients. This is a key issue in risk analysis and in system design.
7.4.2.2.2 Process Flow
The Device-Patient Association Manager receives the information that the association between a particular patient and one or more devices no longer exists. An authorized operator may originate this message through a user interface. In some cases, the device itself is capable of determining that the association has been broken and can communicate this information directly to the Device-Patient Association Manager, or indirectly through the Device-Patient Association Reporter. It may be appropriate to note this event on a user interface and get confirmation that it is correct. It also could be appropriate to ask whether other devices on record as being connected to the same patient are still connected or not.
7.4.2.3 Query for the Devices for a Patient
7.4.2.3.1 Description
A Device-Patient Association Consumer may query a Device-Patient Association Manager for a list of devices associated with a particular patient at present, or at a designated time in the past, or more generally for a snapshot of the Device-Patient Association map.
7.4.2.3.2 Process Flow
For status display or for error-checking and diagnostic purposes, the Device-Patient Association Manager can respond to a targeted query by sending a query response message.
7.4.2.4 Use Case #4 Query the Associated Patient for a Device
7.4.2.4.1 Description
A device (or another system) may require the identity of the patient it is connected to, for display or other purposes, but not have this information available to it, so the profile provides for a Device-Patient Association Consumer actor to query the Device-Patient Association Manager for this information.
7.4.2.4.2 Process Flow
The identity of the patient associated with a device (or the lack of an associated patient identity) may be queried for.
7.4.2.5 Use Case #5 Device Registrant Registers a Device with the Device-Patient Association Manager
7.4.2.5.1 Description
Identification and supporting information about a device may be registered with the Manager.
7.4.2.5.2 Process Flow
Before a device can participate in a Device-Patient Association, its identity and basic attributes such a device type, manufacturer and model, and additional identity information such as its regulatory Unique Device Identifier are provided by the Device Registrant to the Device-Patient Association Manager to be persisted and used in the other transactions in this use case.
7.4.2.6 Use Case #6 Query the Device Registrant for a list of candidate devices for an association
 A Device Registrant Actor in the present might be used by Device-Patient Association Reporter to allow presentation of a pick list of candidate devices to be paired with a patient
7.5 Security Considerations in the Use of This Proposed Profile
This profile itself does not impose specific requirements for authentication, encryption, or 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.
See the associated IHE PCD PCIM White Paper for additional discussion of some additional specific security concerns.
7.5.1 General IHE PCD Guidance on Security and Privacy
During the profile development there were no unusual security/privacy concerns identified. There are no mandatory security controls, but the implementer is encouraged to use of the underlying security and privacy profiles from ITI that are appropriate to the transports, such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed.
7.5.2 Risk Assessment and Mitigation for Device-Patient Association Profile
Any procedures, manual or automatic, affecting identification of patients and devices in a clinical scenario should of course be subject to analysis of risks and potential mitigations according to the institution?s established policies and procedures for analysis of safety, security, and privacy risk in general, in accordance with general risk analysis best practices. In addition to the risk of clinical data loss or data associated with the wrong patient discussed elsewhere in this document, any other hazards potentially arising from related activities should be taken into account. The profile described in this document cannot be assessed for effects on risk in isolation from the context in which it could be used, particularly routines for assigning unique patient identification codes and manual and automatic means for verifying patient identity during care to assure accuracy. Likewise recording unique device identification of devices and tracking procedures need to be assessed for assurance of correctness. This risk analysis should be carried out by a team including qualified persons in affected clinical and technology departments.
This document describes communications protocols but not full details of user interfaces and implementation of automated rules in actual systems for associating devices with patients, but these implementation details strongly affect the safety and effectiveness of the system in actual use, and therefore deserve careful evaluation.
The transactions described may carry highly sensitive identity and personal health information and could potentially be used wrongly if not appropriately secured in health information systems and on health information networks, so privacy is a critical aspect of risk analysis.
See the IHE PCD White Paper on Point-of-Care Identity Management Appendix C for additional risk analysis information including discussion of use of IHE Information Technology Infrastructure profiles for security.
7.6 Cross Profile Considerations
This profile specifically covers associations and disassociations between patients and devices. As patient demographics and ADT information (e.g., patient location) are often integral to satisfying the use cases profiled in this document, implementers should be familiar with the following profiles within the IT Infrastructure Technical Framework:
* Patient Administration Management profile
* Patient Demographics Query
* ITI Patient Demographic Query - Patient Demographic Reporter
A Patient Demographic Consumer in IT Infrastructure might be used by a Device-Patient Association Reporter to allow presentation of a pick list of candidate patients to associate with one or more devices at the point-of-care. 
Volume 2 ? Transactions
Insert in Section 3, as 3.17
3.17 Assert Device-Patient Association [PCD-17]
3.17.1 Scope
This transaction is used to by a Device-Patient Association Reporter to assert that an association has been established between a device and a patient, or to update information reported previously by that reporter.
3.17.2 Actor Roles
The Roles in this transaction are defined in the following table and may be played by the actors listed:
Table 3.17.2-1: Actor Roles
Actor:
Device-Patient Association Reporter
Role:
Reporter ? the source of the assertion. Identifies the device, the patient, the authority for the association, and the effective time.
Actor:
Device-Patient Association Manager
Role:
Manager ? establishes a persistent record of the association.
3.17.3 Referenced Standards
HL7 2.6 Chapters 2, 3, 5 and 7
3.17.4 Interaction Diagram

3.17.4.1 Device-Patient Association Report
This is an HL7 Version 2 message giving details of the association being asserted. The message may assert association between more than one device and one patient.
The manager may receive this message from multiple Reporter instances.
3.17.4.1.1 Trigger Events
This message is triggered at the beginning of an interval when the logical connection between a device and the data it originates and a particular patient is established, after that connection has been verified by a human user able to check its validity at the point of care.
3.17.4.1.2 Message Semantics
The significant content of the message is the following:
* Confirmed unique identity of patient, preferably derived from an AIDC (Automatic Identification and Data Capture) such as scanning the patient wristband or reading an RFID tag. Code used to identify the patient must be chosen so as to be unique at least over the scope of the set of patients seen over all information systems in the institution, such as a Medical Record Number issued by the institution for the patient, or, if available, a national id number. The type and issuing entity shall be recorded with the code. Additional identity codes may be provided at the discretion of the institution. Note that any code identifiable with an individual patient must by secured from misuse in accordance with applicable legal and policy procedures.
* Unique identity of Device. This again is determined by site considerations. It is preferable to use a universally unique identification of the individual instance of the device, such as an IEEE EUI-64 or a Unique Device Identifier such as one produced in accordance with the US FDA (or other regulatory agency) UDI standards. If this is not possible, then another universal identification scheme such as EUI-64 or a local identification scheme allowing all device instances in the institution to be uniquely distinguished and tracked may be used. Additional identification codes may be included. Whatever code is used should be possible to record automatically, as manual data entry has a high error rate, and correct identification is a patient safety concern.
* Identity of the authorized person responsible for obtaining and visually confirming the identity information for the patient and the device.
The form of the message is similar to an unsolicited observation report, with supplementary PRT segments identifying the device, human operator originating the association. See Appendix A.1 for details of HL7 V2 messages.
On receipt of the message, the manager system checks for valid syntax and that the:
1. originating Reporter system and human user are authorized for their roles
2. the device is a member of the set of registered device instances and has no current conflicting association recorded (e.g. a single-patient device has an active association with a different patient)
3. the patient identity provided corresponds to a known person in an appropriate status (e.g. admitted)
After these checks, the Manager logs the result and returns an appropriate positive or negative acknowledgement to the Reporter. 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. 
If the checks are passed, the Manager establishes a record of the existence of the association and its effective time.
3.18 Assert Device-Patient Disassociation [PCD-18]
3.18.1 Scope
This transaction breaks the association between a device and a patient, and causes an ending time to be inserted in the record of the former association.
3.18.2 Actor Roles
Table 3.18.2-1: Actor Roles
Actor:
Device-Patient Association Reporter
Role:
Reporter ? the source of the assertion. Identifies the device, the patient, the authority for the association, and the effective time.
Actor:
Device-Patient Association Manager
Role:
Manager ? establishes a persistent record of the association.
3.18.3 Referenced Standards
HL7 2.6 Chapters 2, 3, 5 and 7
3.18.4 Interaction Diagram

3.18.4.1 Device-Patient Disassociation Report
Reports that an association previously reported between a device and a patient no longer exists. This is the inverse of the Device-Patient Association Report. The two are similar in form and could have been defined as two variants of the same message, but have been given different names and discussed separately to emphasize differences in effects.
3.18.4.1.1 Trigger Events
This message can be triggered manually. The user interface could display information about the existing association, and an authorized person could select the association and give a command to end it.
If the equipment used has a means available to detect the termination of recording of data from a particular patient, this method could be used to give an operator warning that the association may have been ended, and offer the opportunity to confirm this and check whether other associations indicated as current for that patient are still valid.
3.18.4.1.1 Message Semantics
The significant content of this message are the identities of the device and the patient that are no longer to be associated, and the identity of the authorized person originating the message. See Appendix A.1for details.
3.18.4.1.2 Expected Actions
The Device-Patient Association Manager records the ending time of the association, persists the record of the time interval of the association, and sends a notification to information system with a subscription covering the event.
3.18.4.2 Device-Patient Disassociation Acknowledgement
The reply to the Device-Patient Disassociation Report is an ordinary HL7 Acknowledgement. 
3.18.5 Security Considerations
No special security or security audit considerations beyond the general ones already discussed apply to this transaction
3.19 Query Device-Patient Associations [PCD-19]
3.19.1 Scope
This transaction is used by a Device Patient Association Consumer to access device-patient association information held by a Device Patient Association Manager.
3.19.2 Actor Roles

Figure 3.19.2-1: Use Case Diagram

Table 3.19.2-1: Actor Roles
Actor:
Device-Patient Association Consumer
Role:
Requests information on Device-Patient Associations. This may be filtered for device, for patient, or for time interval. It may request a current ?snapshot? of active associations, or optionally for an ongoing feed of device-patient association information.
Actor:
Device-Patient Association Manager
Role:
Fulfills a request from a Device-Patient Association Consumer for device-patient association information in the manner specified by the Consumer
3.19.3 Referenced Standards
HL7 2.6 Chapters 2, 3, 5 and 7
3.19.4 Interaction Diagram

3.19.4.1 Device-Patient Association Query
This message from a Device-Patient Association Consumer requests a response from a Device-Patient Association Manager containing device-patient association data. A Device-Patient Association Manager is expected to be able to service multiple Device-Patient Association Consumer systems and manage different query and response streams and communications connections with each. Whether these communications ports are preconfigured, or dynamic with appropriate node identification and authorization for each connection request, is a matter of implementation design.
There are multiple use cases: 
1. A request for a ?current snapshot? of associations filtered as specified by the query parameters.
2. A request for an ongoing real-time feed of changes in associations.
3. Possibly less important would be request for a ?replay? of data from a specified time period in the past.
Trying to fit these cases with the array of patterns present in Chapter 5 (Queries) of the HL7 Specification presents some puzzles. This profile chooses the QSB publish-subscribe paradigm, matching option 1, as the general case and treats 2 and 3 as special cases of it using some special semantics of query parameters described below.
3.19.4.1.1 Trigger Events
This message is triggered by the Device-Patient Association Consumer when it requires information about a device or devices associated with a patient currently or in the past (within the period available from the Device-Patient Association Manager). It may also be used to request a continuing feed of data concerning changes in device-patient associations within the scope of the Device-Patient Association Manager.
3.19.4.1.2 Message Semantics
This message is a query specification. It gives the scope of the information wanted by the Device-Patient Association Consumer in response to the query: what patients, units, devices and time periods are pertinent. See Appendix A.4 for details of HL7 segment contents and semantics.
3.19.4.1.3 Expected Actions
The Device-Patient Association Manager is responsible for collecting, formatting and sending the requested information back to the querying Device-Patient Association Consumer according to the filtering specified in the query.
The management of the query and response connection between the Device-Patient Association Consumer and the Device-Patient Association Manager in the case of an ongoing subscription is an implementation detail, but 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 (within its time limits, if any). For a non-subscription, ?snapshot?-type query, the Device-Patient Association Manager could just respond on the static connection that the query comes in on.
3.19.4.2 Device-Patient Association Query Response
The response carries the requested data if the Device-Patient Association Manager has any matching the specification. If there is none available, the response is in effect an empty frame with zero data records in the position that data would be expected. If the request is ill-formed (incorrect syntax or impossible query specification), an indication of the nature of the error should be returned. 
3.19.4.2.1 Trigger Events
This message and the activity of preparing it, is triggered in the Device-Patient Association Manager by the query request from the Device-Patient Association Consumer. This trigger may request a snapshot of current state, or request the setting up of a sequence of messages triggered by a state change in the device-patient associations 
3.19.4.2.2 Message Semantics
The message is made up of a frame identifying the message, a read-back of the query parameters of the request, and the requested data represented as a set of observations portraying the pertinent device-patient association states.
This response may be part of a sequence of messages sent when device-patient association state transitions happen within the scope of the request from the Device-Patient Association Consumer that initiated. For detailed semantics and the construction of the HL7 message structure and segment contents, see Appendix A.5.
3.19.4.2.3 Expected Actions
The Device-Patient Association Consumer is expected to take actions depending on the reason it made the query request and its own business logic. An example would be for a device without its own selection and validation mechanism for identifying the patient it is interacting with to receive and use the information from the Device-Patient Association Manager to send that patient identity information with its observations or display the patient identity on its user interface.
3.19.5 Security Considerations
No special security or security audit considerations beyond the general ones already discussed apply to this transaction.
3.20 Register Device [PCD-20]
3.20.1 Scope
This transaction is used to report the introduction of a new device or the removal of a device to subscribing actors, including the Device Patient Association Manager. 
3.20.2 Actor Roles

Figure 3.20.2-1: Use Case Diagram
Table 3.20.2-1: Actor Roles
Actor:
Device Registrant
Role:
Maintains master file of medical devices that can be associated with a patient
Actor:
Device-Patient Association Manager
Role:
Maintains list of associations between devices and patients 
The Roles in this transaction are defined in the following table and may be played by the actors shown here:
Table 3.20.2-1 Actor Roles
Role:
Notifier
Actor(s):
The following actors may play the role of Notifier:
            Device Registrant: Notify subscribers of updates to the Device Master
Role:
Subscriber
Actor(s):
The following actors may play the role of Subscriber:
Device-Patient Association Manager: Update local list of devices available for association with a patient
Transaction text specifies behavior for each Role. The behavior of specific Actors may also be specified when it goes beyond that of the general Role.

3.20.3 Referenced Standards
HL7 2.6 Chapters 2 and 8.
3.20.4 Interaction Diagram

3.20.4.1 MFN - Master File Notification - General 
This message is sent by the device registrant to notify the Device-Patient Association Manager that a device has been added, removed, deactivated or reactivated from the inventory of bedside medical devices.
3.20.4.1.1 Trigger Events
M13 - Master File Notification ? General
Any change to the list of bedside medical devices available for assocation to a patient:
* Device added to the list
* Device removed from the list
* Device deactivated, and temporarily unavailable for association
* Device reactivated
3.20.4.1.2 Message Semantics
This message is an HL7 V2 Master File Notification. With this message, the Device Registrant actor notifies subscribers, such as the Device-Patient Association Manager, of additions, deletions, deactivations and reactivations of bedside medical devices.
3.20.4.1.3 Expected Actions
Because of receiving this message, recipients should update their local device lists as appropriate. 
As an example: if the recipient is a Device-Patient Association Manager, and the sender indicated the device was added to the master, then the Device-Patient Association Manager may offer this device to be a subject of the association with a patient.
Senders of this message are not expected to take any specific action, beyond preparing to receive an acknowledgement.
3.20.4.2 ACK - General Acknowledgement
This message is returned to acknowledge receipt of the MFN message.
3.20.4.2.1 Trigger Events
Upon receipt of a message that requires acknowledgement.
3.20.4.2.2 Message Semantics
This message is the HL7 V2 ACK message. 
3.20.4.2.3 Expected Actions
With this message, recipients are cleared to initiate the next transaction. As an example, if this message is sent to a Device Registrant, upon receipt the Device Registrant is clear to send the next Master File Notification message.
3.20.5 Security Considerations
No security considerations beyond the general ones already given are dictated.
3.20.5.1 Security Audit Considerations
No security audit considerations are dictated.
Appendix A. Proposed Messages
The descriptions of these messages do not repeat all information in the related sections of the IHE PCD TF-2 or the base HL7 specifications, which should be consulted for additional details. The base version of HL7 used in IHE PCD Profiles is version 2.6; however, this profile uses the semantics of the PRT segment which was not introduced until version 2.7 and not extended with full details of the Unique Device Identifier until version 2.8.2.
A.1 Report Device-Patient Association and Disassociation
As all of the use cases identified in this profile can be considered observations (it was observed that device d1 was connected to patient p1 starting at t1 and ending at t2), the ORU message structure is used throughout this profile to manage associations. This description also serves for a Report Device-Patient Disassociation ? the only difference between the Association and Disassociation messages is the content of OBX-5. The Message Structure and attendant notes also serve to specify the segment pattern to be expected in responses to PCD-019 Query for Device-Patient Associations messages. The prototype for the IHE Patient Care Device observations in this profile is the PCD-01 in the Device Enterprise Communication profile (IHE PCD TF-2: 3.1), which implementers should familiarize themselves with ? it serves as useful background information and contains details on some fields that are not covered in this profile.
A.1.1 Message Structure
Appendix Table 1: Report Device Patient Association
Segments
Description
MSH
Message Header
[{ SFT }]
Software Segment
[UAC]
User Authentication Credential
 PID
Patient Identification
 [PV1]
Patient Visit Information (for room bed)
  OBR
Observation Request
{
One group for each device being associated with patient identified in the PID
 OBX
Observation Result
 { PRT }
Participation ? One PRT segment for  device, one for responsible person
}
MSH, SFT, and UAC Segments: Same as in PCD-01 Profile.
In the context of this use case, the message is constrained to reporting association(s) for a single patient. This could be single device, single patient, or multiple devices associated to a single patient.
A.1.2 Segments
A.1.2.1 MSH ? Message Header
Since this message is effectively and unsolicited observation report, the contents of the MSH segment follow the specifications for PCD-01 in the IHE 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.
A.1.2.2 PID ? Patient Identification
In order to assert an association between a patient and a device, the PID segment is required. It identifies the patient who is associated to the device. The Patient Identifier List must contain an identifier that is unique for all patients within the scope of the system. By default, if an identifier on the list is identified as a medical record number, it is used (PID-3.5 Identifier Type code valued as ?MR?). There may be multiple identifiers in the list, and implementers may choose to allow a different identifier than the medical record number to be used as a configuration option.
Appendix Table 2: PID Fields
SEQ
DT
OPT
RP
Description
1
SI
O

Set ID - PID
3
CX
R
Y
Patient Identifier List
5
XPN
O
Y
Patient Name
7
DTM
RE

Gender
8
IS
RE

DOB
A.1.2.3 PV1 Patient Visit Information
See IHE PCD-01 for basic information (IHE PCD TF-2 Appendix B.6). In this profile, the PV1 segment is used to convey patient location information in PV1-3 Assigned Patient Location. This is also usable as a query filter to limit responses from the Device-Patient Association Query to matching locations.
A.1.2.4 OBR ? Order Request
This segment serves as a wrapper for an association observation. It gives the association message a unique identifier in the Filler Order Number OBR-3. This is a required field: it acts as an association object instance identifier for tracking is used for tracking messages from all sources in the overall configuration of systems, so it must be constrained by some method of generation that assures that duplicate identifiers between sources are not possible. It gives the timestamp of the beginning of the association (OBR-7), and when it is known, the end of the association (OBR-8). 
A.1.2.5 OBX ? Observation (for Patient ID)
This segment conveys the ?observation? that the patient has been associated to a device. It includes the time stamp of the association event and the device ID. A set of PRT segments accompanies it to convey the identity of the patient, the device, and the responsible observer. 
Appendix Table 3: OBX Fields
SEQ
DT
OPT
RP
Description
1
SI
O

Set ID - OBX
2
ID
R

Value Type ? set to CWE
3
CWE
R

Observation Identifier ? set to 68487^MDCX_ATTR_EVT_COND^MDC
4
ST
O

Observation Sub-ID. Use to convey a specific channel that?s been associated, as <MDS>.<VMD>.<CHANNEL>.<facet>
5
CWE
R

Observation Value. See Appendix Table 4: OBX-5 Values on page 28
11
ID
R

Observation Result Status. See Appendix Table 5: OBX-11 Values on page 28.
Appendix Table 4: OBX-5 Values
Observation Value
Description
0^MDCX_DEV_ASSOCIATE^MDC
Device has been associated to a patient.
0^MDCX_DEV_DISASSOCIATE^MDC
Device has been disassociated from a patient.
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).
Appendix Table 5: OBX-11 Values
 Status
HL7 Description
Adaptation
C
Record coming over is a correction and thus replaces a final result.
Record coming over is a correction and thus replaces a validated association.
D
Deletes the OBX record
Deletes the association record.
F
Final results; can only be changed with a corrected result.
Validated association. Can only be changed with a corrected association record.
R
Results entered -- not verified
An association has been asserted, but not validated.
W
Post original as wrong, e.g., transmitted for wrong patient.
Post original as wrong, e.g., transmitted for wrong patient.
A.1.2.6 PRT ? Participation (Observation Participation)
This segment conveys information about persons and/or devices that participated in the association, ancillary to the patient and device that are its subjects. There will be PRT messages identifying the patient, the device, and the responsible observer of a device-patient association following an OBX message as described in A.1.2.5. For example:
* A nurse that established and/or validated an association
* A device gateway
* The device itself, if the patient ID is entered directly onto the device
Appendix Table 6: PRT Fields
SEQ
DT
OPT
RP
Description
2
ID
R

Action Code. Always value to UC (unchanged).
4
CWE
R

Participation .
5
XCN

Y
Participation Person. If a person is the participant in this association message, his or her ID and name appear here.
9
PL

Y
Participation Location. Location where association was asserted or observed.
10
EI
C
Y
Participation Device. 
If a device is the initiator of this association record (PRT-4 = AUT), its ID appears here. Format is the same as in existing IHE PCD profiles and will match PRT-10 of device-as-subject PRT segment of this message, provided that the device associated with the patient and the device reporting the participation are one and the same (e.g., patient admitted on this monitor).
If this PRT segment identifies this device as the subject of the association (PRT-4 = EQUIP), its ID appears here. Note ? Prior to HL7 2.7, this would have appeared in OBX-18.
11
DTM
C

Participation Begin Date/Time (arrival time).
Refer to 
Appendix Table 9: PRT-12 Interpretation on page 31.
12
DTM
C

Participation End Date/Time (departure time).
Refer to Appendix Table 8: PRT-11 Interpretation on page 30.
13
CWE
O

Participation Quaitative Duration. Not used in this profile.
14
XAD
O

Participation Address
15
XTN
O

Participation Telecommunication Address
16
EI
O

 Participation Device Identifier.  From UDI, should be present if known. See discussion below.
17
DTM


Participation Device Manufacture Date. From UDI, should be present if known.
18
DTM
O

Participation Device Expiry Date. Not normally applicable in this profile.
19
ST
O

Participation Device Lot Number. Not normally applicable in this profile.
20
ST
C

Participation Device Serial Number. From UDI, should be present if known.
Appendix Table 7: PRT-4 Values
Participation
HL7 Description
Adaptation
AUT
AUT Author/Event Initiator
The participant (nurse, device, etc.), initially asserts the association.
EQUIP
Equipment
The participant is the device that is a subject of the device-patient association.
RO
Responsible Observer
The participant (nurse, etc.) observes an already asserted association as a prelude to adjusting, validating, or marking in error. 
PRT-10   Participation Device (EI)
PRT-10 should contain some form of identifier sufficient to uniquely identify the device within the scope of the overall system. This is a repeating field, so more than one identifier can be given. If available, it should have as one of its values the ?human readable form? of the Unique Device Identifier defined by the US FDA, where applicable, but in any case must contain See details in the UDI Final Rule (U.S. Food and Drug Administration 2013).
It should be noted that the use of OBX-18 for equipment identification has been deprecated. So for long-term use, the PRT segment is preferred. See the IHE TF-2 Appendix B.10.2 for details of how the PRT segment should be used for equipment identification.
Definition: Identifier for the device participating. This may reflect an unstructured or a structured identifier such as FDA UDI, RFID, IEEE EUI-64 identifiers, or bar codes.
If this attribute repeats, all instances must represent the same device.
Condition: At least one of the Participation Person, Participation Organization, Participation Location, or Participation Device fields must be valued.
If this field contains an FDA UDI, it shall contain the entire Human Readable Form of the UDI. For example, a GS1-based UDI would be represented as follows:
|(01)00643169001763(17)160712(21)21A11F4855^^2.16.840.1.113883.3.3719^ISO|
A HIBCC-based example would be represented as follows:
|+H123PARTNO1234567890120/$$420020216LOT123456789012345/SXYZ4567890123 45678/16D20130202C^^2.16.840.1.113883.3.3719^ISO
The identifier root shall be the OID assigned to UDI. For example, for FDA UDIs the root shall be 2.16.840.1.113883.3.3719, and the extension shall be the Human Readable Form appropriate for the style of content. When captured as a simple string, the string shall be the Human Readable Form appropriate for the style of content. The content style can be determined from the leading characters of the content:
UDIs beginning with: 	
	?(? are in the GS1 Human Readable style;
		?0-9? are a GS1 DI (containing only the DI value, no PI or GS1 AI);
	?+? are in the HIBCC Human Readable style;
	?=? or ?&? are in the ICCBBA Human Readable style.
Note: If ?&? is used in the UDI while one of the delimiters in MSH.2 includes ?&? as well, it must be properly escaped per Chapter 2.7 of the HL7 Specification.
The exchange of UDI sub-elements in PRT-16 through PRT-21 is not required when the full UDI string is provided in PRT.10. 
When a UDI is provided and sub-elements are also provided, then for those sub-elements that are valued, the content must match the content encoded in the UDI if it is encoded within the UDI. 
Caution: The UDI may contain personally identifying information in the form of the device serial number which may be used to link to other information on a patient. Standard practice for exchanging potentially identifying content should be exercised when exchanging UDIs which contain a serial number. 
Note:  PRT.10 is a repeating field. Additional device identifiers, such as an IEEE EUI-64 may also be contained in this field.
Appendix Table 8: PRT-11 Interpretation
Participation Status
AUT
EQUIP
RO
R-Asserted
Time that the person/device asserted the association between the patient and device.
Time that the device-patient association is asserted to have been established.
Unusual. Time that the person in this role observed the person/device in the AUT role asserting the association.
C-Corrected
n/a
Corrected time that the device-patient association is asserted to have been established.
Time that the person in this role issued the correction.
D-Deleted
n/a
n/a
Time that the person in this role issued the deletion order.
F-Validated
n/a
Time that the device-patient association is confirmed to have been established. If null, most recently asserted/corrected time has been confirmed.
Time that the person in this role validated the association.
W-Wrong
n/a
n/a
Time that the person in this role declared the association to be erroneous.
Appendix Table 9: PRT-12 Interpretation
Participation ?
?Status
AUT
EQUIP
RO
R-Asserted
Time that the person/device asserted the disassociation between the patient and device.
Time that the device-patient disassociation is asserted to have taken place.
Unusual. Time that the person in this role observed the person/device in the AUT role asserting the disassociation.
C-Corrected
n/a
Corrected time that the device-patient association is asserted to have ended.
Time that the person in this role issued the correction.
D-Deleted
n/a
n/a
n/a
F-Validated
n/a
Time that the device-patient association is confirmed to have ended. If null, most recently asserted/corrected time has been confirmed.
Time that the person in this role validated the disassociation.
W-Wrong
n/a
n/a
n/a
PRT-16   Participation Device Identifier (EI)
Definition: Provides the U.S. FDA UDI device identifier (DI) element.
This is the first component in the UDI and acts as the look up key for the Global Unique Device Identification Database (GUDID), and may be used for retrieving additional attributes.
When exchanging Device Identifiers (DI) the root shall be the OID, or standards? appropriate corollary to the OID, assigned to DI and the extension shall be the Human Readable Form of the content. For example, for DIs the root shall be:
	GS1 DIs: 	2.51.1.1
	HIBCC DIs:	1.0.15961.10.816
ICCBBA DIs:	2.16.840.1.113883.6.18.1.17 for Blood containers and 2.16.840.1.113883.6.18.1.34 otherwise.
Example:	|00643169001763^^2.51.1.1^ISO|

A.2 Device-Patient Association Query Message
A.2.1 Scope
This query allows a system to request a list of the device-patient associations meeting specified conditions. Note that ?snapshot? and ?subscription? request modes are supported.
A.2.2 Use Case Roles









A.2.3 Details of PCD-19 Device-Patient Association Query Message
This message is used by a Device-Patient Association Consumer to request device-patient association information from a Device-Patient Association Manager, specifying filtering by patient identification, by location or by device identification. It may also be limited to a particular time (often the time the message is originated), a time interval, or it may specify an open-ended time interval, signifying that the Device-Patient Association Consumer is requesting an ongoing real-time subscription to device-patient association information (possibly filtered as just described) that is received from Device-Patient Association Reporters. The query takes the form of a QSB publish and subscribe query as described in HL7 Chapter 5, Section 5.7.3.1. It is almost identical to the profile for the QSB^Z83^QSB_Q16 trigger with ORU^R01^ORU_R01 response trigger described in Section 5.7.3.1 of the HL7 specification except that the query parameters are different to accommodate the semantics of filtering for device-patient associations, and the observation reports given as the response to the query, while conforming to the ORU_R01 message structure, have the specific semantics of PCD-017 Device-Patient Association Reports. 
For identification, the arbitrary ?local? (i.e. not issued by the HL7 organization) trigger event Z66 is used for the query/subscription message. This applies for initial testing but is subject to change before this profile is submitted for final text.
 
Query Statement ID
Z66
Type
Publish
Query Name
Device Patient Association Query
Query Trigger
QSB^Z66^QSB_Q16
Query mode
Both
Response Trigger
ORU^R01^ORU_R01
Query Characteristics
Returns device-patient associations as constrained in the input parameters
Purpose
Sends device-patient association records, filtered as defined in input parameters
Response Characteristics
The response contains IHE PCD-17 device-patient association reports known to the Device-Patient Association Manager, filtered by the query parameters.
Based on Segment Pattern
R01 as constrained by IHE PCD-01 (see details in IHE PCD TF-2 3.1 and with the semantics of PCD-17 as in this profile.

QBP^Z66^QBP^QBP_Z66 Query Grammar: QBP Message
Segments
Segments
Description
HL7 Section Reference
MSH
Message Header Segment
2.15.9
[{SFT}]
Software Segment

[UAC]
User Authentication Credential
2.14.13
QPD
Query Parameter Definition
5.5.4
RCP
Response Control Parameter
5.5.6
For the segment pattern to be expected in the response to this query, see the definition of the ORU^R01 Message Structure in IHE PCD TF-2, which is a specialization of the ORU^R01 Message Structure in HL7 Chapter 7, Section 7.3.1, ORU ? Unsolicited Observation Message (Event R01), as follows:

Segments
Description
MSH
Message Header
[{ SFT }]
Software Segment
[UAC]
User Authentication Credential
 PID
Patient Identification
 [PV1]
Patient Visit Information (for room bed)
  OBR
Observation Request
{
One group for each device being associated with patient identified in the PID
 OBX
Observation Result
 { PRT }
Participation ? One PRT segment for  device, one for responsible person
}
Note that this segment pattern, unlike some segment patterns, is not introduced by any ?header? type extra segments, but instead is a straight sequenced of repeats of PCD-17 messages reporting device-patient association events, filtered according to the query parameters. This implies that it should be the same connection as the query was sent from the Device-Patient Association Consumer to the Device-Patient Association Manager, so there can be no confusion with other messages not from this profile. Since there is no end indication in the message sequence, either, in the case of a bolus query getting current state information (see the discussion under the RCP segment, RCP-3), the Device-Patient Association Manager will close the connection initiated by the Device-Patient Association Consumer when all the data have been sent. A new connection must then be connected if and when another query is sent.
A.2.3.1 MSH Segment
As for transaction PCD-01 in the IHE PCD TF-2 Appendix B.1, except that MSH-21 is valued as IHE_PCD_017^IHE PCD^1.3.6.1.4.1.19376.1.6.4.19^ISO.
A.2.3.2 QPD Segment
QPD - Query Parameter Definition
Mnemonic
Description
Type
Optionality
Length
Table
Repetition
QPD.1
Message Query Name
CE
Required
250
471
No
QPD.2
Query Tag
ST
Optional
32

No
QPD.3
User Parameters
VARIES
Optional
256

No
QPD.4
Action Code
ID


323
QPD Input Parameter Specification
Field
Seq
(Query ID=Z99)
Name
LEN
DT
OPT 
R/#
TBL
Segment 
Field Name
Element
Name
1
MessageQueryName
60
CWE
R



MessageQueryName
2
QueryTag
32
ST
R



QueryTag
3
User Parameters

ID
0

033

ActionCode
Identifiers for field, component, or subcomponent in QPD.3 User Parameters

FLD
ELEMENT NAME
PID.3.1
Patient Identifier List ? ID number
PV1.3.1
Assigned Patient Location ? Point of Care
PV1.3.2
Assigned Patient Location ? Room
PV1.3.3
Assigned Patient Location ? Bed
PRT.10
Participation Device
OBR.7
Observation Date/Time (start)
OBR.8
Observation End Date/Time
The QueryTag (QPD.2) is used to identify a query instance and therefore must be unique for each query.
The User Parameters field (QPD.3) is used to specify ?filtering? values, so that the query response can be limited to, for example, the records matching a particular Patient Identifier (by including a PID.3 specification), a particular device (by adding a Participation Device PRT specification) and so on. If multiple specifications are given, the responding system ?AND?s the specifications together, so that for example, a patient identifier and a device identifier specification result in the response only gives associations involving that patient and device.
The form of the User Parameters specifications in QPD.3 field uses one or more repetition of the CSC data type (separated by the HL7 repetition separator, by default the tilde character ~), one for each query parameter to be specified, with each repetition using the QSC data type. This data type takes the form of a component specifying the field, component, or subcomponent to filter on as @<seg>.<field number>.<component number>.<subcomponent number>, followed by a logical operator component (normally EQ for ?equals?), and a component giving the value sought for that field. An example would be:

 @PID.3.1.1^EQ^MR123~@PRT.10^EQ^PUMP1
This means limit the messages given in response to ones involving patient identifier MR123 and device identifier PUMP1.
The Device-Patient Association Manager is responsible for executing the search in accordance with the filters. The different query parameter filters are ANDed together, that is, only associations where all query parameters match the sought value will be sent by the Device-Patient Association Manager. 
Where the association records have query parameter fields that are repeated (as for example where multiple patient identifiers of different Identifier Types, or multiple device identifiers of different Identifier Types, are present), the Device-Patient Association Manager will consider the association record matched and send it if any value present in any repeat of the repeated field matches the sought value without regard to the Identifier Type.
A.A.1:   RCP Segment
RCP - Response Control Parameter
Field
Description
Type
Optionality
Length
Table
Repetition
1
Query Priority
ID
R
1
91
No
2
Query Limited Request

X



3
Response Modality
CNE




4
Execution and Deliver Time





5
Modify Indicatory
ID




RCP Response Control Parameter Field Description and Commentary
Field
Seq
(Query
ID=Z99)
Name
Component
Name
LEN
DT
Description
1
Query Priority

1
ID
Deferred / Immediate
2
Quantity Limited Request

10
CQ
Not applicable, this profile does not support continuation
3
Response Modality

60
CWE
Real time or Batch. Default is R.
5
Execution and Delivery Time


DTM
Only valued when RCP-1 Query Priority contains the value D (deferred)
6
Modify Indicator

The possible values for RCP-1, Query Priority, are:

Value
Description
Comment
D
Deferred

I
Immediate
Quantity limited requests are not supported, so RCP-2 Quantity Limited Request value is not used.
The supported values of RCP-3 Response Modality are R (Real Time) or T (Bolus). In real-time mode, association records are sent as they arrive at the Device-Patient Association Manager. In bolus mode all the available associations are sent at once. The Device-Patient Association Consumer wanting a continuous real-time feed of association events may need to make a bolus query first to get all existing associations meeting the desired filter specification to get the starting state.
Because the segment pattern has no start or end indication, the Device-Patient Association Manager will signal the completion of a bolus query by closing the connection to the Device-Patient Association Consumer. The Device-Patient Association Consumer will then make a new connection for the real-time continuing query.
RCP-4 Execution and Delivery Time is required when RCP-1 contains the value of RCP-1 D (Deferred). It specifies when the response is to be returned. 
RCP-5 Modify Indicator specifies whether a new subscription is being requested (value: N), or a modification is being made to an existing subscription (M). QPD-4 Action Code can signify the deletion of a subscription with a value of D.
Cancelling a Subscription
A subscription may be explicitly cancelled by the Device-Patient Association Consumer by sending a QSX^J66^QSX_J01 message, which is simply an MSH segment containing that string as MSH-9, followed by a QID segment identifying the subscription being cancelled with QID Query Identification Segment containing in field QID-1 the Query Tag (from QPD-2 of the original query establishing the subscription) and in QID-2 the Message Query Name (from QPD-1 of the original query).
A.3 Register Device
These messages are used to report the introduction of a new device or the removal of a device to subscribing actors, including the Device Patient Association Manager. 
As the list of devices available within the facility is best thought of as a master file, the HL7 Master File Notification paradigm is used. For lack of a better alternative, the PRT segment is used to convey device details. While most commonly used to indicate a device?s participation in an observation, it contains the necessary fields for device inventory and is used elsewhere in this profile.
A.3.1 Message Structure
Appendix Table 10: Report Device Patient Association
Segments
Description
MSH
Message Header
[{ SFT }]
Software Segment
[UAC]
User Authentication Credential
MFI
Master File Identification
{

 MFE
Master File Entry
 PRT
Participation
}
MSH, SFT, and UAC Segments: Same as DEC Profile.
A.3.2 Segments
A.3.2.1 MSH ? Message Header
MSH-9 is valued to MFN^M14^MFN_PRT
A.3.2.2 MFI ? Master File Identification Segment
This segment identifies the master file as the Device Master.
Appendix Table 11: MFI Fields
SEQ
DT
OPT
RP
Description
1
CWE
R

Master File Identifier ? Value to INV (Inventory)
2
HD
O
Y
Master File Application Identifier ? Value to ?Device Registrant?
3
ID
R

File-Level Event Code ? Value to UPD (Update)
6
ID
R

Response Level Code ? Value to NE (No application level response needed)
A.3.2.3 MFE ? Master File Entry
This segment communicates the event corresponding to the device record.
Appendix Table 12: MFE Fields
SEQ
DT
OPT
RP
Description
1
ID
R

Record-Level Event Code (See table below)
4
HD
R
Y
Primary Key Value (Hospital designated device identifier)
5
ID
R
Y
Primary Key Value Type (Value to CWE)
6
DTM
O

Entered Date/Time
7
DTM
O

Effective Date/Time
Appendix Table 13 ? Record Level Event Codes
Value
Description
MAD
Device added to inventory list
MDL
Device deleted from inventory list
MUP
Device information updated
MDC
Device deactivated, but remains on inventory list
MAC
Deactivated device reactivated
A.3.2.4 PRT ? Participation Information Segment
The Participation Information Segment contains device information details. Use the PRT segment details as in Appendix section A.1.2.6.
A.4 Example Messages
Example 1: At 12:00, Nurse Diesel connected patient Spaniel to a continuous physiological monitor with ID MON5588. At 12:30, she records the association on the Critical Care application. As she is an RN and has witnessed and entered the association on the Critical Care system, this is considered a validated association. This message would be sent from the Critical Care system in the role of Association Reporter to the Association Manager.

MSH|^~\&|CritCare||AssocMgr||20160726123002||ORU^R01^ORU_R01|12d15a9|P|2.7|||AL|AL||8859/1|||IHE_PCD_017^IHE PCD^1.3.6.1.4.1.19376.1.6.4.17^ISO
PID|||AB60001^^^A^PI||Spaniel^C^R^^^^L
PV1||E|3 WEST ICU^3001^1
OBR|||15404652
OBX|1|CWE|68487^MDCX_ATTR_EVT_COND^MDC||0^MDCX_DEV_ASSOCIATE^MDC||||||F
PRT|1|UC||EQUIP||||||3 WEST ICU^3001^1|MON5588^^231A8456B1CB2366^EUI-64|20160726120000
PRT|2|UC||RO|58793^Diesel^N||||3 WEST ICU^3001^1||20160726123000
The Association Manager first responds with the following commit level acknowledgment.

MSH|^~\&|AssocMgr||CritCare||20160726123002||ACK^R01^ACK||P|2.7
MSA|CA|12d15a9
Once the association is fully processed, the Association Manager responds by initiating the following application level acknowledgment

MSH|^~\&|AssocMgr||CritCare||20160726123003||ACK^R01^ACK|AM52E123|P|2.7|||AL|NE||8859/1|||IHE_PCD_017^IHE PCD^1.3.6.1.4.1.19376.1.6.4.17^ISO
MSA|AA|12d15a9
To which the Association Reporter responds with a commit level acknowledgement, completing the exchange.

MSH|^~\&|CritCare||AssocMgr||20160726123003||ACK^R01^ACK||P|2.7
MSA|CA|AM52E123
Example 2: At 16:00, Nurse Ratched connected patient McMurphy to a continuous physiological monitor with ID MON5596. She enters his patient ID on the monitor and presses a button causing the association to be asserted.

MSH|^~\&|MonitorGateway||AssocMgr||20160726160000||ORU^R01^ORU_R01|12d1574|P|2.7|||AL|AL||8859/1|||IHE_PCD_017^IHE PCD^1.3.6.1.4.1.19376.1.6.4.17^ISO
PID|||AB60001^^^A^PI||McMurphy^R^P^^^^L
PV1||E|3 WEST ICU^3001^1
OBR|||15404697
OBX|1|CWE|68487^MDCX_ATTR_EVT_COND^MDC||0^MDCX_DEV_ASSOCIATE^MDC||||||R
PRT|1|UC||EQUIP||||||3 WEST ICU^3001^1|MON5588^^231A8456B1CB2366^EUI-64|20160726160000
PRT|1|UC||AUT||||||3 WEST ICU^3001^1|MON5588^^231A8456B1CB2366^EUI-64|20160726160000


(Acknowledgment messages not shown)

The Association Manager may then broadcast this information to subscribers (such as Critical Care), or its clients (such as Critical Care) may query for this information, depending on how the systems are integrated.
At 16:45, she confirms the association on the Critical Care application (or the Association Manager, depending on how the systems are integrated). This message would be sent from the Critical Care system in the role of Association Reporter to the Association Manager.

Example 3. A new monitor with hospital assigned key MON5588 is registered. It is located at 3 West ICU, Room 3001, Bed 1.
MSH|^~\&|DeviceMaster||AssocMgr||20160726160000||MFN^M14^MFN_PRT|12d1574|P|2.7|||AL|AL||8859/1|||IHE_PCD_020^IHE PCD^1.3.6.1.4.1.19376.1.6.4.20^ISO
MFI|INV|Device Registrant|UPD|||NE
MFE|MAD|||MON5588|CWE
PRT|1|UC||EQUIP|||||3 WEST ICU^3001^1|MON5588^^231A8456B1CB2366^EUI-64|20160726160000
Example 4. A device controller needs an ongoing feed of all devices connected to patient with identifier . The controller opens a subscription to the Device-Patient Association Manager to get a filtered device-patient information feed of the relevant data:

MSH|^~\&|||MonitoringGateway||AssocMgr||QSB^Q66^QSB_Q16||P|2.8|
QPD|Q66^Device-Patient Subscription|Q0044|@PID.3.1^AB60001|
RCP|I||R|||N|
The Device-Patient Association Manager responds by starting a continuous stream of PCD-17 Device-Patient Association messages, starting with message(s) giving the current device associations of the patient (which will require the Device-Patient Association Manager to access that information and format it in PCD-17 form).
 
MSH|^~\&|MonitoringGateway|||COMWEST||||ORU^R01^ORU_R01|4409|P|2.8|
PID|||4567^^^MPI^MR|....
OBR|....
OBX|...

To cancel the subscription, the Device-Patient Association Consumer can send the following cancel message:

MSH|
QID|Q0044|Q66^Device-Patient Subscription^HL7005|
IHE Patient Care Device Technical Framework Supplement ? Point of Care Identity Management (PCIM)
______________________________________________________________________________




Rev. x.x ? 20xx-MM-DD 	3	                       Copyright ¸ 2018: IHE International, Inc.