IHE IT Infrastructure Technical Framework Supplement. Patient Location Tracking Query (PLQ) Draft for Public Comment

Transcription

1 Integrating the Healthcare Enterprise 5 IHE IT Infrastructure Technical Framework Supplement 10 Patient Location Tracking Query (PLQ) 15 Draft for Public Comment 20 Date: April 17, 2013 Author: IHE-J IT Infrastructure Committee iti@ihe.net Copyright 2013: IHE International, Inc.

2 Foreword This is a supplement to the IHE IT Infrastructure Technical Framework 9.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 April 17, 2013 for Public Comment. Comments are invited and may be submitted at In order to be considered in development of the Trial Implementation version of the supplement, comments must be received by May 17, This supplement describes changes to the existing technical framework documents and where indicated amends text by addition (bold underline) or removal (bold strikethrough), as well as addition of new sections introduced by editor s instructions to add new text or similar, which for readability are not bolded or underlined. Boxed instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume: Replace Section X.X by the following: General information about IHE can be found at: Information about the IHE IT Infrastructure domain can be found at: Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at: and The current version of the IHE IT Infrastructure Technical Framework can be found at: Rev Copyright 2013: IHE International, Inc.

3 CONTENTS Introduction to this Supplement... 5 Open Issues and Questions... 5 Closed Issues... 5 General Introduction... 7 Appendix A - Actor Summary Definitions... 7 Appendix B - Transaction Summary Definitions... 7 Glossary... 7 Volume 1 Profiles... 8 Copyright Licenses... 8 Domain-specific additions... 8 X Patient Location Tracking Query (PLQ) Profile... 9 X.1 PLQ Actors, Transactions, and Content Modules X.1.1 Actor Descriptions and Actor Profile Requirements X.2 PLQ Actor Options X.3 PLQ Actor Required Groupings X.4 PLQ Overview X.4.1 Concepts X.4.2 Use Case #1: Finding current patient location X.4.3 Use Case #2: Tracking patient s location using RFID X.5 PLQ Security Considerations X.6 PLQ Cross Profile Considerations Appendices Volume 2b Transactions Y1 Patient Location Feed [PLQ-x01] Y1.1 Scope Y1.2 Actor Roles Y1.3 Referenced Standards Y1.4 Interaction Diagram Y1.5 Security Considerations Y2 Patient Location Query [PLQ-x02] Y2.1 Scope Y2.2 Use Case Roles Y2.3 Referenced Standards Y2.4 Interaction Diagram Appendices Appendix P Examples of Messages P.x Example of Patient Location Tracking Query P.x.1 Example of transaction PLQ-x01: Patient Location Feed P.x.1.1 Messages P.x.2 Example of transaction PLQ-x02: Patient Location Query P.x.2.1 Messages Rev Copyright 2013: IHE International, Inc.

4 95 Volume 2 Name Space Additions Volume 3 Content Modules Volume 4 National Extensions Rev Copyright 2013: IHE International, Inc.

5 Introduction to this Supplement The Patient Location Tracking Query (PLQ) Integration Profile provides an integration solution to find the physical location (PL) of patients. A physical location can be mapped to the service delivery location (SDL). An implementation may support SDL with this profile, e.g., using an appropriate code system of locations which relates PL to SDL. A PL may be shared by more than one SDL. It is up to an implementation to define their relationship if it decides to support SDL with this profile. IHE does not specify a mapping of PL to SDL. Open Issues and Questions How to profile the PL/PV/MSH How PL should be constrained in this profile (which components of the HL7 message should be optional/prohibited/required)? The document of MSH components is still in this document. This will be removed and made reference to the ITI Framework section on message headers unless a specific need header need for PLQ is identified. RFID (passive RFID at doorway) Passive RFID cannot identify arriving or leaving. The HL7 message encodings for PL are all locations. How should this encoding be extended to accommodate the conveyance of patient went through this doorway? Transitions like this may be directionless or directional. Doorways with RFID are often found in corridors and other areas where there is no room number or department location to be associated. Message type for Query Is it necessary to use a specific trigger event or should we use custom query tag? Closed Issues Assumption of location information: Assumptions of location information can be implemented on actors in PLQ when a location of patient A is undefined (e.g., When patient A left location-a one hour ago and not detected at any place, Patient Location Manager may be able to assume patient A is waiting at location-b). In this version, we do not consider such assumptions. Boundary for the PLQ (Intra or Inter-enterprise): Intra only. Desired location information in PLQ: A physical location can be mapped to the service delivery location (SDL). An implementation may support SDL with this profile, e.g., using an appropriate code system of locations which relates PL (Physical Location) to SDL. RFID Tag ID - Patient ID mapping: PLQ Profile does not specify the mapping between RFID Tag ID and Patient ID. Rev Copyright 2013: IHE International, Inc.

6 Communication between RFID system and PLQ actors: PLQ profile does not specify the communication between RFID system and PLQ actors. Mapping of PL to SDL PLQ Profile does not specify a mapping of PL to SDL. History of movement: PLM must have the latest location at least. PLM may keep prior locations. PLC will be able to query by the range of date and time. Rev Copyright 2013: IHE International, Inc.

7 General Introduction Update the following Appendices to the General Introduction as indicated below. Note that these are not appendices to Volume Appendix A - Actor Summary Definitions Add the following actors to the IHE Technical Frameworks General Introduction list of Actors: Actor Patient Location Manager Patient Location Supplier Definition Tracks patient location that is sent from Patient Location Supplier and be inquired by Patient Location Consumer Feeds patient location to Patient Location Manager Patient Location Consumer Queries patient location to Patient Location Manager Appendix B - Transaction Summary Definitions 150 Add the following transactions to the IHE Technical Frameworks General Introduction list of Transactions: Transaction Patient Location Feed [PLQ-x01] Patient Location Query [PLQ-x02] Definition is used to notify the patient location that is send from Patient Location Supplier to Patient Location Manager is used to query the patient location from Patient Location Consumer to Patient Location Manager Glossary 155 Add the following glossary terms to the IHE Technical Frameworks General Introduction Glossary: RFID Glossary Term Definition (Radio-Frequency Identification) is a technology that uses radio waves to transfer data from an electronic tag, called RFID tag or label, attached to an object, through a reader for the purpose of identifying and tracking the object. Rev Copyright 2013: IHE International, Inc.

8 Copyright Licenses Volume 1 Profiles 160 Add the following to the IHE Technical Frameworks General Introduction Copyright section: NA Domain-specific additions NA 165 Add Section X to Volume 1 Rev Copyright 2013: IHE International, Inc.

9 X Patient Location Tracking Query (PLQ) Profile The Patient Location Tracking Query (PLQ) is the integration profile that collects the patient location information in a hospital, and provides his/her recently recognized location to other subsystems. The area PLQ covers is the patient location tracking inside single facilities, not between two or more hospitals. There is no systemized mechanism that records the latest location of the patients in a hospital due to the lack of standardized method to collect it. The Patient Location Tracking Query (PLQ) Integration Profile standardizes the transactions, manages patients' locations, and provides the latest information upon request from external subsystems. Patient locations are recognized by PLQ suppliers, and received/managed by PLQ manager. A new transaction [PLQ-x01] is used for Patient Location Feed. Request for a patient location is sent from PLQ consumer to PLQ manager using a new Patient Location Query [PLQ-x02]. PLQ suppliers can be many small systems from different vendors that specialize for certain exams where individual small room is assigned. A patient can be traced whether he/she has left/arrived from/at the physical location, and PLQ manager will know the last location he/she was identified. Rev Copyright 2013: IHE International, Inc.

10 X.1 PLQ Actors, Transactions, and Content Modules 185 Figure X.1-1 shows the actors of PLQ and the relevant transactions among them. Broken lines show the actor and the transaction indirectly involved in PLQ. 190 Patient Demographics Supplier Patient Location Feed [PLQ-x01] Patient Identity Management [ITI-030] Patient Demographics Consumer Patient Location Manager Patient Location Query [PLQ-x02] 195 Patient Location Supplier Patient Location Consumer Figure X.1-1: PLQ Actor Diagram 200 Table X.1-1 lists the actors and the transactions of PLQ. Transactions labeled R should be implemented to support PLQ. Actor groupings are further described in Section X.3. Table X.1-1: PLQ Profile - Actors and Transactions Actors Transactions Optionality Reference Patient Location Manager Patient Location Feed R ITI TF-2: 3.Y1.1 Patient Location Query R ITI TF-2: 3.Y2.1 Patient Location Supplier Patient Location Feed R ITI TF-2: 3.Y1.1 Patient Location Consumer Patient Location Query R ITI TF-2: 3.Y X.1.1 Actor Descriptions and Actor Profile Requirements X Patient Location Manager Patient Location Manager (PLM) shall respond location of patient and patient demographic information when queried from Patient Location Consumer. Patient demographic data on PLM should be updated by Patient Identity Management [ITI-30]. Rev Copyright 2013: IHE International, Inc.

11 210 X Patient Location Supplier Patient Location Supplier uses Patient Location Feed [PLQ-x01] to notify Patient Location Manager of the patient location information. X Patient Location Consumer 215 Patient Location Consumer inquires patient location information to Patient Location Manager using Patient Location Query [PLQ-x02]. Patient Location Manager replies the patient location information and the event time. X.2 PLQ Actor Options There are no options in the actors in PLQ. 220 Table X.2-1: PLQ - Actors and Options Actor Option Name Reference Patient Location Manager No options defined - - Patient Location Supplier No options defined - - Patient Location Consumer No options defined - - X.3 PLQ Actor Required Groupings Patient Location Manager is required to be grouped with ITI Patient Administration Management (PAM) Patient Demographics Consumer to update patient demographic information. 225 Table X.3-1: PLQ - Actors Required Groups PLQ Actor Required Grouping Actor Technical Note Framework Reference Patient Location Manager ITI Patient Administration Management (PAM) Patient Demographics Consumer ITI TF-1: Note 1 Note 1: Patient Location Manager may be provided with up-to-date patient data as soon as they need it, provided this data is available in the healthcare institution. Rev Copyright 2013: IHE International, Inc.

12 X.4 PLQ Overview X.4.1 Concepts It is common especially for aged patients to get consultation at multiple departments in a day. Finding the location of patients quickly is very important for the productivity and effective use of resources (staffs/devices/systems/ ) in a hospital. The Patient Location Tracking Query (PLQ) Integration Profile has the ability to track the whereabouts of patients in a hospital. There are two typical use cases described below. The first is a simple one describing how to find the patient location using PLQ, and the second is a case using RFID system that is considered effective for PLQ. X.4.2 Use Case #1: Finding current patient location 240 This section shows the workflow to find the location of a patient using PLQ. X.4.2.1Finding current patient location: Use Case Description 245 A CT scan of a patient Mr. Tanaka is scheduled at 10:00 am. But Mr. Tanaka has not arrived yet at the reception of the radiology department, so the staff cannot start the CT scan. To know the location of Mr. Tanaka, the staff of the radiology department uses a PLQ Consumer. The result shows that Mr. Tanaka was accepted at the outpatient department and has not left there yet. Therefore, they skip the CT scan of Mr. Tanaka and start a CT scan of Mr. Suzuki who has already been accepted at the radiology department. Rev Copyright 2013: IHE International, Inc.

13 250 Figure X : Finding Current Patient Location Rev Copyright 2013: IHE International, Inc.

14 X Finding current patient location: Process Flow 255 Patient Location Manager Patient Location Supplier Patient Location Consumer Patient Location Feed [PLQ-x01] 260 Patient Location Query [PLQ-x02] 265 Figure X : Basic Process Flow in PLQ Profile 270 X.4.3 Use Case #2: Tracking patient s location using RFID This use case shows how RFID (Radio-Frequency Identification) device works effectively in PLQ. This profile is not limited to use with RFID for location reporting. Any location reporting technology can be used. RFID is one very commonly deployed technology. X Tracking patient s location using RFID: Use Case Description Patient-Sato is scheduled to visit internal medicine department at 10:00 and ophthalmology department at 10:30. Patient-Suzuki is scheduled to visit ophthalmology department at 11:00. Patient-Sato checks in by hospital ID card. Patient-Sato enters a consultation room in the internal medicine department at 10:00 am. At 10:30, Patient-Sato is still in the internal medicine department. A reception staff of the ophthalmology department calls Patient-Sato. However, Patient-Sato is not in the lobby of the ophthalmology department. Rev Copyright 2013: IHE International, Inc.

15 The reception staff does not know whether Patient-Sato already finished the consultation at the internal medicine department. Then a doctor in the ophthalmology department waits for Patient- Sato for a while. At 10:45 am, Patient-Sato does not visit the ophthalmology department. The doctor starts a consultation of Patient-Suzuki. In these processes above, the ophthalmology department stops consultation and may loss about 15 minutes for waiting Patient-Sato and Patient-Sato has to wait at the ophthalmology department for a long time. RFID monitoring devices are installed at both the lobbies and the consultation rooms. Patients always carry the RFID-tag in this hospital. At 10:30, the doctor in the ophthalmology department checks the location of Patient-Sato with PLQ integration profile. The doctor quickly finds that the Patient-Sato is still in the internal medicine department and skips Patient-Sato. The doctor finds the next patient who is waiting at the lobby and calls Patient-Suzuki for next patient. Patient-Suzuki needs not wait for a consultation. Before introducing PLQ, the ophthalmology physician has to stop consultation and may lose some time to wait Patient-Sato. Patient-Sato has to wait at the ophthalmology department for a long time. 300 Figure X : Tracking patient s location using RFID Rev Copyright 2013: IHE International, Inc.

16 X Finding current patient location: Process Flow 305 Patient Location Manager Patient Location Supplier Patient Location Consumer Patient Location Feed [PLQ-x01] 310 Patient Location Query [PLQ-x02] 315 Figure X : Finding current patient location: Process Flow 320 X.5 PLQ Security Considerations Location information of a patient in a hospital is privacy sensitive. PLQ profile does not specify a specific security requirement for actors. However the implementation should be considered carefully in order to protect the patient privacy information. X.6 PLQ Cross Profile Considerations 325 Three actors in PLQ may collect patient demographic information and that will be fed by Patient Demographics Supplier using Patient Identity Management [ITI-030]. Rev Copyright 2013: IHE International, Inc.

17 330 No new Volume 1 appendices. Appendices Rev Copyright 2013: IHE International, Inc.

18 Add section 3.Y1 Volume 2b Transactions 3.Y1 Patient Location Feed [PLQ-x01] 335 This section corresponds to Transaction PLQ-x01 of the IHE IT Infrastructure Technical Framework. Transaction PLQ-x01 is used by the Patient Location Supplier and Patient Location Manager. 3.Y1.1 Scope 340 This transaction communicates patient location information, including temporary location and event time. 3.Y1.2 Actor Roles Patient Location Supplier Patient Location Manager Patient Location Feed Figure 3.Y1.2-1: Use Case Diagram 345 Table 3.Y1.2-1: Actor Roles Actor: Role: Actor: Role: Patient Location Supplier Provides notification to the Patient Location Manager for any patient location related events including: arrive, depart, etc. Patient Location Manager Serves patient location information provided by Patient Location Supplier. 3.Y1.3 Referenced Standards HL7 Version 2.5: Chapter 2 Control, Chapter 3 Patient Administration, Chapter 15 Personnel Management Rev Copyright 2013: IHE International, Inc.

19 350 3.Y1.4 Interaction Diagram Patient Location Supplier Patient Location Manager Patient Location Feed: HL7 ADT^A09 or A10 3.Y1.4.1 Patient Location Feed 3.Y Trigger Events The following events from a Patient Location Supplier Actor will trigger one of the Patient departing or Patient arriving messages: A09 Patient departing from temporary location. A10 Patient arriving to temporary location. 3.Y Message Semantics The Patient Location Feed transaction is conducted by the HL7 ADT message, as defined in the subsequent sections. The Patient Location Supplier Actor shall generate the message whenever a patient is departing or arriving from/to temporary locations. The segments of the message listed below are required, and their detailed descriptions are provided in the following subsections. Required segments are defined below. Other segments are optional Table 3.Y : ADT Patient Administration Messages ADT Patient Administration Message Chapter in HL7 2.5 MSH Message Header 2 EVN Event Type 3 PID Patient Identification 3 PV1 Patient Visit 3 Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT message to its sender. See ITI TF-2x: C.2.3, Acknowledgement Modes, for definition and discussion of the ACK message. Rev Copyright 2013: IHE International, Inc.

20 370 3.Y MSH - Message Header Segment Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, Message control ) This segment defines the intent, supplier, destination, and some specifics of the syntax of the message. It also uniquely identifies the message itself and dates its production. 375 Table 3.Y : MSH - Message Header SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 1 ST R [1..1] Field Separator 2 4 ST R [1..1] Encoding Characters HD R [1..1] Sending Application HD R [1..1] Sending Facility HD R [1..1] Receiving Application HD R [1..1] Receiving Facility 7 26 TS R [1..1] Date/Time of Message 8 40 ST X [0..0] Security 9 15 MSG R [1..1] Message Type ST R [1..1] Message Control Id 11 3 PT R [1..1] Processing Id VID R [1..1] Version ID NM O [0..1] Sequence Number ST X [0..0] Continuation Pointer 15 2 ID X [0..0] Accept Acknowledgement Type 16 2 ID X [0..0] Application Acknowledge 17 3 ID RE [1..1] Country Code ID C [0..1] Character Set CE RE [1..1] Principal Language of Message ID X [0..0] Alternate Character Set Handling Scheme EI RE [0..*] Message Profile Identifier 380 MSH-1 Field Separator, Required: This Integration Profile requires that applications support any ASCII value for field separator as specified in the HL7 standard. The value suggested by HL7 is (ASCII 124). MSH-2 Encoding Characters, Required: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. This Integration Profile requires that applications support any ASCII values for encoding characters as specified in the HL7 standard. The values suggested by HL7are ^~\& (ASCII 94, 126, 92, and 38, respectively). Rev Copyright 2013: IHE International, Inc.

21 MSH-3 Sending Application (HD) and MSH-5 Receiving Application (HD), Required: See the constrainable profile definition of data type HD. MSH-4 Sending Facility (HD) and MSH-6 Receiving Facility (HD), Required: See the constrainable profile definition of data type HD. MSH-9 Message Type (MSG), Required: Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)> Definition: This field contains the message type, trigger event, and the message structure ID for the message. All three components are required. MSH-10 Message Control Id (ST), Required: Definition: This field contains a number or other identifier that uniquely identifies the message in the context of exchange between trading partners. Each message should be given a unique identifier by the sending system. The receiving system will echo this ID back to the sending system in the Message Acknowledgment segment (MSA). The combination of this identifier and the name of the sending application (MSH-3) should be unique across the healthcare enterprise. MSH-12 Version ID (VID), Required: Components: <Version ID (ID)> ^ <Internationalization Code (CE)> ^ <International Version ID (CE)> Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. The first component SHALL be populated with the value "2.5" representing HL7 Version 2.5. MSH-15 Accept Acknowledgment Type (ID) Not supported. MSH-16 Application Acknowledgment Type (ID) Not supported. MSH-17 Country Code (ID), Required if available. Definition: This field contains the country of origin for the message. The values to be used are 345 those of ISO 3166, using the 3-character alphabetic form. Refer to HL7 Table Country code. Examples of valid values: JPN = Japan, USA = United States, GBR = United Kingdom, ITA = Italy, FRA = France, NLD = Netherlands. 350 MSH-18 Character Set (ID), Conditional. Definition: This field contains the character set for the entire message. Refer to HL7 Table Alternate character sets for valid values. Examples of valid values: ASCII: The printable 7-bit ASCII character set. Rev Copyright 2013: IHE International, Inc.

22 /1: The printable characters from the ISO 8859/1 Character set used by Western Europe. This character set can still be used, but 8859/15 should be used by preference. This character set is the forward-compatible version of 8859/1 and includes new characters such as the Euro currency symbol. ISO IR87: Code for the Japanese Graphic Character set for information interchange (JIS X ). UNICODE UTF-8: UCS Transformation Format, 8-bit form. Condition predicate: This field shall only be valued if the message uses a character set other than the 7-bit ASCII character set. Though the field is repeatable in HL7, IHE authorizes only one occurrence (i.e., one character set). The character set specified in this field is used for the 365 encoding of all of the characters within the message. MSH-19 Principal Language of Message (CE), Required if available. Coded from ISO 639. Examples: DE = German, EN = English, ES=Spanish, JA = Japanese, FR = French, NL = Dutch, IT = Italian MSH-20 Alternate Character Set Handling Scheme (ID), Not supported: Character set 370 switching is not allowed here. MSH-21 Message Profile Identifier (EI), Required if available. This field shall be valued in the messages for which a Message Profile has been officially registered with HL7. When multiple message profiles are listed in this field, they should be vendor specific and/or country specific message profiles constraining the official one. 3.Y EVN Event Type Segment 440 Standard Reference: HL7 Version 2.5, Chapter 3, section This segment is used to provide generic properties of the trigger event. Table 3.Y : EVN Event Type segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 3 ID X [0..0] Event Type Code 2 26 TS R [1..1] Recorded Date Time 3 26 TS O [0..1] Date/Time Planned Event 4 3 IS O [0..1] Event Reason Code XCN O [0..*] Operator ID 6 26 TS R2 [0..1] Event Occurred HD RE [0..1] Event Facility 445 EVN-1 Event Type Code (ID): Not supported (deprecated in HL7 2.5). The Event Type Code is given in MSH-9 of segment MSH. Rev Copyright 2013: IHE International, Inc.

23 EVN-2 Recorded Date Time (TS): Required. Date/time when the event was recorded. EVN-6 Event Occurred (TS): This field contains the date/time that the event really occurred. Condition predicate: This field shall not be populated in messages communicating pending events and their cancellations. In messages communicating effective events (inserts and updates), this field shall be populated with the real date/time of the notified event. In messages communicating cancellations, this field shall be populated with the date/time that was sent in the message that originally communicated the event being cancelled. EVN-7 Event Facility (HD): Required if known to the sender. This field identifies the actual facility where the event occurred as distinct from the sending facility (MSH-4). 3.Y PID - Patient Identification segment 460 Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.2) The PID segment is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently. Table 3.Y : PID - Patient Identification segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 4 SI O [0..1] Set ID - PID 2 20 CX X [0..0] Patient ID CX R [1..*] Patient Identifier List 4 20 CX X [0..0] Alternate Patient ID - PID XPN O [1..*] Patient Name XPN O [0..1] Mother s Maiden Name 7 26 TS O [0..1] Date/Time of Birth 8 1 IS O [1..1] Administrative Sex XPN X [0..1] Patient Alias CE O [0..1] Race XAD O [0..*] Patient Address 12 4 IS X [0..1] County Code XTN O [0..*] Phone Number - Home XTN O [0..*] Phone Number - Business CE O [0..1] Primary Language CE O [0..1] Marital Status CE O [0..1] Religion CX O [0..1] Patient Account Number ST X [0..1] SSN Number - Patient Rev Copyright 2013: IHE International, Inc.

24 SEQ LEN DT Usage Card. TBL# ITEM# Element name DLN X [0..1] Driver's License Number - Patient CX O [0..*] Mother's Identifier CE O [0..1] Ethnic Group ST O [0..1] Birth Place 24 1 ID O [0..1] Multiple Birth Indicator 25 2 NM O [0..1] Birth Order CE O [0..1] Citizenship CE O [0..1] Veterans Military Status CE X [0..0] Nationality TS O [0..1] Patient Death Date and Time 30 1 ID O [0..1] Patient Death Indicator 31 1 ID O [0..1] Identity Unknown Indicator IS O [0..*] Identity Reliability Code TS R2 [0..1] Last Update Date/Time HD O [0..1] Last Update Facility CE O [0..1] Species Code CE O [0..1] Breed Code ST O [0..1] Strain CE O [0..2] Production Class Code CWE O [0..*] Tribal Citizenship In accord with the HL7 Version 2.5 usage of this segment, fields PID-2 (Patient ID), PID-4 (Alternate Patient ID), PID-19 (SSN patient number) and PID-20 (Driver s license number) are superseded by field PID-3, as shown below; field PID-28 (Nationality) is superseded by field PID-26 (Citizenship). PID-3 Patient Identifier List (CX), Required. This field contains a list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient. As shown in the constrained profile definition of data type CX at the end of this supplement, subfields CX-1 ID number, CX-4 Assigning authority, and CX-5 Identifier Type Code are required for each identifier. This field may be populated with various identifiers assigned to the patient by various assigning authorities. The authorized values for subfield CX-5 Identifier Type Code are given in HL7 Table 0203 (HL7 Version 2.5, Chapter 2A, Section 2A.14.5). Values commonly used for Identifier Type Code in the context of PID-3 are as follows: 480 BC DL Bank card number. Assigning authority is the bank. Driver s license number. Assigning authority is the state. Rev Copyright 2013: IHE International, Inc.

25 485 NH PE PI PPN PRC SS National Health Plan Identifier. Assigning authority at the national level. Living Subject Enterprise Number. Assigning authority is the enterprise. Patient Internal Identifier assigned by the healthcare organization. Passport number. Permanent Resident Card Number. Social Security Number 3.Y PV1 - Patient Visit segment 490 Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.3) The PV1 segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis. Table 3.Y : PV1 - Patient Visit segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 4 SI O [0..1] Set ID PV1 2 1 IS R [1..1] Patient Class 3 80 PL O [0..1] Assigned Patient Location 4 2 IS O [0..1] Admission Type CX O [0..1] Preadmit Number 6 80 PL O [0..1] Prior Patient Location 10 3 IS O [0..1] Hospital Service PL R+ [0..1] Temporary Location 12 2 IS O [0..1] Preadmit Test Indicator 13 2 IS O [0..1] Re-admission Indicator 14 6 IS O [0..1] Admit Supplier 15 2 IS O [0..*] Ambulatory Status 16 2 IS O [0..1] VIP Indicator 18 2 IS O [0..1] Patient Type CX O [0..1] Visit Number FC O [0..*] Financial Class 21 2 IS O [0..1] Charge Price Indicator 22 2 IS O [0..1] Courtesy Code 23 2 IS O [0..1] Credit Rating 24 2 IS O [0..*] Contract Code 25 8 DT O [0..*] Contract Effective Date NM O [0..*] Contract Amount 27 3 NM O [0..*] Contract Period Rev Copyright 2013: IHE International, Inc.

26 SEQ LEN DT Usage Card. TBL# ITEM# Element name 28 2 IS O [0..1] Interest Code 29 4 IS O [0..1] Transfer to Bad Debt Code 30 8 DT O [0..1] Transfer to Bad Debt Date IS O [0..1] Bad Debt Agency Code NM O [0..1] Bad Debt Transfer Amount NM O [0..1] Bad Debt Recovery Amount 34 1 IS O [0..1] Delete Account Indicator 35 8 DT O [0..1] Delete Account Date 36 3 IS O [0..1] Discharge Disposition DLD O [0..1] Discharged to Location CE O [0..1] Diet Type 39 2 IS O [0..1] Servicing Facility 40 1 IS X [0..1] Bed Status 41 2 IS O [0..1] Account Status PL O [0..1] Pending Location PL O [0..1] Prior Temporary Location TS O [0..1] Admit Date/Time TS O [0..1] Discharge Date/Time NM O [0..1] Current Patient Balance NM O [0..1] Total Charges NM O [0..1] Total Adjustments NM O [0..1] Total Payments CX O [0..1] Alternate Visit ID 51 1 IS O [0..1] Visit Indicator XCN X [0..*] Other Healthcare Provider PV1-11 Temporary Location (PL), Required. This field contains reported patient temporary location. PV1-43 Prior Temporary Location (PL), Optional. This field contains patient prior temporary location. 3.Y Expected Actions Patient Location Supplier shall notify Patient Location Manager with ADT^A09 message when a patient leave a physical location in a hospital. ADT^A09 message shall contain information below: EVN-6 - Event Occurred departure time of patient Patient Location Supplier shall notify Patient Location Manager with ADT^A10 message when a patient arrive at a physical location in a hospital. Rev Copyright 2013: IHE International, Inc.

27 ADT^A10 message shall contain information below: EVN-6 - Event Occurred arrival time of patient Y1.5 Security Considerations Refer to Refer to X.5 PLQ Security Considerations. 3.Y1.5.1 Security Audit Considerations Refer to Refer to X.5 PLQ Security Considerations. 3.Y1.5.1.(z) Actor Specific Security Considerations 515 Refer to Refer to X.5 PLQ Security Considerations. Rev Copyright 2013: IHE International, Inc.

28 3.Y2 Patient Location Query [PLQ-x02] 3.Y2.1 Scope This transaction involves a request by the Patient Location Consumer Actor for information about patients whose location data match data provided in the query message. The request is received by the Patient Location Manager Actor. The Patient Location Manager Actor immediately processes the request and returns a response in the form of patient location information for matching patients. 3.Y2.2 Use Case Roles Patient Location Consumer Patient Location Manager Patient Location Query Actor: Patient Location Manager Role: Returns patient location information for all patients matching the location criteria provided by the Patient Location Consumer. Actor: Patient Location Consumer Role: Requests a list of patients matching a minimal set of location criteria (e.g., patient id, place in the hospital) from the Patient Location Manager. 3.Y2.3 Referenced Standards 530 HL7 Version 2.5: Chapter 2 Control, Chapter 3 Patient Administration, Chapter 5 Query Rev Copyright 2013: IHE International, Inc.

29 3.Y2.4 Interaction Diagram Patient Location Query Request: HL7 QBP^ZVx 3.Y2.4.1 Patient Location Query Request Y Trigger Events A Patient Location Consumer s need to select a patient based on tracking information about patients whose information matches a minimal set of known data will trigger the Patient Location Query based on the following HL7 trigger event: ZVx* Find Candidates from Tracking Information * need to confirm which ZVx is available. 3.Y Message Semantics The Patient Location Query transaction is conducted by the HL7 QBP^ZVx message. The Patient Location Consumer Actor shall generate the query message whenever it needs to select from a list of patients whose information matches a minimal set of tracking data. The segments of the message listed below are required, and their detailed descriptions are provided in the following subsections. Required segments are defined below. Other segments are optional Table 3.Y : QBP Query by Parameter ADT Patient Administration Message Chapter in HL7 2.5 MSH Message Header 2 QPD Query Parameter Definition 5 RCP Response Control Parameter Rev Copyright 2013: IHE International, Inc.

30 The receiver shall respond to the query by sending the RSP^ZVx message. This satisfies the requirements of original mode acknowledgment; no intermediate ACK message is to be sent. The Patient Location Query is always targeted at a multi-source of patient tracking information (referred to in this Transaction as the patient location supplier) Y MSH - Message Header Segment Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, Message control ) This segment defines the intent, supplier, destination, and some specifics of the syntax of the message. It also uniquely identifies the message itself and dates its production. 560 Table 3.Y : MSH - Message Header SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 1 ST R [1..1] Field Separator 2 4 ST R [1..1] Encoding Characters HD R [1..1] Sending Application HD R [1..1] Sending Facility HD R [1..1] Receiving Application HD R [1..1] Receiving Facility 7 26 TS R [1..1] Date/Time of Message 8 40 ST X [0..0] Security 9 15 MSG R [1..1] Message Type ST R [1..1] Message Control Id 11 3 PT R [1..1] Processing Id VID R [1..1] Version ID NM O [0..1] Sequence Number ST X [0..0] Continuation Pointer 15 2 ID X [0..0] Accept Acknowledgement Type 16 2 ID X [0..0] Application Acknowledge 17 3 ID RE [1..1] Country Code ID C [0..1] Character Set CE RE [1..1] Principal Language of Message ID X [0..0] Alternate Character Set Handling Scheme EI RE [0..*] Message Profile Identifier 565 MSH-1 Field Separator, Required: This Integration Profile requires that applications support any ASCII value for field separator as specified in the HL7 standard. The value suggested by HL7 is (ASCII 124). Rev Copyright 2013: IHE International, Inc.

31 MSH-2 Encoding Characters, Required: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. This Integration Profile requires that applications support any ASCII values for encoding characters as specified in the HL7 standard. The values suggested by HL7are ^~\& (ASCII 94, 126, 92, and 38, respectively). MSH-3 Sending Application (HD) and MSH-5 Receiving Application (HD), Required: See the constrainable profile definition of data type HD. MSH-4 Sending Facility (HD) and MSH-6 Receiving Facility (HD), Required: See the constrainable profile definition of data type HD. MSH-9 Message Type (MSG), Required: Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)> Definition: This field contains the message type, trigger event, and the message structure ID for the message. All three components are required. The first component shall have a value of QBP; the second component shall have a value of ZVx. The third component shall have a value of QBP_Q21. MSH-10 Message Control Id (ST), Required: Definition: This field contains a number or other identifier that uniquely identifies the message in the context of exchange between trading partners. Each message should be given a unique identifier by the sending system. The receiving system will echo this ID back to the sending system in the Message Acknowledgment segment (MSA). The combination of this identifier and the name of the sending application (MSH-3) should be unique across the healthcare enterprise. MSH-12 Version ID (VID), Required: Components: <Version ID (ID)> ^ <Internationalization Code (CE)> ^ <International Version ID (CE)> Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. The first component SHALL be populated with the value "2.5" representing HL7 Version 2.5. MSH-15 Accept Acknowledgment Type (ID), Not supported. MSH-16 Application Acknowledgment Type (ID), Not supported. MSH-17 Country Code (ID), Required if available. Definition: This field contains the country of origin for the message. The values to be used are 345 those of ISO 3166, using the 3-character alphabetic form. Refer to HL7 Table Country code. Examples of valid values: JPN = Japan, USA = United States, GBR = United Kingdom, ITA = Italy, FRA = France, NLD = Netherlands. 350 Rev Copyright 2013: IHE International, Inc.

32 MSH-18 Character Set (ID), Conditional. Definition: This field contains the character set for the entire message. Refer to HL7 Table Alternate character sets for valid values. Examples of valid values: ASCII: The printable 7-bit ASCII character set. 8859/1: The printable characters from the ISO 8859/1 Character set used by Western Europe. This character set can still be used, but 8859/15 should be used by preference. This character set is the forward-compatible version of 8859/1 and includes new characters such as the Euro currency symbol. ISO IR87: Code for the Japanese Graphic Character set for information interchange (JIS X ). UNICODE UTF-8: UCS Transformation Format, 8-bit form. Condition predicate: This field shall only be valued if the message uses a character set other than the 7-bit ASCII character set. Though the field is repeatable in HL7, IHE authorizes only one occurrence (i.e., one character set). The character set specified in this field is used for the 365 encoding of all of the characters within the message. MSH-19 Principal Language of Message (CE), Required if available. Coded from ISO 639. Examples: DE = German, EN = English, ES=Spanish, JA = Japanese, FR = French, NL = Dutch, IT = Italian MSH-20 Alternate Character Set Handling Scheme (ID), Not supported: Character set 370 switching is not allowed here. MSH-21 Message Profile Identifier (EI), Required if available. This field shall be valued in the messages for which a Message Profile has been officially registered with HL7. When multiple message profiles are listed in this field, they should be vendor specific and/or country specific message profiles constraining the official one. 3.Y QPD Query Parameter Definition Segment 630 The Patient Location Consumer Actor shall send attributes within the QPD segment as described in Table 3.Y Table 3.Y : QPD Query Parameter Definition segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 3 CE R [1..1] Message Query Name 2 32 ST R+ [1..1] Query Tag 3 QIP R [1..1] Query Fields Adapted from the HL7 standard, version 2.5 Rev Copyright 2013: IHE International, Inc.

33 QPD-1 Message Query Name (CE): Required: The Consumer shall specify IHE PLQ Query. QPD-3 Query Fields (QIP): Required: Field QPD-3-Query Fields-Related Fields consists of one or more repetitions, each of which contains two components that together contain the name and value of a distinct parameter to the query. Acceptable segments are PID, PD1 and PV1. The first component of each parameter contains the name of an HL7 element in the no>.<component no>.<subcomponent no> The above format is populated according to common HL7 usage for specifying elements used in query parameters, as follows: <seg> represents a 3-character segment ID from the HL7 Standard. <field no> is the number of a field within the segment as shown in the SEQ column of the segment attribute table for the segment selected. <component no>, for fields whose data types contain multiple components, shall contain the cardinal number of the component being valued. For fields whose data types do not contain multiple components, <component no> shall not be valued and its preceding period should not appear. <subcomponent no>, for components whose data types contain multiple subcomponents, shall contain the cardinal number of the subcomponent being valued. For components whose data types do not contain multiple subcomponents, <subcomponent no> shall not be valued and its preceding period shall not appear. The second subcomponent of each parameter contains the value that is to be matched. The Patient Location Consumer may specify, and the Patient Location Manager shall support, the fields in the following table. Table 3.Y : PLQ Profile QPD-3 fields required to be supported FLD Element name PID.3 Patient Identifier List PID.33 Last Update Date/Time 660 In addition, the Patient Location Manager should support the fields in the following table, and it shall support at least one of them. Some fields may not be relevant to particular care settings (e.g., inpatient, day patient) and will thus not be supportable by domains in those care settings. Table 3.Y : PLQ Profile QPD-3 fields recommended to be supported FLD Element name PID.5 Patient Name Rev Copyright 2013: IHE International, Inc.

34 FLD PV1.2 PV1.10 PV1.19 Element name Patient Class Hospital Service Visit Number The Patient Location Manager shall return demographic records that reflect the best fit to all of the search criteria. Examples of parameter expressions in QPD-3: Requests all patients whose Patient ID of PID-3-Patient Identifier List (data type CX) matches the value 12345, which location date of PID-33-Last Update Date/Time (data type TS) matches the value and whose patient class (PV1-2- Patient Class (data type IS)) matches the value Requests all patients whose point of care (second component (data type ST) PV1.11-Temporary Location (data type PL)) matches the value R Y RCP Response Control Parameter Segment 680 The Patient Location Consumer Actor shall send attributes within the RCP segment as described in Table 3.Y Fields not listed are optional. Table 3.Y : RCP Response Control Parameter Segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 1 ID R [1..1] Query Priority 2 10 CQ O [0..1] Quantity Limited Request Adapted from the HL7 standard, version RCP-1 Query Priority (ID): Required: Field RCP-1-Query Priority shall always contain I, signifying that the response to the query is to be returned in Immediate mode. RCP-2 Quantity Limited Request (CQ): Optional: The Patient Location Consumer Actor may request that responses to the query be sent, using the HL7 Continuation Protocol, in increments of a specified number of patient records. (In the context of the HL7 query, a patient record is defined as the PID segment and any segments accompanying it for each patient.) It is desirable to request an incremental response if the query could result in hundreds or thousands of matches or hits. Rev Copyright 2013: IHE International, Inc.

35 The Patient Location Manager Actor shall support the HL7 Continuation Protocol. Field RCP-2 is of data type CQ, which contains two components. The first component contains the number of increments, always expressed as an integer greater than 0, while the second component contains the kind of increment, always RD to signify that incremental replies are specified in terms of records. For example, 50^RD requests 50 records at a time. See the Incremental Response Processing section (3.Y ) and the Expected Actions section of the Patient Location Query Response message (3.Y ) for more information on the implementation of the continuation protocol. 3.Y Expected Actions 3.Y Immediate Acknowledgement The Patient Location Manager shall immediately return an RSP^ZVx response message as specified below in 3.Y.4.2, Patient Location Response. The RSP^ZVx response message incorporates original mode application acknowledgment as specified in the Acknowledgment Modes section (ITI TF-2x: C.2.3). The Supplier shall use Field MSH-3-Sending Application of the RSP^ZVx message to return the value it received from the Patient Location Consumer in Field MSH-5-Receiving Application of the QBP^ZVx message. 3.Y Query Parameter Processing The Patient Location Manager Actor shall be capable of accepting, searching on, and responding with attributes in the QPD segment as specified in Table 3.Y The Patient Location Manager Actor must be capable of receiving all valid combinations of subcomponents that make up the Assigning Authority component (i.e., all valid combinations of QPD-3.8). The Manager shall return at least all exact matches to the query parameters sent by the Consumer; IHE does not further specify matching requirements. 3.Y Incremental Response Processing 720 The Patient Location Manager Actor shall be capable of accepting and processing attributes in the RCP segment as listed in Table 3.Y In particular, the Patient Location Manager Actor shall respond in immediate mode (as specified by a RCP-1-Query Priority value of I). Also, the Patient Location Manager Actor shall be able to interpret RCP-2-Quantity Limited Request to return successive responses of partial lists of records according to the HL7 Continuation Protocol, as described in 3.Y2.4.2 below and in the HL7 Standard. Rev Copyright 2013: IHE International, Inc.