Newer version available

Transcription

1 General Practice Messaging Standard Version 3.0 May 2014 Copyright notice: The HL7 standard is protected by copyright. In order to use the standard and associated documents your organisation needs to be a member of the HL7 1

2 Date Version Change March First Version of Standard November See Appendix 7 for change history May See Appendix 7 for change history

3 About the The (HIQA) is the independent Authority established to drive high quality and safe care for people using our health and social care services. HIQA s role is to promote sustainable improvements, safeguard people using health and social care services, support informed decisions on how services are delivered, and promote person-centred care for the benefit of the public. The Authority s mandate to date extends across the quality and safety of the public, private (within its social care function) and voluntary sectors. Reporting to the Minister for Health and the Minister for Children and Youth Affairs, the Health Information and Quality Authority has statutory responsibility for: Setting Standards for Health and Social Services Developing person-centred standards, based on evidence and best international practice, for those health and social care services in Ireland that by law are required to be regulated by the Authority. Supporting Improvement Supporting health and social care services to implement standards by providing education in quality improvement tools and methodologies. Social Services Inspectorate Registering and inspecting residential centres for dependent people and inspecting children detention schools, foster care services and child protection services. Monitoring Healthcare Quality and Safety Monitoring the quality and safety of health and personal social care services and investigating as necessary serious concerns about the health and welfare of people who use these services. Health Technology Assessment Ensuring the best outcome for people who use our health services and best use of resources by evaluating the clinical and cost effectiveness of drugs, equipment, diagnostic techniques and health promotion activities. Health Information Advising on the efficient and secure collection and sharing of health information, evaluating information resources and publishing information about the delivery and performance of Ireland s health and social care services.

4 Overview of Health Information function Healthcare is information-intensive, generating huge volumes of data every day. Health and social care workers spend a significant amount of their time handling information, collecting it, looking for it and storing it. It is therefore imperative that information is managed in the most effective way possible in order to ensure a high quality, safe service. Safe, reliable healthcare depends on access to, and the use of, information that is accurate, valid, reliable, timely, relevant, legible and complete. For example, when giving a patient a drug, a nurse needs to be sure that they are administering the appropriate dose of the correct drug to the right patient and that the patient is not allergic to it. Similarly, lack of up-to-date information can lead to the unnecessary duplication of tests if critical diagnostic results are missing or overlooked, tests have to be repeated unnecessarily and, at best, appropriate treatment is delayed or at worst not given. In addition, health information has a key role to play in healthcare planning decisions where to locate a new service, whether or not to introduce a new national screening programme and decisions on best value for money in health and social care provision. Under section (8)(1)(k) of the Health Act 2007, the Health Information and Quality Authority (the Authority) has responsibility for setting standards for all aspects of health information and monitoring compliance with those standards. In addition, under section 8(1)(j), the Authority is charged with evaluating the quality of the information available on health and social care and making recommendations in relation to improving the quality and filling in gaps where information is needed but is not currently available. Information and communications technology (ICT) has a critical role to play in ensuring that information to drive quality and safety in health and social care settings is available when and where it is required. For example, it can generate alerts in the event that a patient is prescribed medication to which they are allergic. Further to this, it can support a much faster, more reliable and safer referral system between the patient s general practitioner (GP) and hospitals. Although there are a number of examples of good practice, the current ICT infrastructure in Ireland s health and social care sector is highly fragmented with major gaps and silos of information which prevents the safe, effective, transfer of information. This results in service users being asked to provide the same information on multiple occasions.

5 Information can be lost, documentation is poor, and there is over-reliance on memory. Equally, those responsible for planning our services experience great difficulty in bringing together information in order to make informed decisions. Variability in practice leads to variability in outcomes and cost of care. Furthermore, we are all being encouraged to take more responsibility for our own health and wellbeing, yet it can be very difficult to find consistent, understandable and trustworthy information on which to base our decisions. As a result of these deficiencies, there is a clear and pressing need to develop a coherent and integrated approach to health information, based on standards and international best practice. A robust health information environment will allow all stakeholders the general public, patients and service users, health professionals and policy makers to make choices or decisions based on the best available information. This is a fundamental requirement for a high reliability healthcare system. One of the areas currently being addressed through this work programme is the need to standardise the information shared between general practitioners and hospital consultant and administrative staff. This has been achieved through a General Practice Messaging Standard (GPMS). The Authority s GPMS is based on the international Health Level Seven (HL7) version 2.4 messaging standard. Version 1.0 of the GPMS was published in April 2010 and approved by the then Minister for Health and Children in May Version 2.0 of the GPMS was developed in 2011 to incorporate new requirements identified by stakeholders. Version 3.0 has been developed to include the messaging requirements for the electronic transfer of prescriptions between GP s and community pharmacy including the outpatient departments of hospitals.

6 Table of Contents 1 Introduction 9 2 Background 9 3 Message segments 11 4 Message flows 87 5 Electronic prescribing in the community General implementation comments Feedback on this document 124 Appendix 1 Feedback form 125 Appendix 2 Abstract message definitions 126 Appendix 3 Reference tables 134 Appendix 4 Healthlink to HL7 mapping 163 Appendix 5 LOINC Codes used for Referral Messaging in Ireland 164 Appendix 6 LOINC Copyright Notice and License 165 Appendix 7 Change History 172

7 Document layout To facilitate readers review of this consultation document, this section describes the layout of the document and provides a brief description of each of the sections in the document. Section 1 Introduction This section provides an introduction to the General Practice Messaging Standard (GPMS) and identifies the scope of the Standard and also what the Standard does not address. Section 2 Background This section provides a brief introduction to the reason for developing the GPMS and the process that was undertaken to develop this Standard. Section 3 Message segments This section describes each of the messaging segments used in the Standard. A segment is a logical grouping of data fields. Segments are the building-blocks for messages. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name. For example, the ADT message may contain the following segments: Message header (MSH), event type (EVN), patient ID (PID), and patient visit (PV1). Each segment is identified by a unique three-character code known as the segment ID. For each segment, a segment attribute table is provided to detail the fields in the segment including (but not limited to) sequence, length, usage and reference table details are supplied. The description column allows for further description and implementation details to be supplied. Section 4 Message flows Each individual message flow covered by the Standard is detailed in this section. A clinical-use case, an interaction model (including interaction diagram and interaction model) will be supplied. The abstract message definition and minimum segments will be detailed and, where an element of segment is specialised from the default segment specification, the detail will be documented. Section 5 Electronic prescribing in the community This section documents scenarios, clinical examples, message flows and use cases relevant to electronic prescribing in the community 7

8 Section 6 General implementation comments This section provides additional information on XML, the CE data type and the PID.32 element. Section 7 Feedback The Authority is fully committed to consulting on its work as widely as possible and invites comments and feedback on this document, using the form in Appendix 1. Appendix 1 Feedback form A feedback form is available to support end-users in providing comments and feedback on this document. Appendix 2 Abstract message structures This section lists the abstract message definitions used as the basis for work flows. Appendix 3 - Reference tables This section will detail the tables used in the Standard. For each table, the code to use and the code description will be supplied. Appendix 4 Healthlink to HL7 Mapping This section provides a mapping from Healthlink to HL7 Abstract Message Types. Appendix 5 LOINC Codes This section provides the LOINC codes for referral messaging in Ireland. Appendix 6 LOINC copyright notice and License This section recreates the LOINC copyright notice and License as published on the LOINC website, Appendix 7 Version Control This section lists the change history between the first and second version of the GPMS. 8

9 1 Introduction The General Practice Messaging Standard (GPMS) is a messaging standard intended to standardise the electronic transmission of messages between general practices, and secondary care and out-of-hours care. The GPMS focuses on the structure and content of electronic messages used to communicate between practice management systems of general practitioners and secondary care and out-of-hours care systems. The Standard defines messages segments and message flows. It also defines both the dynamic aspects (systems participating in the interchange and triggers which precipitate the interchange) and the static aspects (message structure and content). This Standard is an application-level specification and does not address lower level details. Specifically it does not address: choice of transport technologies encryption and authentication mechanisms infrastructure for addressing and routing of messages. 2 Background In 2009, the (the Authority) commenced work on the development of the GPMS standard for general practice messaging. To lead and oversee the process and advise the Authority, a multidisciplinary working group was convened including experts from practice management systems vendors, acute care information systems and messaging experts. The inaugural meeting of this group was held on 11 June The terms of reference for the working group were to: agree to adopt, adapt or develop a general practice messaging standard make recommendations on a mechanism for testing conformance to the standard make recommendations on a mechanism for amendments, version control, and timescale when the standard should be formally reviewed. The Authority, through its Health Information function, retains overall responsibility for the project and its management. 9

10 The Authority would like to thank the members of the working group for their input, and would like to thank Dr Brian O Mahony (GPIT) and Orla Doogue (Healthlink) in particular for the significant time and expertise they provided in developing the messaging standard. The membership of the working group included representation from the following organisations: Dr Brian O Mahony, General Practice Information Technology Group Malachy Stringer, Health Service Executive Julie Bellew, Health Service Executive Orla Doogue, National Healthlink Project Eleanor Crowley, National Cancer Registry Ireland Dr Kevin O Carroll, Louise Mc Quaid, Dr Donal Buckley, Irish College of General Practitioners Dr Ann Lynott, Irish College of General Practitioners Carl Beame, Complete GP Ltd Declan Rossiter, Health Ireland Partners Ltd Vincent Jordan, Health Service Executive Patrick O Neill, Freagra Gerard Hurl, Health Service Executive Michael Nerney, Health Service Executive Stephen Mulvany, Health Service Executive. Version 1.0 of the GPMS was published in April 2010 and approved by the then Minister for Health and Children in May Version 2.0 of the GPMS was developed to incorporate new requirements identified by stakeholders. Version 3.0 includes an update related to electronic transfer of prescriptions. 10

11 3 Message segments The GPMS standard specifies the structure and content of electronic messages transmitted to and from GP practices. To achieve this, the GPMS initially defines a set of building blocks for messages, known as message segments, which may be reused when constructing messages. A total of 25 message segments are detailed and are listed below. The MSH segment (message header) The PID segment (patient identification) The EVN segment (event) The PV1 segment (event type/ patient visit) The PV2 segment (event type additional information) The PRD segment (provider data) The DG1 segment (diagnosis) The NTE segment (notes and comments) The OBR segment (observation request) The OBX segment (observation result) The PDA segment (patient death and autopsy) The RGS segment (resource group) The AIP segment (appointment information personnel resources) The SCH segment (scheduling activity information ) The AIL segment (appointment information location resource) The ORC segment (common order segment) The RF1 segment (referral information) The SAC segment (specimen container detail) The MSA segment (message acknowledgement) The ERR segment (message error) The QRD segment (query definition) The QRF segment (query filter) The QAK segment (query response) The TXA segment (transcription document header) The DSC segment (continuation pointer) This section details each of the messages segments that may used in a message flow and the associated fields and rules. The message segment attribute table will be used to detail each of the segments. 11

12 Table 1 - Message segment attribute table HL7 Seq HL7 Element Name Max Len General Practice Messaging Standard Version 3.0 HL7 Opt Repeat Table Item # Data Type Below follows a description of each of the columns in the message segment attribute table. HL7 Seq This refers to the ordinal position of the field in the segment. In the segment attribute tables, this information is provided in the column labelled HL7 Seq. HL7 Element Name This refers to the name of the field as specified in the HL7 version 2.4 standard. The name is for reference purposes only and does not appear on the message data. In the segment attribute tables this information is provided in the column labelled HL7 Element name. Max Len This column details the maximum field length. For repeating fields it specifies the maximum length of each value, so a field with multiple repeating values may exceed the specified length. HL7 Data Type This column indicates the HL7 data type that must be used for the field. Information about HL7 data types may be found in Chapter 2 of the HL7 standard specification available at In the segment attribute tables this information is provided in the column labelled HL7 Data Type. Opt This column defines whether the field is required, optional, or conditional in a segment. In the segment attribute tables this information is provided in the column labelled Opt. A local implementation guide or local standard may make an optional field in HL7 a required field locally. A local implementation guide may not make a required 12

13 field in HL7 optional. If a HL7 field is required, not all of the field components need to be populated. The values listed in the table below are appropriate for the general practice messaging standard. A mapping to the Healthlink Online Messaging Specification (HOMS) is also provided. Table 2 - Mapping to HOMS Value HOMS mapping R Required If data is missing or incorrect, the message may not be delivered or may have limited value. O Optional Population of the field is optional. C Conditional The optionality of the field is conditional on the trigger event or on some other field(s) within the message. B Backward This element is retained for backward compatibility. X Not Used The element is in the base HL7 standard but is not used in the GP Messaging Standard. Repeating field RC RNC, O, OR C, RNC This column defines whether the field may repeat or not, or the number of repetitions supported. In the segment attribute tables this information is provided in the column labelled Repeat. The designations for repetition are detailed in table 3 below. Table 3 - Repeating field values Value N or blank no repetition allowed Y the field may repeat an indefinite or site-determined number of times (integer) the field may repeat up to the number of times specified by the integer Table B The table column of a segment attribute table specifies the HL7 identifier for a set of coded values. In the segment attribute tables, the table identifier is provided in the column labelled Table. An entry in the table number column means that the table name and the element name are equivalent. If this attribute is not valued or blank, there is not a table of values defined for the field. 13

14 HL7 defines table values in 3 ways: HL7 defined, user-defined and externally defined as follows: User-defined Tables: A user-defined table is a set of values that are locally or site defined HL7 Tables: A HL7 table is a set of values defined and published by HL7. They are a part of the HL7 Standard because they affect the interpretation of the messages that contain them. These values may not be redefined locally; however, the table itself may be extended to accommodate locally defined values External Tables: An external table is a set of coded values defined and published by another standards organisation. Item Number The item number is a small integer that uniquely identifies the data item throughout the Standard. In the segment definition this information is provided in the column labelled Item #. The description field adds additional information to the usage of the element. This information will be contained in the column. Not all fields in the HL7 segments are detailed in this standard. These fields are identified in the segment attribute tables with a description Not currently used and are also identifiable by a lighter font. 14

15 3.1 The MSH segment (message header) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. Table 4 - MSH Segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 MSH.1 - Field Separator 1 ST R This field contains the separator between the segment ID and the first real field, MSH-2-encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is, (ASCII 124). 2 MSH.2 - Encoding Characters 4 ST R This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. Recommended values are ^~\& (ASCII 94, 126, 92, and 38, respectively). 15

16 HL7 Seq HL7 Element Name 3 MSH.3 - Sending Application Max Len HL7 Data Type 180 HD R Opt Repeat Table Item # This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. This field further describes the sending application, MSH-3-sending application. The field structure is System or System.Middleware or System.Middleware.Message Number. The optionality of this field is further constrained than the HL7 standard optionality of (O). The HD datatype is used in fields that in earlier versions of HL7 used the IS data type. Thus, a single component HD (only the first component valued) will look like a simple IS data type for older systems expecting a single component in the place of the HD data type. If the first component for the HD data type is present, the second and third components are optional. If the third component is present, then the second must also be present (although in this case the first is optional). The second and third components must either both be valued (both nonnull), or both be not valued (both null).this means that if all three components of the HD are valued, the entity identified by the first component is the same as the entity identified by components two and three taken together. However, implementers may choose, by site agreement, to specify that if all three components of the HD are valued, the first component defines a member in the set defined by the second and third components. 16

17 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 3 MSH.3/HD.1 IS C 0361 The name of the sending application. This field further describes the sending application, MSH-3- sending application. The field structure is System or System.Middleware or System.Middleware.Message Number. 3 MSH.3/HD.2 ST C The code associated with the sending application. 3 MSH.3/HD.3 ID C The coding system used to identify the sending application. 4 MSH.4 - Sending Facility 180 HD R The field is used to define the health agency where the message originated. In the acute setting this may be the department or clinic, in the general practice setting this will be the general practice. This field further describes the sending application, MSH-3-sending application. The optionality of this field is further constrained than the HL7 standard optionality of (O). 4 MSH.4/HD.1 IS C 0362 The name of the sending facility. 4 MSH.4/HD.2 ST C The code associated with the sending facility. 4 MSH.4/HD.3 ID C The coding system used to identify the sending facility. 5 MSH.5 -Receiving Application 180 HD O This field uniquely identifies the receiving application among all other applications within the network enterprise. 5 MSH.5/HD.1 IS C 0361 The name of the receiving application. 5 MSH.5/HD.2 ST C The code associated with the receiving application. 5 MSH.5/HD.3 ID C The coding system used to identify the receiving application. 17

18 HL7 Seq HL7 Element Name Max Len HL7 Data Type 6 MSH.6 - Receiving Facility 180 HD R Opt Repeat Table Item # The field is used to define the health agency where the message is destined. In the acute setting this may be the department or clinic, in the general practice setting this will be the general practice. The optionality of this field is further constrained than the HL7 standard optionality of (O). 6 MSH.6/HD.1 IS C 0362 The name of the receiving facility. 6 MSH.6/HD.2 ST C The code associated with the receiving facility. 6 MSH.6/HD.3 ID C The coding system used to identify the receiving facility. 7 MSH.7 Date / Time Of Message 26 TS R 8 MSH.8 - Security 40 ST X 9 MSH.9 - Message Type 13 CM R This field contains the date/time that the sending system created the message. Not Currently Used. The first component is the message type code defined by HL7 Table Message type. This table contains values such as ACK, ADT, ORM, ORU etc.. The second component is the trigger event code defined by HL7 Table Event type. This table contains values like A01, O01, R01 etc.. 9 MSH.9/MSG.1 ID R 0076 This field is the message type code defined by HL7 Table Message type. This table contains values such as ACK, ADT, ORM, ORU etc.. MSH.9/MSG.2 ID R 0003 This field is the trigger event code defined by HL7 Table Event type. This table contains values like A01, O01, R01 etc.. 18

19 HL7 Seq HL7 Element Name 10 MSH.10 - Message Control ID Max Len HL7 Data Type Opt Repeat Table Item # 20 ST R This field contains a number or other identifier that uniquely identifies the message. 11 MSH.11- Processing ID 3 PT R 0103/02 07 The receiving system echoes this ID back to the sending system in the Message acknowledgment segment (MSA) where applicable This field is used to decide whether to process the message as defined in HL7 Application (level 7) Processing rules. 11 MSH.11/PT.1 ID R This should be set to P for live messages, T for training messages and D for debugging messages. 12 MSH.12 - Version ID 60 VID R The version id. This should be MSH.13- Sequence Number 15 NM X Not Currently Used. 14 MSH.14-Continuation 180 ST X Not Currently Used. Pointer MSH.15 - Accept 2 ID O 0155 This field identifies the conditions under which accept Acknowledgment Type acknowledgments are required to be returned in response to this message. Required for enhanced acknowledgment mode. 16 MSH.16 - Application 2 ID X 0155 Not Currently Used. Acknowledgment Type 17 MSH.17 - Country Code 3 ID O 18 MSH.18 - Character Set 16 ID X 19 MSH.19 - Principal Language Of Message 20 MSH.20 - Alternate Character Set Handling Scheme 21 MSH.21 - Conformance Statement ID 250 CE O 20 ID X 10 ID X Y This field contains the country of origin for the message. HL7 recommends using ISO table 3166 as the suggested values. Not Currently Used. This field contains the principal language of the message. HL7 recommends using ISO table 639 as the suggested values. Not Currently Used. Not Currently Used. 19

20 The PID segment (patient identification) 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 5 - Patient identification segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 PID.1 - Set ID - PID 4 SI O This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.. 2 PID.2 - Patient ID 20 CX X Not Currently Used. 3 PID.3 - Patient Identifier List 250 CX R Y This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient (e.g., medical record number, billing number, national unique individual identifier, etc.). 3 PID.3/CX.1 ST R The patient identifier. 3 PID.3/CX.4/HD.1 ST R 0363 The name of the authority that assigned the patient identifier. 3 PID.3/CX.4/HD.2 IS O The code of the assigning authority. 3 PID.3/CX.4/HD.3 ID O 0301 The coding system used to identify the assigning authority. (The universal id of the system that received the order.) 3 PID.3/CX.5 ID O 0203 The type of identifier in PID.3/CX.1. 4 PID.4 Alternate Patient ID - PID 20 CX X Y Not Currently Used. 5 PID.5 -Patient Name 250 XPN R Y This field contains the names of the patient. 5 PID.5/XPN.1/FN.1 ST R Patient s Family Name. 5 PID.5/XPN.2 ST R Patient s First Name. 5 PID.5/XPN.3 ST O Middle Names/and or initials. 20

21 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 5 PID.5/XPN.4 ST O A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 5 PID.5/XPN.5 ST O A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 5 PID.5/XPN.6 IS O 0360 Qualifications. 5 PID.5/XPN.7 ID O 0200 Name type code. 6 PID.6 -Mother s Maiden Name 250 XPN O Y This field contains the family name under which the mother was born (i.e., before marriage). 7 PID.7 -Date/Time of Birth 26 TS C This field contains the patient s date and time of birth. This field should be populated if known. The structure of the field is YYYYMMDD. Thus, YYYY is used to specify a precision of year, YYYYMM specifies a precision of month and YYYYMMDD specifies a precision of day. The optionality of this field is further constrained than the HL7 standard optionality of (O). If the date of birth is known then it is strongly recommended that is supplied. If the date of birth is unknown, a default date of birth may be supplied and it is recommended that this is indicated using the PID.32 field. 8 PID.8 -Administrative Sex 1 IS R This field contains the patient s sex. The optionality of this field is further constrained than the HL7 standard optionality of (O). 9 PID.9 -Patient Alias 250 XPN B Y This field has been retained for backward compatibility only. It is recommended to use PID-5 - patient name for all patient names. This field contained the name(s) by which the patient has been known at some time. 10 PID.10 -Race 250 CE O Y This field refers to the patient s race. 11 PID.11 -Patient Address 250 XAD O Y This field contains the mailing address of the patient. 11 PID.11/XAD.1/SAD.1 ST O Street Address. 11 PID.11/XAD.2 ST O Address line 2. 21

22 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 11 PID.11/XAD.3 ST O Address line PID.11/XAD.4 ST O Address line PID.11/XAD.5 ST O Postal code. 12 PID.12 -County Code 4 IS B This field has been retained for backward compatibility only. 13 PID.13 -Phone Number - Home This field contains the patient s county code. 250 XTN O Y This field contains the patient s personal phone numbers. 13 PID.13/XTN.1 TN O This field is a telephone number to call when communicating with a patient 13 PID.13/XTN.2 ID O 0201 Telecommunications use code. 13 PID.13/XTN.3 ID O 0202 Telecommunications equipment type. 13 PID.13/XTN.4 ST O address 13 PID.13/XTN.6 NM O Area/city code 13 PID.13/XTN.7 ID O Telephone number 14 PID.14 -Phone Number - Business 250 XTN O Y This field contains the patient s business telephone numbers. 14 PID.14/XTN.1 TN O This field is a telephone number to call when communicating with a provider or organisation 14 PID.14/XTN.2 ID O 0201 Telecommunications use code. 14 PID.14/XTN.3 ID O 0202 Telecommunications equipment type. 14 PID.14/XTN.4 ST O address 14 PID.14/XTN.6 NM O Area/city code 14 PID.14/XTN.7 ID O Telephone number 15 PID.15 -Primary Language 250 CE O This field contains the patient s primary language. HL7 recommends using ISO table 639 as the suggested values. 15 PID.15/CE.1 ST O Primary language code. 15 PID.15/CE.2 ST O of coded language. 15 PID.15/CE.3 IS O Name of coding system used. 16 PID.16 -Marital Status 250 CE O This field contains the patient s marital status. 22

23 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 17 PID.17 -Religion 250 CE O This field contains the patient s religion. 18 PID.18 -Patient Account Number 19 PID.19 -SSN Number - Patient 20 PID.20 - Driver's License Number - Patient 21 PID.21 -Mother's Identifier 250 CX O This field contains the patient account number assigned by accounting to which all charges, payments, etc., are recorded. 16 ST B This field has been retained for backward compatibility only. 25 DLN X Not Currently Used. It is recommended to use PID-3 - Patient Identifier List for all patient identifiers. However, in order to maintain backward compatibility, this field should also be populated. 250 CX O Y This field is used, for example, as a link field for newborns. Typically a patient ID or account number may be used. 22 PID.22 -Ethnic Group 250 CE O Y This field further defines the patient s ancestry. 23 PID.23 -Birth Place 250 ST O This field indicates the location of the patient s birth. 24 PID.24 -Multiple Birth Indicator 1 ID O This field indicates whether the patient was part of a multiple birth. 25 PID.25 -Birth Order 2 NM O When a patient was part of a multiple birth, a value (number) indicating the patient s birth order is entered in this field. 26 PID.26 -Citizenship 250 CE O Y This field contains the patient s country of citizenship. 27 PID.27 -Veterans Military Status 250 CE O This field contains the military status assigned to a veteran. 28 PID.28 -Nationality 250 CE B This field has been retained for backward compatibility only. This field contains a code that identifies the nation or national grouping to which the person belongs. This information may be different from a person s citizenship in countries in which multiple nationalities are recognised (for example, Spain: Basque, Catalan, etc.). 23

24 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 29 PID.29 -Patient Death Date and Time 26 TS C This field contains the date and time at which the patient death occurred. Please refer to the Death Notification message flow for specific usage of this field. 29 PID.29/TS.1 TS C The date and time of the patient s death. 30 PID.30 -Patient Death Indicator 31 PID.31 Identity Unknown Indicator 32 PID.32 -Identity Reliability Code 33 PID.33 -Last Update Date/Time 34 PID.34 -Last Update Facility 1 ID C This field indicates whether the patient is deceased. Please refer to the Death Notification message flow for specific usage of this field. 1 ID O This field indicates whether or not the patient s/person s identity is known. 20 IS O Y This field contains a coded value used to communicate information regarding the reliability of patient/person identifying data transmitted via a transaction. Values could indicate that certain fields on a PID segment for a given patient/person are known to be false (e.g., use of default or system-generated values for Date of Birth) 26 TS X Not Currently Used. 40 HD X Not Currently Used. 35 PID.35 -Species Code 250 CE X Not Currently Used. 36 PID.36 -Breed Code 250 CE X Not Currently Used. 37 PID.37 -Strain 80 ST X Not Currently Used. 38 PID.38 - Production Class Code 250 CE X Not Currently Used. 24

25 3.2 The EVN segment (event) The EVN segment is used to communicate necessary trigger event information to receiving applications. Table 6 - The EVN segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 EVN.1 - Event Type Code 3 ID B This field has been retained for backward compatibility only. 2 EVN.2 Recorded Date/Time 26 TS R HL7 recommend using the second component (trigger event) of MSH-9 - Message Type to transmit event type code information. This field contains the events corresponding to the trigger events described in this section, e.g., admission, transfer, or registration. The date time that the event was recorded on the source system. 2 EVN.2/TS.1 TS R The date time that the event was recorded on the source system. 3 EVN.3 - Date/Time Planned Event 4 EVN.4 - Event Reason Code 26 TS X 3 IS X 5 EVN.5 - Operator ID 250 XCN X 6 EVN.6 - Event Occurred 26 TS X 7 EVN.7 Event Facility 180 HD X Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. 25

26 3.3 The PV1 segment (event type/ patient visit) The PV1 segment is used by registration/patient administration applications to communicate information on an account or visit-specific basis. Table 7 - The PV1 segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 PV1.1 - Set ID 4 SI O This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.. 2 PV1.2 - Patient Class 1 IS R This field identifies the class of the patient in terms of Inpatient, Outpatient, Emergency, Unknown etc.. 3 PV1.3 - Assigned Patient Location 80 PL O This field contains the patient s initial assigned location or the location to which the patient is being moved e.g. Radiology Department. The first component may be the nursing station for inpatient locations, or clinic or department, for locations other than inpatient. 3 PV1.3/PL.4/HD.1 IS O The name of the assigned patient location. 3 PV1.3/PL.4/HD.2 ST O The code associated with the assigned patient location. 3 PV1.3/PL.4/HD.3 ID O The coding system used to identify the assigned patient location. 3 PV1.3/PL.9 ST O The location of the patient as plain text. 4 PV1.4 - Admission Type IS O This field indicates the circumstances under which the patient was or will be admitted. 5 PV1.5 - Preadmit Number 250 CX X Not Currently Used. 6 PV1.6 - Prior Patient Location 80 PL X Not Currently Used. 7 PV1.7 - Attending Doctor 250 XCN O Y This field identifies the healthcare practitioner responsible for care of the patient. It is recommended that the doctors name and professional identifier are supplied. 26

27 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 7 PV1.7/XCN.1 ST O The identifier for the attending doctor. 7 PV1.7/XCN.2/FN.1 ST O The family name of the attending doctor. 7 PV1.7/XCN.3 ST O The first name of the attending doctor. 7 PV1.7/XCN.4 ST O Middle names/and or initials. 7 PV1.7/XCN.5 ST O The name suffix. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 7 PV1.7/XCN.6 ST O A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 8 PV1.8 - Referring Doctor 250 XCN O Y This field identifies the healthcare practitioner responsible for referring the patient. It is recommended that the doctors name and professional identifier is supplied. 8 PV1.8/XCN.1 ST O The identifier for the doctor. 8 PV1.8/XCN.2/FN.1 ST O The family name of the referring doctor. 8 PV1.8/XCN.3 ST O The first name of the referring doctor. 8 PV1.8/XCN.4 ST O Middle names/and or initials. 8 PV1.8/XCN.5 ST O The name suffix. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 8 PV1.8/XCN.6 ST O The name prefix. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 9 PV1.9 - Consulting Doctor 250 XCN B Y This field has been retained for backward compatibility only. This field contains the consulting physician information. Some hospital use this field to identify other healthcare professionals involved in this episode of care. 9 PV1.9/XCN.1 ST O The identifier for the consulting doctor. 9 PV1.9/XCN.2/FN.1 ST O The family name of the consulting doctor. 27

28 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 9 PV1.9/XCN.3 ST O The first name of the consulting doctor. 9 PV1.9/XCN.4 ST O The middle names/and or initials of the consulting doctor. 9 PV1.9/XCN.5 ST O The name suffix. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 9 PV1.9/XCN.6 ST O The name prefix. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 10 PV Hospital Service 3 IS X Not Currently Used. 11 PV1.11- Temporary Location 12 PV1.12- Preadmit Test Indicator 13 PV Re-admission Indicator 80 PL X Not Currently Used. 2 IS X Not Currently Used. 2 IS X Not Currently Used. 14 PV Admit Source 6 IS C This field indicates where the patient was admitted. 15 PV Ambulatory Status Please refer to the A&E Notification and Admission Notification workflows for specific usage of this field. 2 IS O Y This field indicates any permanent or transient disability. 16 PV VIP Indicator 2 IS X Not Currently Used. 17 PV Admitting Doctor 250 XCN X Y Not Currently Used. 18 PV Patient Type 2 IS X Not Currently Used. 19 PV Visit Number 250 CX O This field contains the unique number assigned to each patient visit. 19 PV1.19/CX.1 ST O The hospitals episode number. 20 PV Financial Class 50 FC O Y This field contains the financial class(es) assigned to the patient for the purpose of identifying sources of reimbursement. 20 PV1.20/FC.1 IS O Financial class code of the patient, as per the user defined table. 28

29 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 20 PV1.20/FC.2 TS O Effective date. 21 PV Charge Price 2 IS X Not Currently Used. Indicator 22 PV Courtesy Code 2 IS X Not Currently Used. 23 PV1.23- Credit Rating 2 IS X Not Currently Used. 24 PV Contract Code 2 IS X Y Not Currently Used. 25 PV Contract Effective Date 8 DT X Y Not Currently Used. 26 PV Contract Amount 12 NM X Y Not Currently Used. 27 PV1.27- Contract Period 3 NM X Y Not Currently Used. 28 PV Interest Code 2 IS X Not Currently Used. 29 PV Transfer to Bad Debt Code 30 PV1.30- Transfer to Bad Debt Date 31 PV Bad Debt Agency Code 32 PV1.32- Bad Debt Transfer Amount 33 PV1.33- Bad Debt Recovery Amount 34 PV1.34- Delete Account Indicator 35 PV Delete Account Date 36 PV Discharge Disposition 1 IS X Not Currently Used. 8 DT X Not Currently Used. 10 IS X Not Currently Used. 12 NM X Not Currently Used. 12 NM X Not Currently Used. 1 IS X Not Currently Used. 8 DT X Not Currently Used. 3 IS C This field contains the disposition of the patient at time of discharge (i.e., discharged to home, expired, etc.). The optionality of this field is further constrained than the HL7 standard optionality of (O). Please refer to message flow Discharge Summary message flow for specific usage of this field. 29

30 HL7 Seq HL7 Element Name 37 PV Discharged to Location Max Len HL7 Data Type Opt Repeat Table Item # 25 CM C This field indicates the healthcare facility to which the patient was discharged. The optionality of this field is further constrained than the HL7 standard optionality of (O). Please refer to discharge summary message flow for specific usage of this field. 37 PV1.37/DLD.1 IS O If the patient is discharged to another coded location it should be indicated here. 38 PV Diet Type 250 CE X Not Currently Used. 39 PV Servicing Facility 2 IS X Not Currently Used. 40 PV Bed Status 1 IS X Not Currently Used. 41 PV Account Status 2 IS X Not Currently Used. 42 PV1.42- Pending Location 80 PL X Not Currently Used. 43 PV1.43- Prior Temporary Location 80 PL X Not Currently Used. 44 PV1.44- Admit Date/Time 26 TS C The date/time the patient was admitted. 45 PV1.45- Discharge Date/Time 46 PV Current Patient Balance The optionality of this field is further constrained than the HL7 standard optionality of (O). Please refer to the A&E Notification and Admission Notification workflow for specific usage of this field. 26 TS C Y The date/time the patient was discharged. The optionality of this field is further constrained than the HL7 standard optionality of (O). Please refer to message flow Please refer to Discharge Notification and Discharge summary message flow 12 NM X Not Currently Used. 47 PV1.47- Total Charges 12 NM X Not Currently Used. 48 PV1.48- Total Adjustments 12 NM X Not Currently Used. 49 PV1.49- Total Payments 12 NM X Not Currently Used. 50 PV Alternate Visit ID 250 CX X Not Currently Used. 51 PV1.51- Visit Indicator 1 IS O This field specifies the level on which data are being 30

31 HL7 Seq HL7 Element Name 52 PV1.52- Other Healthcare Provider Max Len HL7 Data Type Opt Repeat Table Item # sent. 250 XCN X Y Not Currently Used. 31

32 3.4 The PV2 segment (event type additional information) The PV2 segment is a continuation of information contained on the PV1 segment. Table 8 - The PV2 segment HL7 Seq HL7 Element Name 1 PV2.1 - Prior Pending Location 2 PV2.2 - Accommodation Code Max Len HL7 Data Type Opt Repeat Table Item # 80 PL X Not Currently Used. 250 CE X Not Currently Used. 3 PV2.3 - Admit Reason 250 CE X Not Currently Used. 4 PV2.4 - Transfer Reason 250 CE X Not Currently Used. 5 PV2.5 - Patient Valuables 25 ST X Y Not Currently Used. 6 PV2.6 - Patient Valuables Location 25 ST X Not Currently Used. 7 PV2-7 - Visit User Code 2 IS X Y Not Currently Used. 8 PV2.8 - Expected Admit Date/Time 9 PV2.9 - Expected Discharge Date/Time 10 PV Estimated Length of Inpatient Stay 11 PV Actual Length of Inpatient Stay 26 TS X Not Currently Used. 26 TS X Not Currently Used. 3 NM X Not Currently Used. 3 NM X Not Currently Used. 12 PV Visit 50 ST X Not Currently Used. 13 PV Referral Source Code 14 PV Previous Service Date 250 XCN X Y Not Currently Used. 8 DT X Not Currently Used. 32

33 HL7 Seq HL7 Element Name 15 PV Employment Illness Related Indicator 16 PV Purge Status Code 17 PV Purge Status Date 18 PV Special Program Code 19 PV Retention Indicator 20 PV Expected Number of Insurance Plans 21 PV Visit Publicity Code 22 PV Visit Protection Indicator 23 PV Clinic Organisation Name 24 PV Patient Status Code 25 PV Visit Priority Code 26 PV Previous Treatment Date 27 PV Expected Discharge Disposition 28 PV Signature on File Date 29 PV First Similar Illness Date Max Len HL7 Data Type Opt Repeat Table Item # 1 ID X Not Currently Used. 1 IS X Not Currently Used. 8 DT X Not Currently Used. 2 IS X Not Currently Used. 1 ID X Not Currently Used. 1 NM X Not Currently Used. 1 IS X Not Currently Used. 1 ID X Not Currently Used. 250 XON X Y Not Currently Used. 2 IS X Not Currently Used. 1 IS X Not Currently Used. 8 DT X Not Currently Used. 2 IS X Not Currently Used. 8 DT X Not Currently Used. 8 DT X Not Currently Used. 33

34 HL7 Seq HL7 Element Name 30 PV Patient Charge Adjustment Code 31 PV Recurring Service Code 32 PV Billing Media Code 33 PV Expected Surgery Date and Time 34 PV Military Partnership Code 35 PV Military Non- Availability Code 36 PV Newborn Baby Indicator 37 PV Baby Detained Indicator 38 PV Mode of Arrival Code Max Len HL7 Data Type Opt Repeat Table Item # 250 CE X Not Currently Used. 2 IS X Not Currently Used. 1 ID X Not Currently Used. 26 TS X Not Currently Used. 1 ID X Not Currently Used. 1 ID X Not Currently Used. 1 ID X Not Currently Used. 1 ID X Not Currently Used. 250 CE O Identifies how the patient was brought to the healthcare facility. 38 PV2.38/CE.1 ST O The code indicating how the patient arrived at the healthcare facility. 38 PV2.38/CE.2 ST O The accompanying text for the code in PV2.38/CE PV2.38/CE.3 IS O 0396 The coding system used in PV2.38/CE PV Recreational Drug Use Code 40 PV Admission Level of Care Code 250 CE X Y Not Currently Used. 250 CE X Not Currently Used. 41 PV Precaution Code 250 CE X Y Not Currently Used. 42 PV Patient Condition Code 250 CE X Not Currently Used. 43 PV Living Will Code 2 IS X Not Currently Used. 34

35 HL7 Seq HL7 Element Name 44 PV Organ Donor Code 45 PV Advance Directive Code 46 PV Patient Status Effective Date 47 PV Expected LOA Return Date/Time Max Len HL7 Data Type Opt Repeat Table Item # 2 IS X Not Currently Used. 250 CE X Y Not Currently Used. 8 DT X Not Currently Used. 26 TS X Not Currently Used. 35

36 3.5 The PRD segment (provider data) This segment will be employed as part of a patient referral message and its related transactions. Table 9 - The PRD segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 PRD.1 - Provider Role 250 CE R Y PRD.1/CE.1 ST R PRD.1/CE.2 ST O 1 PRD.1/CE.3 IS O This field contains the contact role that defines the relationship of the person described in this segment to the patient being referred. The provider role. This field contains the contact role that defines the relationship of the person described in this segment to the patient being referred. This field contains the free text for information concerning the provider role This field contains the name of the coding system for the provider role 2 PRD.2 Provider Name 250 XPN C Y This field contains the name of the provider. Please refer to the Online Referral workflow for specific usage of this field. 2 PRD.2/XPN.1 ST O The provider s family name. 2 PRD.2/XPN.2 ST O The provider s first name. 2 PRD.2/XPN.3 ST O Middle names and/or initials 2 PRD.2/XPN.4 ST O Name suffix. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 36

37 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 2 PRD.2/XPN.5 ST O Name prefix. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 2 PRD.2/XPN.6 IS The degree (e.g., MD) for the provider role 3 PRD.3 Provider Address 250 XAD C Y PRD.3/XAD.1/SAD.1 ST O Street Address. 3 PRD.3/XAD.2 ST O Address Line 2. 3 PRD.3/XAD.3 ST O Address Line 3. 3 PRD.3/XAD.4 ST O Address Line 4. 4 PRD.4 Provider Location 60 PL C PRD.4/PL.1 IS O Point of Care. 4 PRD.4/PL.6 IS O Person Location Type. This field contains the mailing address of the provider identified in this segment. Please refer to the Online Referral work flow for specific usage of this field. This field contains the location of the provider as needed when a provider that may be external to a given enterprise must be referenced. Please refer to the Online Referral work flow for specific usage of this field. 4 PRD.4/PL.9 ST O Location. 37

38 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 5 PRD.5 Provider Communication Information 250 XTN C Y This field contains information, such as the phone number or electronic mail address, used to communicate with the provider or organisation. Please refer to the Online Referral workflow for specific usage of this field. 5 PRD.5/XTN.1 TN O This field is a telephone number to call when communicating with a patient 5 PRD.5/XTN.2 ID O 0201 Telecommunications use code. 5 PRD.5/XTN.3 ID O 0202 Telecommunications equipment type. 5 PRD.5/XTN.4 ST O address 5 PRD.5/XTN.6 NM O Area/city code 5 PRD.5/XTN.7 ID O Telephone number 6 PRD.6 Preferred Method of Contact - Provider 250 CE X PRD.7 Provider Identifiers 100 CM C Y Not Currently Used. Provider identifiers. Please refer to the Online Referral workflow for specific usage of this field. 7 PRD.7/PI.1 ID O This repeating field contains the provider s unique identifiers. 7 PRD.7/PI.2 IS O Type of ID number (IS). 7 PRD.7/PI.3 ST O Other qualifying information. 38

39 HL7 Seq HL7 Element Name 8 PRD.8 Effective Start Date of Provider Role 9 PRD.9 Effective End Date of Provider Role Max Len HL7 Data Type 26 TS X 26 TS X Opt Repeat Table Item # Not Currently Used. Not Currently Used. 39

40 3.6 The DG1 segment (diagnosis) The DG1 segment contains patient diagnosis information of various types, for example, admitting, primary, etc. The DG1 segment is used to send multiple diagnoses (for example, for medical records encoding). Table 10 - The DG1 segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 DG1.1 - Set ID - DG1 4 SI R This field contains the number that identifies this transaction. For the first occurrence of the segment the sequence number shall be 1, for the second occurrence it shall be 2, etc.. 2 Dg1.2 - Diagnosis Coding Method 2 ID (B) R This field has been retained for backward compatibility only. Use the components of DG1.3 instead of this field. 3 DG1.3 - Diagnosis Code 250 CE O This field contains the diagnosis code. Use this field instead of DG1.2 and DG DG1.3/CE.1 ST O 0051 Local Code for the diagnosis. 3 DG1.3/CE.2 ST O The diagnosis text associated with the code in DG1.3/CE.1. 3 DG1.3/CE.3 IS O The coding system used in DG1.3/CE.1. The should contain L if used. 4 DG1.4 - Diagnosis 40 ST B This field has been retained for backward compatibility only. It is recommended to use the components of DG1-3 - diagnosis code-dg1 field instead of this field. 26 TS O This field contains the date/time that the diagnosis was determined. 5 DG1.5 - Diagnosis Date/Time 6 DG1.6 - Diagnosis Type 2 IS R This field contains a code that identifies the type of diagnosis being sent. 7 DG1.7 - Major Diagnostic 250 CE X Not Currently Used. Category 8 DG1.8 - Diagnostic 250 CE X Not Currently Used. Related Group 9 DG1.9 - DRG Approval 1 ID X Not Currently Used. Indicator 40

41 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 10 DG DRG Grouper 2 IS X Not Currently Used. Review Code 11 DG Outlier Type 250 CE X Not Currently Used. 12 DG Outlier Days 3 NM X Not Currently Used. 13 DG Outlier Cost 12 CP X Not Currently Used. 14 DG Grouper Version 4 ST X Not Currently Used. And Type 15 DG Diagnosis Priority 2 ID X Not Currently Used. 16 DG Diagnosing Clinician 250 XCN O Y This field contains the individual responsible for generating the diagnosis information. 16 DG1.16/XCN.1 ST O The individual responsible for the diagnosis. 16 DG1.16/XCN.2/FN.1 ST O The family name of the diagnosing clinician. 16 DG1.16/XCN.3 ST O The first name of the diagnosing clinician. 16 DG1.16/XCN.4 ST O Middle names and/or initials. 16 DG1.16/XCN.5 ST O The name suffix. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 16 DG1.16/XCN.6 ST O The name prefix. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 17 DG Diagnosis 3 IS X Not Currently Used. Classification 18 DG Confidential 1 ID X Not Currently Used. Indicator 19 DG Attestation Date/Time 26 TS X Not Currently Used. 41

42 3.7 The NTE segment (notes and comments) The NTE segment is commonly used for sending notes and comments. Table 11 - The NTE segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 NTE.1 - Set ID - NTE 4 SI O This field may be used where multiple NTE segments are included in a message. Their numbering must be described in the application message definition. 2 NTE.2 - Source of Comment 8 ID O This field is used when source of comment must be identified. 3 NTE.3 - Comment FT O Y This field contains the comment contained in the segment. 4 NTE.4 - Comment Type 250 CE X Not Currently Used. 42

43 3.8 The OBR segment (observation request) The observation request segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment. In the reporting of clinical data, the OBR serves as the report header. It includes the relevant ordering information when that applies. It contains many of the fields that usually apply to all of the included observations. When a set of observations is ordered, the order message contains an OBR segment. However, observations can be collected and reported without an antecedent order. When observations are reported, the report message also includes one or more OBR segments. Table 12 - The OBR segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 OBR.1 - Set ID 4 SI R For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2 and so on. 2 OBR.2 - Placer Order Number The optionality of this field is further constrained than the HL7 standard optionality of (O). 22 EI C This field is a case of the Entity Identifier data type. Please refer to message flow Laboratory Order and Referral workflows for specific usage of this field. 2 OBR.2/EI.1 ST C If the system that placed the order provided a reference to the filler, then it should be entered here. 3 OBR.3 - Filler Order Number 22 EI C This field is the order number associated with the filling application. Please refer to message flow Laboratory and Radiology Results work flows for specific usage of this field. The optionality of this field is further constrained than the HL7 standard optionality of (O). It is strongly recommended that one of OBR.3/EI.1, 43

44 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # OBR.3/EI.2 or OBR.3/EI.3 is populated. 3 OBR.3/EI.1 ST C 0363 The order number of the system that received the order. 3 OBR.3/EI.2 IS C The numeric identifier of the system that received the order. 3 OBR.3/EI.3 ST C The name of the system that received the order. 3 OBR.3/EI.4 ID C 0301 The universal id of the system that received the order. 4 OBR.4 - Universal Service Identifier 250 CE R This field is the identifier code for the requested observation/test/battery. 4 OBR.4/CE.1 ST O The code for observation/test. 4 OBR.4/CE.2 ST R Meaningful description of the test being ordered or a meaningful description of the overall set of OBX s included under each OBR. For example: Hemoglobin, Urea & Electrolytes. 4 OBR.4/CE.3 IS O 0396 The coding system used in OBR.4/CE.1. 4 OBR.4/CE.4 ST O Code for the observation/test. Reserved for adoption of national coding system. 4 OBR.4/CE.5 ST O Meaningful description of the Lab/Radiology Test. Reserved for adoption of national coding system. 4 OBR.4/CE.6 IS O 0396 Coding system used in OBR.4/CE.4. Reserved for adoption of national coding system. 5 OBR.5 - Priority - OBR 2 ID X Not Currently Used. 6 OBR.6 - Requested Date/Time 7 OBR.7 - Observation Date/Time 26 TS X Not Currently Used. 26 TS C This field is the clinically relevant date/time of the observation. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field 44

45 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # must be filled in because this specimen time is the physiologically relevant date/time of the observation. Please refer to Laboratory Results and Radiology Results message flows for specific usage of this field. 7 OBR.7/TS.1 TS C The date and time the specimen was collected or obtained. 8 OBR.8 - Observation End Date/Time 26 TS O This field contains the end date and time of a study or timed specimen collection. 9 OBR.9 - Collection Volume 20 CQ O For laboratory tests, the collection volume is the volume of a specimen. 10 OBR.10 - Collector Identifier 11 OBR.11 - Specimen Action Code 250 XCN O Y When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. 1 ID O This field identifies the action to be taken with respect to the specimens that accompany or precede this order. 12 OBR.12 - Danger Code 250 CE O This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. 13 OBR.13 - Relevant Clinical Info. 300 ST O This field contains any additional clinical information about the patient or specimen. It is strongly recommended that this field is populated where clinically appropriate. 45

46 HL7 Seq HL7 Element Name 14 OBR.14 - Specimen Received Date/Time 15 OBR.15 Specimen Source Max Len HL7 Data Type Opt Repeat Table Item # 26 TS C The time that the specimen was received at dispatch. Please refer to message flow Laboratory Order and Laboratory Results workflow for specific usage of this field. 300 CM O This field identifies the site where the specimen should be obtained or where the service should be performed. 15 OBR.15/SPS.1/CE.1 ST O The specimen source code. 15 OBR.15/SPS.1/CE.2 ST O 0070 Meaningful specimen source code description. 15 OBR.15/SPS.1/CE.3 IS O Coding system used in CE.1 15 OBR.15/SPS.1/CE.4 ST O Alternate specimen source code. 15 OBR.15/SPS.1/CE.5 ST O Alternate specimen description. 15 OBR.15/SPS.1/CE.6 IS O Alternate coding system used in CE.4 15 OBR.15/SPS.2 ST O Text describing additives. 15 OBR.15/SPS.3 ST O Simple free text. 15 OBR.15/SPS.4/CE.1 ST O 0163 Identifier of body site. 15 OBR.15/SPS.4/CE.2 ST O Text description of body site. 15 OBR.15/SPS.4/CE.3 IS O Name of coding system. 15 OBR.15/SPS.5/CE.1 ST O Identifier of site modifier. 15 OBR.15/SPS.5/CE.2 ST O Text description of site modifier. 15 OBR.15/SPS.5/CE.3 IS O Name of coding system. 15 OBR.15/SPS.6/CE.1 ST O Identifier of collection method. 15 OBR.15/SPS.6/CE.2 ST O Text description of collection method. 15 OBR.15/SPS.6/CE.3 IS O Name of coding system. 16 OBR.16 - Ordering Provider 250 XCN O Y This field identifies the provider who ordered the test. Either the identifier code or the name, or both, may be present. This is the same as ORC-12-Ordering provider. 46

47 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 16 OBR.16/XCN.1 ST O Identifier of the person ordering. 16 OBR.16/XCN.2 FN O Family name. 16 OBR.16/XCN.3 ST O Given name. 16 OBR.16/XCN.4 ST O Second or further given names or initials thereof. 16 OBR.16/XCN.5 ST O A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D.suffix (e.g., JR or III). 16 OBR.16/XCN.6 ST O Name prefix. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 16 OBR.16/XCN.16 CE O 0448 <Copy To> Indicator Prefix. 17 OBR.17 - Order Callback Phone Number Please refer to use cases Unsolicited Laboratory Result, Unsolicited Radiology Result and Corrected Result for specific usage of this field. 250 XTN O Y/ This field is the telephone number to call when reporting a status or a result. 17 OBR.17/XTN.1 TN O This field is a telephone number to call when when reporting a status or a result. 17 OBR.17/XTN.2 ID O 0201 Telecommunications use code. 17 OBR.17/XTN.3 ID O 0202 Telecommunications equipment type. 17 OBR.17/XTN.4 ST O address. 17 OBR.17/XTN.6 NM O Area/city code. 47

48 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 17 OBR.17/XTN.7 ID O Telephone number. 18 OBR.18 - Placer Field 1 60 ST X Not Currently Used. 19 OBR.19 - Placer Field 2 60 ST X Not Currently Used. 20 OBR.20 - Filler Field 1 60 ST X Not Currently Used. 21 OBR.21 - Filler Field 2 60 ST X Not Currently Used. 22 OBR.22 - Results Rpt/Status Chng - Date/Time 23 OBR.23 - Charge to Practice 24 OBR.24 - Diagnostic Serv Sect ID 26 TS C This field specifies the date/time when the results were reported or status changed. 40 CM X Not Currently Used. 10 ID C This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Please refer to message flow Laboratory Results, Radiology Results for specific usage of this field. 25 OBR.25 - Result Status 1 ID C This field is the status of results for this order. Please refer to Laboratory Results and Radiology Results and Corrected Results work flows for specific usage of this field. 26 OBR.26 Parent Result 400 CM O This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29- parent, uniquely identifies the parent result s OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. 27 OBR.27 - Quantity/Timing 200 TQ O Y This field contains information about how many services to perform at one service time and how often the service times are repeated, and to fix duration of the request. 48

49 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 27 OBR.27/TQ.1 CQ O Quantity. 28 OBR.28 - Result Copies To 250 XCN O Y/ This field is the people who are to receive copies of the results. By local convention, either the identifier number or the name may be absent. 28 OBR.28/XCN.1 ST O Identifier of the person being copied ( e.g. GP s GP code). 28 OBR.28/XCN.2/FN.1 ST O Family name. 28 OBR.28/XCN.3 ST O First name. 28 OBR.28/XCN.4 ST O Middle/ other names. 28 OBR.28/XCN.5 ST O Name suffix. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 28 OBR.28/XCN.6 ST O Name prefix. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 28 OBR.28/XCN.16 CE O 0448 <Copy To> indicator string. Please refer to use cases Unsolicited Laboratory Result, Unsolicited Radiology Result and Corrected Result for specific usage of this field. 29 OBR.29 - Parent 200 CM O This field is identical to ORC-8-parent. This field relates a child to its parent when a parent/child relationship exists. 30 OBR.30 - Transportation 20 ID X Not Currently Used. Mode 31 OBR.31 - Reason for Study 32 OBR.32 - Principal Result Interpreter 33 OBR.33 - Assistant Result Interpreter 250 CE X Y Not Currently Used. 200 CM O This field identifies the physician or other clinician who interpreted the observation and is responsible for the report content. 200 CM X Y Not Currently Used. 49

50 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 34 OBR.34 - Technician 200 CM X Y Not Currently Used. 35 OBR.35 - Transcriptionist 200 CM X Y Not Currently Used. 36 OBR.36 - Scheduled Date/Time 37 OBR.37 - Number of Sample Containers 38 OBR.38 - Transport Logistics of Collected Sample 39 OBR.39 - Collector's Comment 40 OBR.40 - Transport Arrangement Responsibility 41 OBR.41 - Transport Arranged 26 TS X Not Currently Used. 4 NM X Not Currently Used. 250 CE X Y Not Currently Used. 250 CE X Y Not Currently Used. 250 CE X Not Currently Used. 30 ID X Not Currently Used. 42 OBR.42 - Escort Required 1 ID X Not Currently Used. 43 OBR.43 - Planned Patient Transport Comment 250 CE X Y Not Currently Used. 44 OBR.44 - Procedure Code 250 CE X Not Currently Used. 45 OBR.45 - Procedure Code Modifier 46 OBR.46 - Placer Supplemental Service Information 47 OBR.47 - Filler Supplemental Service Information 250 CE X Y Not Currently Used. 250 CE X Y Not Currently Used. 250 CE X Y Not Currently Used. 50

51 3.9 The OBX segment (observation result) The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. Table 13 - The OBX segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 OBX.1 - Set ID 4 SI R This field contains the sequence number. For compatibility with ASTM. The optionality of this field is further constrained than the HL7 standard optionality of (O). 2 OBX.2- Value Type 2 ID C This field contains the format of the observation value in OBX. It must be valued if OBX-11-Observ result status is not valued with an X meaning the result cannot be obtained or this observation. 3 OBX.3 - Observation Identifier 250 CE R This field should contain a unique identifier for the observation. 3 OBX.3/CE.1 ST R The code for the OBX.3/CE.2 description. 3 OBX.3/CE.2 ST R A description of the test or observation. 3 OBX.3/CE.3 IS R The coding system used in CE.1. 3 OBX.3/CE.4 ST O Alternate code for the test or observation. 3 OBX.3/CE.5 ST O 3 OBX.3/CE.6 IS O Alternate description of the radiology test. The alternate coding system used in CE.4. 51

52 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 4 OBX.4 - Observation Sub-ID 20 ST O This field is used to distinguish between multiple OBX segments with the same observation ID organised under one OBR. 5 OBX.5 - Observation Value * C Y This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to which observation value is formatted. It is not a required field because some systems will report only the normalcy/abnormalcy (OBX-8), especially in product experience reporting. 6 OBX.6 - Units 250 CE O When an observation s value is measured on a continuous scale, one must report the measurement units within the units field of the OBX segment. 6 OBX.6/CE.1 ST O The code for the units used. 6 OBX.6/CE.2 ST O The actual units used as text (not a code). 6 OBX.6/CE.3 IS O The coding system used for the units. 7 OBX.7 - References Range 60 ST O This field contains the reference range for this particular test. 8 OBX.8 - Abnormal Flags 5 IS O Y/ This field contains a table lookup indicating the normalcy status of the result. This field may not be valued for certain laboratory results e.g. Microbiology Results. 9 OBX.9 - Probability 5 NM X Not Currently Used. 10 OBX.10 - Nature of Abnormal Test 11 OBX.11 - Observation Result Status 2 ID X Y Not Currently Used. 1 ID R This field contains the observation result status. This field reflects the current completion status of the results for one Observation Identifier. Please refer to message flow Unsolicited Laboratory 52

53 HL7 Seq HL7 Element Name 12 OBX.12 - Date Last Observation Normal Value 13 OBX.13 - User Defined Access Checks 14 OBX.14 - Date/Time of the Observation Max Len HL7 Data Type Opt Repeat Table Item # Result, Unsolicited Radiology Result and Corrected Result workflow for updated results for specific usage of this field. 26 TS X Not Currently Used. 20 ST X Not Currently Used. 26 TS O In the case of tests performed on specimens, the relevant date-time is the specimen s collection datetime. In the case of observations taken directly on the patient (e.g., X-ray images, history and physical), the observation date-time is the date-time that the observation was performed. 15 OBX.15 - Producer's ID 250 CE O This field contains a unique identifier of the responsible producing service. It should be reported explicitly when the test results are produced at outside laboratories. 16 OBX.16 - Responsible Observer 17 OBX.17 - Observation Method 18 OBX.18 - Equipment Instance Identifier 19 OBX.19 - Date/Time of the Analysis 250 XCN O Y When required, this field contains the identifier of the individual directly responsible for the observation (i.e., the person who either performed or verified it). 250 CE X Y Not Currently Used. 22 EI X Y Not Currently Used. 26 TS X Not Currently Used. 53

54 3.10 The PDA segment (patient death and autopsy) This segment carries information on a patient s death and possible autopsy. Table 14 - The PDA segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 PDA.1 Death Cause Code 250 CE C Y This field is valued with the reason of the death. Please see the Death Notification workflow for specific recommendations. 1 PDA.1/CE.1 ST O The code indicating the cause of death. 1 PDA.1/CE.2 ST O The text for the cause of death. 1 PDA.1/CE.3 IS O The coding system used in PDA.1/CE.1. 2 PDA.2 Death Location 80 PL C This field is valued with the place the death occurred. Please see the Death Notification workflow for specific recommendations. 2 PDA.2/PL.9 ST O The free text location of patient s death. 3 PDA.3 Death Certified Indicator 4 PDA.4 Death Certificate Signed Date/Time 1 ID X Not Currently Used. 26 TS O This field is valued with the date and time the death certificate was signed. 4 PDA.4/TS.1 TS O The date and time the death certificate was signed. 5 PDA.5 Death Certified By 250 XCN X Not Currently Used. 6 PDA.6 Autopsy Indicator 1 ID X Not Currently Used. 7 PDA.7 Autopsy Start and End Date/Time 53 DR X Not Currently Used. 8 PDA.8 Autopsy Performed By 250 XCN X Not Currently Used. 9 PDA.9 Coroner Indicator 1 ID X Not Currently Used. 54

55 3.11 The RGS segment (resource group) The RGS segment is used to identify relationships between resources identified for a scheduled event. Table 15 - The RGS segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 RGS.1 Set ID 4 SI R This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion. 2 RGS.2 Segment Action Code 3 ID C This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. 3 RGS.3 Resource Group ID 250 CE O This field contains an identifier code describing the group of resources following this RGS segment. 55

56 3.12 The AIP segment (appointment information personnel resources) The AIP segment contains information about the personnel types that can be scheduled. Table 16 - The AIP segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 AIP.1 - Set ID - AIP 4 SI R This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion. 2 AIP.2 - Segment Action code 3 AIP.3 - Personnel Resource ID 3 ID C This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. 250 XCN C Y This field contains the ID number and name of the person being requested or scheduled for an appointment. 4 AIP.4 - Resource Role 250 CE R This field identifies the role of the personnel requested/scheduled for an appointment. 5 AIP.5 - Resource Group 250 CE X Not Currently Used. 6 AIP.6 - Start Date/Time 26 TS X Not Currently Used. 7 AIP.7 - Start Date/Time Offset 8 AIP.8 - Start Date/Time Offset Units 20 NM X Not Currently Used. 250 CE X Not Currently Used. 9 AIP.9 - Duration 20 NM X Not Currently Used. 10 AIP.10 - Duration Units 250 CE X Not Currently Used. 11 AIP.11 - Allow Substitution Code 10 IS X Not Currently Used. 12 AIP.12 - Filler Status Code 250 CE X Not Currently Used. 56

57 3.13 The SCH segment (scheduling activity information) The SCH segment contains general information about the scheduled appointment. Table 17 -The SCH segment HL7 Seq HL7 Element Name 1 SCH.1 - Placer Appointment ID 2 SCH.2 Filler Appointment ID Max Len HL7 Data Type Opt Repeat Table Item # 75 EI X Not Currently Used. 75 EI C 2 SCH.2/EI.1 ST O Entity identifier. 2 SCH.2/EI.2 IS O Namespace ID. 2 SCH.2/EI.3 ST C Universal ID. 2 SCH.2/EI.4 ID C Universal ID Type. 3 SCH.3 - Occurrence Number 4 SCH.4 - Placer Group Number 5 NM C 22 EI X 5 SCH.5 - Schedule ID 250 CE X This field contains the filler application s permanent identifier for the appointment request (and the scheduled appointment itself, when it has been confirmed as a booked slot by the filler application). This field is used in conjunction with SCH-1-Placer appointment ID and/or SCH-2-Filler appointment ID to uniquely identify an individual occurrence (a child) of a parent repeating schedule appointment. Not Currently Used. Not Currently Used. 57

58 HL7 Seq HL7 Element Name Max Len HL7 Data Type 6 SCH.6 - Event Reason 250 CE R Opt Repeat Table Item # This field contains an identifier code for the reason that the notification event was triggered. This field may contain a code describing the cancel reason, the delete reason, the discontinue reason, the add reason, the block reason or any other code describing the reason that a specific event will occur. 6 SCH.6/CE.1 ST O The code (local code) for the event reason. 6 SCH.6/CE.2 ST R The reason for this message event. 6 SCH.6/CE.3 IS O The coding system used in SCH.6/CE.1. 7 SCH.7 - Appointment Reason 250 CE X SCH.8 - Appointment Type 250 CE X SCH.9 - Appointment Duration 10 SCH.10 - Appointment Duration Units 11 SCH.11 - Appointment Timing Quantity 20 NM X 250 CE X 200 TQ R Y Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. This field contains the scheduled appointment s timing and quantity, as scheduled by the filler application. 11 SCH.11/TQ.4 TS R The start time of the appointment. 11 SCH.11/TQ.6 ST O The priority time of the appointment. The following are suggested values based on HL7 v2.4 for the priority component: 58

59 HL7 Seq HL7 Element Name 12 SCH.12 - Placer Contact Person 13 SCH.13 - Placer Contact Phone Number 14 SCH.14 - Placer Contact Address 15 SCH.15 - Placer Contact Location 16 SCH.16 - Filler Contact Person Max Len HL7 Data Type 250 XCN X Y 250 XTN X 250 XAD X Y 80 PL X 250 XCN R Y Opt Repeat Table Item # Priority component (ST) Definition: This field describes the urgency of the request. The following values are suggested (the default for Priority is R): S = Stat With highest priority A = ASAP Fill after S orders R = Routine Default P = Preop C = Callback T = Timing critical A request implying that it is critical to come as close as possible to the requested time, e.g., for a trough antimicrobial level. PRN = As needed Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. This field identifies the person responsible for the scheduling of the requested appointment. Most often, this person will be the same person responsible for maintaining the schedule and for reviewing appointment requests. 16 SCH.16/XCN.1 ST O The identifier of the filler contact person. 16 SCH.16/XCN.2/FN.1 ST O The family name of the filler contact person. 16 SCH.16/XCN.3 ST O The first name of the filler contact person. 59

60 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 16 SCH.16/XCN.4 ST O The middle names of the filler contact person. 16 SCH.16/XCN.5 ST O The name suffix of filler contact person. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A,MBA, Ph.D. 16 SCH.16/XCN.6 ST O The name prefix of filler contact person. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 17 SCH.17 - Filler Contact Phone Number 250 XTN X Not Currently Used. 18 SCH.18 - Filler Contact Address 19 SCH.19 - Filler Contact Location 250 XAD X Y Not Currently Used. 80 PL X Not Currently Used. 20 SCH.20 - Entered by Person 250 XCN R Y This field identifies the person responsible for entering the request for the scheduling of an appointment. It is included to provide an audit trail of persons responsible for the request. This person may be someone other than the placer contact person, who is responsible for entering orders and requests. 20 SCH.20/XCN.1 ST O The identifier of the entered by contact person. 20 SCH.20/XCN.2/FN.1 ST O The family name of the entered by contact person. 20 SCH.20/XCN.3 ST O The first name of the entered by contact person. 60

61 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 20 SCH.20/XCN.4 ST O The middle names and/or initials of the entered by contact person. 20 SCH.20/XCN.5 ST O The name suffix of the entered by contact person. A name suffix follows a person s full name and provides additional information about the person, for example M.A, M.F.A, MBA, Ph.D. 20 SCH.20/XCN.6 ST O The name prefix. A name prefix precedes a person s full name and provides additional information about the person, for example Dr, Mr. 21 SCH.21 - Entered by Phone Number 250 XTN X Y Not Currently Used. 22 SCH.22 - Entered by Location 23 SCH.23 - Parent Placer Appointment ID 24 SCH.24 - Parent Filler Appointment ID 80 PL X Not Currently Used. 75 EI X Not Currently Used. 75 EI X Not Currently Used. 25 SCH.25 - Status Code 250 CE O This field contains a code describing the status of the appointment with respect to the filler application. 25 SCH.25/CE.1 ST O 0278 The status code of the appointment as seen by the filler (hospital). 25 SCH.25/CE.2 ST O The status text. 25 SCH.25/CE.3 IS O 0396 The coding system used in CE SCH.26 - Placer Order Number 27 SCH.27 - Filler Order Number 22 EI X Y Not Currently Used. 22 EI X Y Not Currently Used. 61

62 3.14 The AIL segment (appointment information location resource) The AIL segment contains information about location resources (meeting rooms, operating rooms, examination rooms, or other locations) that can be scheduled. Resources included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Resources not controlled by a schedule are not identified on a schedule request using this segment. Location resources are identified with this specific segment because of the specific encoding of locations used by the HL7 standard. Table 18 - The AIL segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 AIL.1 - Set ID - AIL 4 SI R This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion. 2 AIL.2 - Segment Action Code 3 ID C This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. 3 AIL.3 - Location 80 PL C This field contains a coded identification of Resource ID the location being requested or scheduled 4 AIL.4 - Location Type- AIL 250 CE R 5 AIL.5 - Location Group 250 CE X 6 AIL.6 - Start Date/Time 26 TS X 7 AIL.7 - Start Date/Time Offset 20 NM X for an appointment. This field identifies the role of the location requested/scheduled for this appointment. Not Currently Used. Not Currently Used. Not Currently Used. 62

63 HL7 Seq HL7 Element Name 8 AIL.8 - Start Date/Time Offset Units Max Len HL7 Data Type 250 CE X 9 AIL.9 - Duration 20 NM X 10 AIL.10 - Duration Units 250 CE X 11 AIL.11 - Allow Substitution Code Opt Repeat Table Item # 10 IS X AIL.12 - Filler Status Code 250 CE X Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. 63

64 3.15 The ORC segment (common order segment) The common order segment is used to transmit fields that are common to all orders (all types of services that are requested). Table 19 - The ORC Segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 ORC.1 - Order Control 2 ID R N Determines the function of the order segment. 2 ORC.2 - Placer Order Number 3 ORC.3 - Filler Order Number 4 ORC.4 - Placer Group Number 22 EI X 22 EI X 5 ORC.5 - Order Status 2 ID X N ORC.6 - Response Flag 1 ID X ORC.7 - Quantity/Timing 200 TQ X Y 8 ORC.8 - Parent 200 CM X 9 ORC.9 - Date/Time of Transaction 26 TS X 10 ORC.10 - Entered By 250 XCN X Y 11 ORC.11 - Verified By 250 XCN X Y Not Currently Used Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. 64

65 HL7 Seq HL7 Element Name Max Len HL7 Data Type 12 ORC.12 - Ordering Provider 250 XCN X Y 13 ORC.13 - Enterer s Location 80 PL X 14 ORC.14 - Call Back Phone Number 250 XTN O Y/2 Opt Repeat Table Item # Not Currently Used. Not Currently Used. This field contains the telephone number to call for clarification of a request or other information regarding the order. 14 ORC.14/XTN.1 TN O This field is a telephone number displayed as an emergency number 14 ORC.14/XTN.2 ID O 0201 Telecommunications use code. 14 ORC.14/XTN.3 ID O 0202 Telecommunications equipment type. 14 ORC.14/XTN.4 ST O address. 14 ORC.14/XTN.6 NM O Area/city code. 14 ORC.14/XTN.7 ID O Telephone number. 15 ORC.15 - Order Effective 26 TS X Not Currently Used. Date/Time 1 ORC.16 - Order Control 250 CE X Not Currently Used. 6 Code Reason ORC.17 - Entering Organisation 250 CE X 18 ORC.18 - Entering Device 250 CE X 19 ORC.19 - Action By 250 XCN X Y 20 ORC.20 - Advanced Beneficiary Notice Code 21 ORC.21 - Ordering Facility Name 250 CE X XON X Y Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. 65

66 HL7 Seq HL7 Element Name 22 ORC.22 - Ordering Facility Address 23 ORC.23 - Ordering Facility Phone Number 24 ORC.24 - Ordering Provider Address 25 ORC.25 - Order Status Modifier Max Len HL7 Data Type 250 XAD X Y 250 XTN X Y 250 XAD X Y 250 CWE X N Opt Repeat Table Item # Not Currently Used. Not Currently Used. Not Currently Used. Not Currently Used. 66

67 3.16 The RF1 segment (referral information) This segment represents information that may be useful when sending referrals from the referring provider to the referred-to provider. Table 20 - The RF1 segment HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 1 RF1.1 - Referral Status 250 CE C This field contains the status of the referral as defined by either the referred-to or the referred-by provider. Please refer to the Online Referral workflow for specific usage of this field. 2 RF1.2 - Referral Priority 250 CE C This field contains the urgency of the referral. Please refer to the Online Referral workflow for specific usage of this field. 3 RF1.3 - Referral Type 250 CE C This field contains the type of referral. It is loosely associated with a clinical specialty or type of resource. Please refer to the Online Referral work flow for specific usage of this field. 4 RF1.4 - Referral Disposition 250 CE O Y This field contains the type of response or action that the referring provider would like from the referred-to provider. 5 RF1.5 - Referral Category 250 CE O This field contains the location at which the referral will take place. 6 RF1.6 - Originating Referral Identifier 30 EI R This field contains the originating application s permanent identifier for the referral. This is a composite field. 7 RF1.7 - Effective Date 26 TS C This field contains the date on which the referral is effective. Please refer to the Online Referral work flow for specific usage of this field. 67

68 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 8 RF1.8 - Expiration Date 26 TS O This field contains the date on which the referral expires. 9 RF1.9 - Process Date 26 TS O This field contains the date on which the referral originated. 10 RF Referral Reason 250 CE O Y This field contains the reason for which the referral will take place. 11 RF External Referral Identifier 30 EI O Y This field contains an external application s permanent identifier for the referral. 68

69 3.17 The SAC segment (specimen container detail) The container detail segment is the data necessary to maintain the containers that are being used throughout the laboratory automation system. Table 21 - The SAC segment HL7 Seq HL7 Element Name 1 SAC.1 - External Accession Identifier Max Len HL7 Data Type Opt Repeat Table Item # 80 EI O This field identifies the laboratory accession (see section Glossary). This identifier is assigned by the external laboratory information system. 2 SAC.2 - Accession Identifier 80 EI X Not Currently Used. 3 SAC.3 - Container Identifier 80 EI X Not Currently Used. 4 SAC.4 - Primary (parent) 80 EI X Not Currently Used. Container Identifier 5 SAC.5 - Equipment 80 EI X Not Currently Used. Container Identifier 6 SAC.6 - Specimen Source 300 CM X 0070/ Not Currently Used SAC.7 - Registration 26 TS X Not Currently Used. Date/Time 8 SAC.8 - Container Status 250 CE X Not Currently Used. 9 SAC.9 - Carrier Type 250 CE X Not Currently Used. 10 SAC.10 - Carrier Identifier 80 EI X Not Currently Used. 11 SAC.11 - Position in Carrier 80 NA X Not Currently Used. 12 SAC.12 - Tray Type - SAC 250 CE X Not Currently Used. 13 SAC.13 - Tray Identifier 80 EI X Not Currently Used. 14 SAC.14 - Position in Tray 80 NA X Not Currently Used. Example: If laboratory A sends a specimen to laboratory B, then within laboratory B this field contains accession identifier of lab A. 69

70 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 15 SAC.15 - Location 250 CE X Y Not Currently Used. 16 SAC.16 - Container Height 20 NM X Not Currently Used. 17 SAC.17 - Container 20 NM X Not Currently Used. Diameter 18 SAC.18 - Barrier Delta 20 NM X Not Currently Used. 19 SAC.19 - Bottom Delta 20 NM X Not Currently Used. 20 SAC.20 - Container 250 CE X Not Currently Used. Height/Diameter/Delta Units 21 SAC.21 - Container Volume 20 NM X Not Currently Used. 22 SAC.22 - Available Volume 20 NM X Not Currently Used. 23 SAC.23 - Initial Specimen 20 NM X Not Currently Used. Volume 24 SAC.24 - Volume Units 250 CE X Not Currently Used. 25 SAC.25 - Separator Type 250 CE X Not Currently Used. 26 SAC.26 - Cap Type 250 CE X Not Currently Used. 27 SAC.27 - Additive 250 CE X Y Not Currently Used. 28 SAC.28 - Specimen 250 CE X Not Currently Used. Component 29 SAC.29 - Dilution Factor 20 SN X Not Currently Used. 30 SAC.30 - Treatment 250 CE X Not Currently Used. 31 SAC.31 - Temperature 20 SN X Not Currently Used. 32 SAC.32 - Hemolysis Index 20 NM X Not Currently Used. 33 SAC.33 - Hemolysis Index 250 CE X Not Currently Used. Units 34 SAC.34 - Lipemia Index 20 NM X Not Currently Used. 35 SAC.35 - Lipemia Index 250 CE X Not Currently Used. Units 36 SAC.36 - Icterus Index 20 NM X Not Currently Used. 37 SAC.37 - Icterus Index Units 250 CE X Not Currently Used. 70

71 HL7 Seq HL7 Element Name Max Len HL7 Data Type Opt Repeat Table Item # 38 SAC.38 - Fibrin Index 20 NM X Not Currently Used. 39 SAC.39 - Fibrin Index Units 250 CE X Not Currently Used. 40 SAC.40 - System Induced 250 CE X Y Not Currently Used. Contaminants 41 SAC.41 - Drug Interference 250 CE X Y Not Currently Used. 42 SAC.42 - Artificial Blood 250 CE X Not Currently Used. 43 SAC.43 - Special Handling Considerations 44 SAC.44 - Other Environmental Factors 250 CE X Y Not Currently Used. 250 CE X Y Not Currently Used. 71

72 3.19 The MSA segment (message acknowledgement) The MSA segment contains information sent while acknowledging another message. Table 22 - The MSA segment HL7 HL7 ELEMENT NAME SEQ 1 MSA.1 Acknowledgment Code MAX LEN HL7 Data Type 2 MSA.2 Message Control ID 20 ST R 3 MSA.3 Text Message 80 ST O 4 MSA.4 Expected Sequence Number 5 MSA.5 Delayed Acknowledgment Type OPT Repeat Table Item # 2 ID R This field contains an acknowledgment code. 15 NM O 1 ID B MSA.6 Error Condition 250 CE O This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended. This optional field further describes an error condition. This text may be printed in error logs or presented to an end user. Use the ERR Segment rather than MSA.3 or MSA.6 for descriptions of error conditions. This optional numeric field is used in the sequence number protocol. This field allows the acknowledging system to use a user-defined error code to further specify AR or AE type acknowledgments. This field is a generalised replacement for MSA-3-text message. 72

73 3.20 The ERR segment (message error) The ERR segment is used to add error comments to acknowledgment messages. Table 23- The ERR segment HL7 SEQ HL7 ELEMENT NAME MAX LEN 1 ERR.1 Error Code and Location HL7 Data Type OPT Repeat Table Item # 80 CM R Y This field identifies an erroneous segment in another message. The second component is an index if there is more than one segment of type <segment ID>. For systems that do not use the HL7 Encoding Rules, the data item number may be used for the third component. The fourth component (which references HL7 Table Message error condition codes, is restricted from having any subcomponents as the subcomponent separator is now the CE s component separator. 73

74 3.21 The QRD segment (Query Definition Segment) The QRD segment is used to define a query. Table 24 - The QRD segment HL7 SEQ HL7 ELEMENT NAME MAX LEN 1 Query Date/Time 2 Query Format Code 3 Query Priority HL7 Data Type OPT Repeat Table Item # 26 TS R 25 Date the query was generated by the application program. 1 ID R Valid format codes are given in HL7 Table Query/response format code. 1 ID R Time frame in which the response is expected. Table values and subsequent fieldsspecify time frames for response. HL7 Table Query priority gives valid codes. 4 Query ID 10 ST R 28 Unique identifier for the query. Assigned by the querying application. Returned intactby the responding application. 5 Deferred Response Type 6 Deferred Response Date/Time 1 ID O Valid entries are from HL7 Table Deferred response type, to indicate before orlater than the date/time specified. 26 TS O 30 Date/time before or after which to send a deferred response. If not present, theresponse can be sent when it is available. 74

75 7 Quantity Limited request 8 Who Subject Filter 9 What Subject Filter 10 What Department Data Code 11 What data Code Value Qualifier 12 Query Results Level 10 CQ R Maximum length of the response that can be accepted by the requesting system. Valid responses are numerical values given in units specified in the second HL7 Table Quantity limited request gives valid entries, with codes for characters, lines, pages, records, or locally defined. The default value is lines.component. 60 XCN R Y 32 The subject of the query or who the inquiry is about. The field is allowed to repeat. 60 CE R Y Describes the kind of information required to satisfy the request. Valid codes are given in HL7 Table What subject filter and may be extended locally during implementation 60 CE R Y 34 Can include drug code, item number, etc., consistent with the subject in Can contain multiple occurrences separated by repetition delimiters. 20 CM O Y 35 Further refines the inquiry by data code qualifiers by providing a window or range to further refine the inquiry. This field contains components giving start and stop code values. 1 ID O Used to control level of detail in results. HL7 Table Query results level gives valid values valid values. 75

76 3.22 The QRF segment (Query Filter Segment) The QRF segment is used with the QRD segment to further refine the content of a query. Table 25- The QRF segment HL7 SEQ HL7 ELEMENT NAME MAX LEN HL7 Data Type OPT Repeat Table Item # 1 Where subject filter 20 ST R Y This field identifies the department, system, or subsystem to which the query pertains. This field may repeat as in LAB~HEMO, etc 2 When data start date/time 26 TS O This field has been retained for backward compatibility only. It is recommended to use QRF-9 When quantity/timing qualifier. When used for backward compatibility, this field contains the dates and times equal to or after which this value should be included. 3 When data end date/time 26 TS O This field has been retained for backward compatibility only. It is recommended to use QRF- 9 When quantity/timing qualifier. When used for backward compatibility, this field contains the dates and times equal to or before which this date should be included. This field contains the dates and times equal to or before which this date should be included. 4 What user qualifier 60 ST O Y This field contains an identifier to further define characteristics of the data of interest. 76

77 5 Other query subject filter 60 ST O Y This field contains a filter defined locally for use between two systems. This filter uses codes and field definitions that have specific meaning only to the applications and/or site involved. 6 Which date/time qualifier 12 ID O Y This field specifies the type of date referred to in QRF-2-When data start date/time and QRF-3- When data end date/time. 7 Which date/time status qualifier 8 Date/time selection qualifier 9 When quantity/timing qualifier 10 Search confidence threshold 12 ID O Y This field specifies the status type of objects selected in date range defined by QRF-2-When data start date/time and QRF-3-When data end date/time. 12 ID O Y This field allows the specification of certain types of values within the date/time range. 60 TQ O This field allows an interval definition to be used for specifying multiple responses to a query. With the addition of this filter, new query specifications should no longer use QRF-2-When data start date/time and QRF-3-When data end date/time in future implementations. 10 NM O This field contains a numeric value used to establish the minimum threshold match. The value instructs the responding system to return no records for patients whose match weight on the look-up was lower than this user-defined value. 77

78 3.23 The QAK segment (Query Response Status) The QAK segment contains information sent with responses to a query. HL7 SEQ HL7 ELEMENT NAME MAX LEN HL7 Data Type OPT Repeat Table Item # 1 Query Tag 32 ST C This field may be valued by the initiating system to identify the query, and may be used to match response messages to the originating query. If it is valued, the responding system is required to echo it back as the first field in the query acknowledgment segment (QAK). This field differs from MSA-2-message control ID in that its value remains constant for each message (i.e., all continuation messages) associated with the query, whereas MSA-2-Message control ID may vary with each continuation message, since it is associated with each individual message, not the query as a whole. QAK-1-Query tag is not conditional on the presence of the QRD-1-Query ID field in the original mode queries: in the original mode queries QAK-1-Query tag is not used. 2 Query Response Status 2 ID O This field allows the responding system to return a precise response status. It is especially useful in the case where no data is found that matches the query parameters, but where there is also no error. It is defined with HL7 Table Query response status. 3 Message Query Name 250 CE O This field contains the name of the query. These names are assigned by the function-specific chapters of this specification. Site-specific event replay query names begin with the letter Z. Refer to User defined table Query name for suggested values. 78

79 4 Hit Count 10 NM O This Payload 10 NM O Hits Remaining 10 NM O This field, when used, contains the total number of records found by the server that matched the query. For tabular responses, this is the number of rows found. For other response types, the Conformance Statement defines the meaning of a hit. This field, when used, contains the total number of matching records that the Server sent in the current response. Where the continuation protocol is used to transmit the response in partial installments, this number will differ from the value sent in QAK-4-Hit count total. This field, when used, contains the number of matching records found by the Server that have yet to be sent. It is only meaningful when the Server uses the continuation protocol to transmit partial responses. 79

80 3.22 The TXA segment (Transcription Document Header Segment) The TXA segment contains information specific to a transcribed document but does not include the text of the document. Table 26- The TXA segment HL7 SEQ HL7 ELEMENT NAME MAX LEN HL7 Data Type OPT Repeat Table Item # 1 Set ID- TXA 4 SI R This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction. 2 Document Type 30 IS R This field identifies the type of document (as defined in the transcription system). Refer to User-defined Table Document type for suggested values. The organisation is free to add more entries. 3 Document Content Presentation 2 ID C This is a conditional field which is required whenever the message contains content as presented in one or more OBX segments. This field identifies the method by which this document was obtained or originated. Refer to HL7 Table 0191 Type of referenced data for valid values. 4 Activity Date/Time 26 TS O This field contains the date/time identified in the document as the date a procedure or activity was performed. This date can identify date of surgery, non-invasive procedure, consultation, examination, etc. 5 Primary Activity Provider Code/Name 250 XCN C Y This field contains the name of the person identified in the document as being responsible for performing the procedure or activity. This field includes the code and name (if available) of the caregiver. This field is conditional based upon the presence of a value in TXA-4-Activity date/time 6 Origination Date/Time 26 TS O This field contains the date and time the document was created (i.e., dictated, recorded, etc.). 80

81 7 Transcription Date/Time 26 TS C This field contains the date and time the input was actually transcribed. This field is conditional based upon the presence of a value in TXA-17- Document completion status of anything except dictated. 8 Edit Date/Time 26 TS O Y This field contains the date and time the document was edited. 9 Originator Code/Name 250 XCN O Y This field identifies the person who originated (i.e., dictated) the document. The document originator may differ from the person responsible for authenticating the document. 10 Assigned Document Authenticator 11 Transcriptionist Code/Name 12 Unique Document Number 250 XCN O Y This field identifies the person(s) responsible for authenticating the document, who may differ from the originator. Multiple persons may be responsible for authentication, especially in teaching facilities. This field is allowed to repeat an undefined number of times. 250 XCN C Y This field identifies the person transcribing the document. This is a conditional value; it is required on all transcribed documents. 30 EI R This field contains a unique document identification number assigned by the sending system. This document number is used to assist the receiving system in matching future updates to the document, as well as to identify the document in a query. When the vendor does not provide a unique document ID number, some type of document identifier should be entered here, or the Unique Document File name should be utilized. See Chapter 2, Section , XTN - extended telecommunication number. Where the system does not customarily have a document filler number, this number could serve as that value, as well. 81

82 13 Parent Document Number 30 EI C This field contains a document number that identifies the parent document to which this document belongs. The parent document number can be used to assist the receiving system in matching future updates to this document. This is a conditional field that is always required on T05 (document addendum notification), T06 (document addendum notification and content), T09 (document replacement notification), and T10 (document replacement notification and content) events. 14 Placer Order Number 22 EI O Y This field is the placer application s order number. This is a composite field. The first component is a string of characters that identifies an individual order (e.g., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the (filler) assigning authority of the placing application. The (filler) assigning authority is a string of characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique entity identifiers. The components are separated by component delimiters 82

83 15 Filler Order Number 22 EI O This field is the order number associated with the filling application. Where a transcription service or similar organisation creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (e.g., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique. 16 Unique Document File Name 17 Document Completion Status 18 Document Confidentiality Status 30 ST O This field contains a unique name assigned to a document by the sending system. The file name is used to assist the receiving system in matching future updates to the document. 2 ID R This field identifies the current completion state of the document. This is a required, table-driven field. Refer to HL7 table Document completion status for valid values. 2 ID O This is an optional field which identifies the degree to which special confidentiality protection should be applied to this information. The assignment of data elements to these categories is left to the discretion of the healthcare organisation. Refer to HL7 table Document confidentiality status for valid values. 83

84 19 Document Availability Status 2 ID O This is an optional field which identifies a document s availability for use in patient care. If an organisation s business rules allow a document to be used for patient care before it is authenticated, the value of this field should be set to AV. If a document has been made available for patient care, it cannot be changed or deleted. If an erroneous document has been made available at any point in time and a replacement is not appropriate, then it may be marked as Cancelled and removed, as in the case of a document being assigned to the wrong patient. Additional information must be provided via an addendum, which is separately authenticated and date/time stamped. If the content of a document whose status is Available must be revised, this is done by issuing a replacement, which is separately authenticated and date/time stamped. Refer to HL7 table Document availability status for valid values. 20 Document Storage Status 2 ID O This optional field identifies the storage status of the document. Refer to HL7 table Document storage status for valid values. 21 Document Change Reason 30 ST C This free text field (limited to 30 characters) contains the reason for document status change. 84

85 22 Authentication Person, Time Stamp 23 Distributed Copies (Code and Name of Recipients) 250 PPN C Y This is a conditional field. When the status of TXA-17-Document completion status is equal to AU (authenticated) or LA (legally authenticated), all components are required. This field contains a set of components describing by whom and when authentication was performed. Whenever any one of the ID number - Name type code components is valued, the when authenticated component, which is time stamp, must be valued as non-null. If the time component of a set is valued as non-null, the person component becomes required. These subcomponents are normally delimited by an ampersand (&). See Chapter XCN O Y This component identifies the person who has authenticated the document (either manually or electronically). 85

86 3.22 The DSC segment () The DSC segment is used in the continuation protocol. Table 27- The DSC segment HL7 SEQ HL7 ELEMENT NAME MAX LEN 1 DSC.1 Continuation Pointer HL7 Data Type OPT Repeat Table Item # 180 ST O Y This field contains the continuation pointer. In an initial query, this field is not present. If the responder returns a value of null or not present, then there is no more data to fulfill any future continuation requests. For use with continuations of unsolicited messages, see chapter 5 and section Error! Reference source not found., "Error! Reference source not found.. Note that continuation protocols work with both display- and record-oriented messages. 2 DSC.2 Continuation Style 1 ID O Indicates whether this is a fragmented message (see Section Error! Reference source not found., "Error! Reference source not found."), or if it is part of an interactive continuation message (see Section 5.6.3, "Interactive continuation of response messages"). 86

87 4 Message flows This section describes the clinical scenarios, also known as message flows, supported by the Standard. Each message flow will be described into four parts use case, interaction model, message structure, and segment specialisation. A brief description is provided of the use case associated with the message flow. The use case is described in technology-free terminology which treats the business process as a black box and describes the business process that is used by its business actors (healthcare professionals) to achieve their goals (e.g. order a test, send a referral). An interaction model specifies a set of distinct artefacts that collectively describe the dynamic and static behaviour of the data exchanges. The artefacts consist of a set of interactions, each describes a single one-way communication. Trigger events, actors and message types will be identified in the interaction model. For each interaction, the abstract message type will be identified and the minimum segments recommended for inclusion in the message are documented. Finally, where there are further constraints for a segment element in a specific message flow, these constraints and conditions will be described in the segment specialisation section. The message flows covered by the GPMS are: Emergency Department Attendance Admission Notification Administrative Discharge Clinical Discharge Summary Death Notification Cooperative Discharge Summary Outpatient Department Appointment Waiting List Notification Online Referral and Response Laboratory Order Unsolicited Laboratory Result Unsolicited Radiology Result Corrected Results. 87

88 4.1 Emergency Department (ED) attendance General Practice Messaging Standard Version 3.0 Use case: A person attends an emergency department and the attendance is recorded on the local system. An electronic notification of the attendance may be sent to other systems. The message type used is the ADT_A01 message type. For the purpose of this standard the minimum emergency department attendance notification message contains the following segments: MSH Message Header PID Patient Identification EVN Event Segment PV1 Event Type/Patient Visit PV2 Event Type/Additional information. The following conditions apply when generating an emergency department attendance notification message: PV1.14 (Admit Source). This element is required PV1.44 (Admit Date/Time.) This element is required. 88

89 4.2 Admission Use case: A patient is admitted as an inpatient to a healthcare facility and this event is recorded on the local system. An electronic notification of the admission of the patient is sent to other systems. The message type used is the ADT_A01 message type. For the purpose of this standard the minimum admission notification message contains the following segments: MSH Message Header PID Patient Identification EVN Event Segment PV1 Event Type/Patient Visit PV2 Event Type/Additional information. The following conditions apply when generating an admission notification message PV1.14 (Admit Source). This element is required PV1.44 (Admit Date/Time). This element is required. 89

90 4.3 Administrative discharge Use case: A person is discharged from a healthcare facility and the administrative event is recorded on the local system. A notification message is sent containing administrative information relating to the admission and discharge. The message type used is the ADT_A03 message type. For the purpose of this standard the minimum administrative discharge notification message contains the following segments: MSH Message Header PID Patient Identification EVN Event Segment PV1 Event Type/Patient Visit PV2 Event Type/Additional information The following conditions apply when an administrative discharge notification message: PV1.36 (Discharge Disposition). This element is required PV1.37 (Discharge to Location). This element is optional in this context but if know it is strongly recommended that it is populated. PV1.45 (Discharge Date/Time). This element is required. 90

91 4.4 Admission Notification Use case: A patient is discharged after an inpatient stay from a healthcare institution, a clinical discharge is recorded on the system and this clinical discharge is sent to other systems. The message type used is the REF_I12 message type. For the purpose of this standard, the minimum clinical discharge summary message contains the following segments: MSH Message Header PID Patient Identification PRD Provider Data DG1 Diagnosis PV1 Patient Visit NTE Notes and Comments. The following conditions apply when generating a clinical discharge summary message PV1.36 (Discharge Disposition). This element is required PV1.37 (Discharge to Location). This element is optional in this context but if know it is strongly recommended that it is populated PV1.45 (Discharge Date/Time). This element is required NTE.3 (Comment). It is strongly recommended that the clinical information is included in this element. 91

92 4.5 Death notification Use case: The death of a patient is recorded on the local system. An electronic notification of the death of the patient is sent to other systems. The message type used is the ADT_A03 message type. For the purpose of this standard the minimum death notification message contains the following segments: MSH Message Header PID Patient Identification EVN Event Segment PV1 Event Type/Patient Visit PDA Patient Death and Autopsy PV2 Event Type/Additional information The following conditions apply when generating a death notification message: PID.29 (Patient Death Date and Time). This element is required. PID.30 (Patient Death Indicator). This element is required. The following recommendations apply when generating a death notification message: PDA.1 (Death Cause Code). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PDA.2 (Death Location). This field is optional but if this information is available it is strongly recommended that this field is populated in the message. 92

93 4.6 Cooperative discharge summary General Practice Messaging Standard Version 3.0 Use case: A patient contacts a GP out-of-hours cooperative and is assessed by a nurse or general practitioner. Clinical information relating to the patient is recorded on the system and a summary of this information is sent to the patient s general practitioner. A patient contacts a GP out of hours co-operative and is assessed by a nurse or general practitioner Source System REF_I12 ACK_I12 Destination System The message type used is the REF_I12 message type. For the purpose of this standard the minimum cooperative discharge summary message contains the following segments: MSH Message Header PID Patient Identification PRD Provider Data DG1 Diagnosis NTE Notes and Comments OBR Observation Request OBX Observation Result 93

94 4.7 Outpatient department appointment General Practice Messaging Standard Version 3.0 Use case: An appointment is scheduled for a patient on a hospitals administrative IT system. The appointment may be subsequently rescheduled, modified or cancelled or the patient may not attend the appointment. Notification of each of these events may be sent to the patient s recorded general practitioner. The message type used is the SIU message type. The event type may be S12, S13, S14, S15, S26 depending on the trigger. For the purpose of this standard the minimum outpatient department appointment message contains the following segments: MSH Message Header PID Patient Identification RGS Resource Group AIP Appointment Information Personnel Information SCH Scheduling Activity Information NTE Notes and Comments. 94

95 4.8 Waiting list notification Use case: A patient is placed on a waiting list for an appointment. The waiting list entry may be subsequently modified or removed. Notifications of these events may be messaged to the patient s general practitioner. The message type used is the SIU message type. The event type may be S12, S13, S14, and S15 depending on the trigger. For the purpose of this standard the minimum waiting list notification message contains the following segments: MSH Message Header PID Patient Identification RGS Resource Group AIL Appointment Information Location Information AIP Appointment Information Personnel Information SCH Scheduling Activity Information NTE Notes and Comments. 95

96 4.9 Online Referral and Response Use case: A GP refers a patient to a hospital consultant. The general practitioner records the details of the referral on the source system and the referral is available to the referred to provider. The referred to provider reviews the referral and advice or information on further management is provided to the referrer within an agreed time period. A clinician creates a referral to a consultant. Source System REF_I12 ACK_I12 RRI_I12 ACK_I12 Destination System The referral is reviewed by the consultant and a management advice is decided. The online referral workflow consists of a referral message and a referral response message. The message type used for the referral is the REF_I12 message type; the message type used for the referral response message is the RRI_I12 message type. For the purpose of this standard the minimum referral message contains the following segments: MSH Message Header RF1 Referral Details PRD Provider Data PID Patient Identification OBR Observation Request OBX Observation Response PV1 Event Type/Patient visit NTE Notes and Comments. 96

97 For the purpose of this standard the minimum referral response message contains the following segments: MSH Message Header RF1 Referral Details PRD Provider Data PID Patient Identification OBR Observation Request OBX Observation Response NTE Notes and Comments. The following conditions apply when generating a referral message: OBR.2 (Placer Order Number). This element is required. The following recommendations apply when generating a referral message: RF1.1 (Referral Status). This field is optional but if this information is available it is strongly recommended that this field is populated in the message RF1.2 (Referral Priority). This field is optional but if this information is available it is strongly recommended that this field is populated in the message RF1.3 (Referral type). This field is optional but if this information is available it is strongly recommended that this field is populated in the message RF1.7 (Effective Date). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.2 (Provider Name). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.3 (Provider Address). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.4 (Provider Location). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.5 (Provider Communication Information). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.7 (Provider Identifiers). This field is optional but if this information is available it is strongly recommended that this field is populated in the message. 97

98 The following conditions apply when generating a referral response acknowledgement message: OBR.2 (Placer Order Number). This element is required. The following recommendations apply when generating a referral response message: PRD.2 (Provider Name). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.3 (Provider Address). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.4 (Provider Location). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.5 (Provider Communication Information). This field is optional but if this information is available it is strongly recommended that this field is populated in the message PRD.7 (Provider Identifiers). This field is optional but if this information is available it is strongly recommended that this field is populated in the message. 98

99 4.10 Laboratory order Use case: A clinician orders a laboratory test for a patient. The clinician records the detail of the order on an electronic system and the details of the order are sent to the performing laboratory department. If there is an error in the structure or content of the message the destination system sends an error message in response to the order. When a result is available an electronic message containing the result will be returned to the original practitioner who ordered the test or to the healthcare practitioner(s) to whom a copy has been requested to be sent. The laboratory order workflow consists of a laboratory order message, a laboratory order acknowledgement message and a laboratory result message. The message type used for the laboratory order is the OML_O21 message type. The message type used for the laboratory order acknowledgement is the ORL_O22 and the message type used for the laboratory result is the ORU_R01. For the purpose of this standard, the minimum laboratory order message OML_O21 contains the following segments: MSH Message Header PID Patient Identification PV1 Event Type/Patient Visit ORC Common Order Segment OBR Observation Request SAC Specimen Container Details OBX Observation Response DG1 Diagnosis NTE Notes and Comments. 99

100 For the purpose of this standard, the minimum laboratory order acknowledgement message response ORL_O22 contains the following segments: MSH Message Header MSA Message Acknowledgement ERR Message Error Segment For the purpose of this standard, the minimum laboratory result message ORU_R01 contains the following segments: MSH Message Header PID Patient Identification PV1 Event Type/Patient Visit OBR Observation Request OBX Observation Response NTE Notes and Comments The following conditions apply when generating a laboratory order message OML_O21: OBR.2 (Placer Order Number). This element is required OBR.7 (Observation Date/Time). This element is required when the specimen accompanies the laboratory order. The following conditions apply when generating a laboratory results message ORU_R01: OBR.2 (Placer Order Number). This element is required OBR.7 (Observation Date/Time). This element is required OBR.14 (Specimen received Date/Time). This element is required OBR.24 (Diagnostic Serv Sect ID). This element is required. Many report headers (OBR) may be sent after each patient segment, with many separate observation segments (OBX) after each OBR. Note segments (NTE) may be inserted as a PID, OBR, OBX segment. The note segment applies to the segment that immediately precedes it. 100

101 4.11 Unsolicited Radiology result Use case: A radiology department performs a radiological investigation on a patient. When a result is reported this is communicated with the healthcare practitioner responsible for ordering the investigation or to the healthcare practitioner to whom a copy has been requested to be sent. A radiological investigation is performed and a result is available Source System ORU_R01 ACK_R01 Destination System The radiology results workflow consists of a radiology result message; the message type used for the radiology result is the ORU_R01. For the purpose of this standard the minimum radiology result message ORU_R01 contains the following segments: MSH Message Header PID Patient Identification PV1 Event Type/Patient Visit OBR Observation Request OBX Observation Response NTE Notes and Comments. The following conditions apply when generating a radiology order message ORU_R01: OBR.7 (Observation Date/Time). This element is required OBR.24 (Diagnostic Serv Sect ID). This element is required OBR.25 (Result Status). This element is required. 101

102 For the purpose of this standard the minimum unsolicited radiology result acknowledgement message response ACK_R01 contains the following segments: MSH Message Header MSA Message Acknowledgement ERR Message Error Segment. Many report headers (OBR) may be sent after each patient segment, with many separate observation segments (OBX) after each OBR. Note segments (NTE) may be inserted as a PID, OBR, OBX segment. The note segment applies to the segment that immediately precedes it. Note: Status Information The complete set of allowed values for the result status held in OBX-11 as defined by HL7 table (0123). The following codes are in used in Ireland and can be expected in OBX.11: Final Result (F) - This code indicates that the result is final. It can only be changed by a corrected result (C). Preliminary Result (P) This code indicates that a further result (for the same type of test) is expected. Partial Result (S) - A test can be composed of multiple tests. If any of the tests are completed a partial result is reported. The report will indicate that the other tests will follow. Wrong Result (W) If a result has been verified as incorrect (wrong); a replacement (corrected) result may be transmitted later. Corrected Result (C) - Code C indicates that data contained in the observation value field will be replaced because the previous results were wrong. Note: Copy results to: Results may be copied to other clinicians other than the clinician who ordered the tests in question. OBR.16 and OBR.28 fields are used in combination to indicate if the message is a copy sent to the ordering provider a copy sent to a clinician who was not the original ordering provider. 102

103 In the former scenario the XCN.16 component will not contain the value COPY_TO. In the latter scenario, the value in XCN.16 field in OBR.16 will be set to COPY_TO. In these instances vendor systems need to route the message to the individual identified in OBR.28 with the value COPY_TO set in XCN Unsolicited laboratory result Use Case: A laboratory receives a specimen and analyses the specimen. When a result is available this is communicated to the healthcare practitioner responsible for ordering the investigation or to the healthcare practitioner to whom a copy has been requested to be sent. The patients specimen is processed and a result is available Source System ORU_R01 ACK_R01 Destination System The laboratory results workflow consists of a laboratory results message. The message type used for the laboratory result is the ORU_R01. For the purpose of this standard the minimum laboratory result message ORU_R01 contains the following segments: MSH Message Header PID Patient Identification PV1 Event Type/Patient Visit OBR Observation Request OBX Observation Response NTE Notes and Comments. For the purpose of this standard the minimum unsolicited laboratory result acknowledgement message ACK_R01 response contains the following segments: MSH Message Header 103

104 MSA ERR Message Acknowledgement Message Error Segment. The following conditions apply when generating a laboratory order message ORU_R01: OBR.7 (Observation Date/Time). This element is required OBR.14 (Specimen Received Date/Time). This element is required OBR.24 (Diagnostic Serv Sect ID). This element is required. Many report headers (OBR) may be sent after each patient segment, with many separate observation segments (OBX) after each OBR. Note segments (NTE) may be inserted as a PID, OBR, OBX segment. The NTE segment applies to the segment that immediately precedes it. Note: Status Information The complete set of allowed values for the result status held in OBX-11 as defined by HL7 table (0123). The following codes are in used in Ireland and can be expected in OBX.11: Final Result (F) - This code indicates that the result is final. It can only be changed by a corrected result (C). Preliminary Result (P) This code indicates that a further result (for the same type of test) is expected. Partial Result (S) - A test can be composed of multiple tests. If any of the tests are completed a partial result is reported. The report will indicate that the other tests will follow. Wrong Result (W) If a result has been verified as incorrect (wrong); a replacement (corrected) result may be transmitted later. Corrected Result (C) - Code C indicates that data contained in the observation value field will be replaced because the previous results were wrong. Note: Copy results to: Results may be copied to other clinicians other than the clinician who ordered the tests in question. OBR.16 and OBR.28 fields are used in combination to indicate if the message is 104

105 a copy sent to the ordering provider a copy sent to a clinician who was not the original ordering provider. In the former scenario the XCN.16 component will not contain the value COPY_TO. In the latter scenario, the value in XCN.16 field in OBR.16 will be set to COPY_TO. In these instances vendor systems need to route the message to the individual identified in OBR.28 with the value COPY_TO set in XCN Corrected Results A laboratory received a specimen, analysed the specimen and communicated the result to the healthcare practitioner responsible for ordering the specimen. Information in the message indicated the message was a final result for the tests requested. Subsequently, the result is corrected and the laboratory sends a message to the healthcare practitioner to indicate the previous result requires correction. The patients specimen is processed and a result is available Source System ORU_R01 ACK_R01 Destination System The laboratory results workflow consists of a laboratory results message. The message type used for the laboratory result is the ORU_R01. For the purpose of this standard the minimum corrected result message ORU_R01 contains the following segments: MSH Message Header PID Patient Identification PV1 Event Type/Patient Visit OBR Observation Request OBX Observation Response NTE Notes and Comments. 105

106 For the purpose of this standard the minimum corrected results message ACK_RO1 response contains the following segments: MSH Message Header MSA Message Acknowledgement ERR Message Error Segment. The following conditions apply when generating a laboratory order message ORU_R01: OBR.7 (Observation Date/Time). This element is required OBR.14 (Specimen Received Date/Time). This element is required OBR.24 (Diagnostic Serv Sect ID). This element is required OBR.25 (Result Status). This element is required OBX.11 (Observ Result Status). This element is required for each OBX segment corrected the value in the OBX.11 field should be set to C and the value in the corresponding OBR.25 segment also should be set to C. Note: Code F in the OBX.25 field indicates that the result has been verified to be correct and final. Code C indicates that data contained in the OBX-5-observation value field are to replace previously transmitted (verified and) final result data with the same observation ID OBX.3 (including suffix, if applicable) and observation sub-id usually because the previous results were wrong. Note: Copy results to: Results may be copied to other clinicians other than the clinician who ordered the tests in question. OBR.16 and OBR.28 fields are used in combination to indicate if the message is a copy sent to the ordering provider a copy sent to a clinician who was not the original ordering provider. In the former scenario the XCN.16 component will not contain the value COPY_TO. In the latter scenario, the value in XCN.16 field in OBR.16 will be set to COPY_TO. In these instances vendor systems need to route the message to the individual identified in OBR.28 with the value COPY_TO set in XCN

107 5 Electronic prescribing in the community General Practice Messaging Standard Version 3.0 In 2013, the Authority reviewed eprescribing and electronic transfer of prescriptions (ETP) initiatives internationally to inform the adoption of appropriate standards in Ireland. Each country reviewed focused mainly on prescribing and dispensing of medication in the community rather than from the hospital setting. This is explained as a consequence of both GPs and pharmacists having similar processes with their peers and hence being able to support computerisation of the process. By contrast, hospital medication management processes are typically more complex, making standardisation and computerisation more complicated (1). Each country reviewed has also undertaken the processes in a phased and incremental approach, with paper systems either included as part of the solution or paper systems supported in parallel with the electronic messages. In initial phases the authoritative prescription continued to be the paper prescription; this carried a bar coded identifier of an electronic prescription which allowed dispensers to retrieve the electronic prescription from a message broker. In subsequent phases the electronic prescription became the authoritative prescription; this required legislation for digital signatures. It is likely that a repository to store prescribed and dispensed medications can be facilitated at a later phase in the implementation of ETP and may function as a medication record. The implementation of patient medication records are considered out of scope for electronic transfer of prescription records but the ETP solutions may facilitate the implementation of such records. The Authority has developed messaging specifications based on the HL7 V2.4 standard and the Clinical Document Architecture standard for the implementation of the electronic transfer of prescriptions. Use cases for this project have been prepared in consultation with experts from the community pharmacy and primary care sectors. This section outlines the use cases with sample clinical scenarios which justify the use cases within the agreed scope of the project. The use cases are illustrated in figure 1 below. 107

108 Figure 1. Electronic Transfer of Prescriptions 5.1 Scenario 1 A patient attends a prescriber who generates an electronic prescription which is sent and stored at the message exchange (Healthlink). The patient subsequently attends a dispenser and provides the dispenser with a bar coded paper prescription which allows the dispenser to identify and retrieve the prescription from the message exchange. The dispenser then dispenses the prescribed medication in accordance with the prescription information. Finally, if no medications are dispensed for the prescription and the dispenser indicates this by returning the unfulfilled items in a message back to the message exchange. The use cases (UCs) to support this scenario are depicted in Figure 2 below. 108

109 5.1.1 Clinical examples to inform use cases General Practice Messaging Standard Version 3.0 The patient attends a prescriber and is prescribed medication (UC 1) A patient may contact a prescriber requesting that a repeat prescription is issued. (UC 1) A next of kin or carer may request a prescription to be issued for a patient (UC 1) The patient or a person on their behalf attends the pharmacy of his/her choice in order to have medication items dispensed. The dispenser retrieves the electronic prescription from the message exchange. (UC 2) A prescription is presented to a dispenser, the person the prescription relates to may present in person or another person may collect the prescription on their behalf. The dispenser retrieves the electronic message from the message exchange. The dispenser is able to dispense all medication items on the prescription (UC 2 and UC 3). The patient receives a prescription from a prescriber and decides to have the price checked at the pharmacy without any of the prescribed medication items being dispensed. (UC 2 and UC 4) The patient attends the pharmacy of his/her choice but the pharmacy does not have the required medication in stock and no medication items are dispensed (UC 2 and UC 4) Message flows Figure 2 below illustrates the message flows generated when a patient attends a prescriber and subsequently attends a dispenser. On generation of a paper prescription, the prescriber s practice management system creates an electronic version of the prescription which is sent to a message exchange. On receipt of the paper prescription, which contains a unique identifier for the electronic prescription, the dispenser retrieves the electronic prescription from the message exchange and subsequently notifies the message exchange that the prescription has been dispensed. 109

110 Figure 2. Electronic prescribing and dispensing of an electronic prescription 1 1 The repository is included in message flow diagrams for completeness but would be considered out of scope within the electronic transfer of prescription solution. Messages forwarded to the repository and from the repository should be seen as optional and possibly a future requirement. 110

111 Use case 1 Medication items are prescribed The message type used for the electronic prescription is MDM^T02 with a MIME encapsulated Clinical Document Architecture (CDA) prescription document carried in the OBX segment. For the purpose of this standard the MDM^T02 contains the following segments: MSH Message Header EVN Event Type PID Patient Identification PV1 Patient Visit TXA Document Notification OBX Observation/Result. For the purpose of this standard the acknowledgement response to receiving an electronic prescription is ACK^T02. It consists of the following segments: MSH Message Header MSA Message Acknowledgement ERR Error Information. Use case Use case 2 Electronic prescription is retrieved from the message exchange The message type used to query the message exchange and retrieve the electronic prescription is QRY^T12. For the purpose of this standard the QRY^T12 contains the following segments: MSH Message Header QRD Query Definition QRF Query Filter. The message type used to return the relevant document for the query is DOC^T12. For the purpose of this standard the acknowledgement response to receiving an electronic prescription is DOC^T12. MSH Message Header MSA Message Acknowledgement ERR Error Segment QRD Query Definition EVN Event Segment PID Patient Identification 111

112 PV1 Event Type/Patient Visit OBX Observation Response. Use case 3 All medication items dispensed The message type used for the electronic prescription is MDM^T02 with a MIME encapsulated Clinical Document Architecture (CDA) prescription document carried in the OBX segment. For the purpose of this standard the acknowledgement response to receiving an electronic prescription is ACK^T02. Use case 4 No medication items dispensed The message type used for the electronic prescription is MDM^T02 with a MIME encapsulated Clinical Document Architecture (CDA) prescription document carried in the OBX segment. For the purpose of this standard the acknowledgement response to receiving an electronic prescription is ACK^T Scenario 2 The dispenser is able to prescribe some of the items prescribed. After the patient collects the medication the dispenser updates the message exchange of medications dispensed. If certain medications are not dispensed then the dispenser updates the medication exchange to indicate this Clinical examples The patient attends a prescriber and receives a prescription for one or more medication items. The pharmacist does not have all medications in stock but dispenses some of the medication items prescribed. (Use case 5). The patient attends the GP and receives a prescription for more than one medication. The patient decides to collect only part of the prescription; therefore some of the medication items are dispensed (Use case 5). A GMS patient attends the GP and receives a prescription for more than one medication item. Some medications are not covered under the GMS scheme and are therefore not dispensed (Use case 5). 112

113 5.1.2 Message flows Figure 3 below illustrates message flows generated when a patient attends a dispenser and only some of the items on the prescription are dispensed. Figure 2. Some medications are not dispensed Use case 5 Some medication items are not dispensed The message type used for the electronic prescription is MDM^T02 with a MIME encapsulated Clinical Document Architecture (CDA) prescription document carried in the OBX segment. For the purpose of this standard the acknowledgement response to receiving an electronic prescription is ACK^T Scenario 3 A patient attends a dispenser with a paper prescription. The pharmacist dispenses the medication items to the patient and records this on their computer system. No electronic prescription record exists for the prescription from the prescriber. 113

114 5.3.1 Clinical examples A patient attends a prescriber who has yet to computerise processes and is given a handwritten, typed or printed prescription (Use case 6). Information systems are not functioning and the prescriber must revert to manual processes and prescribe using a paper handwritten prescription (Use case 6). A patient is reviewed by a prescriber during a home visit and the prescriber writes a paper prescription. A patient is reviewed by a prescriber out of hours and the prescriber creates a paper prescription Message flows Figure 4 below illustrates the message flows generated when a patient attends dispenser with a paper prescription and there is no electronic version of the prescription. Figure 3. Medications are dispensed where no electronic prescription ever existed 114

115 Use case 6 Medication items are dispensed (no electronic prescription exists) The message type used for the electronic prescription is MDM^T02 with a MIME encapsulated Clinical Document Architecture (CDA) prescription document carried in the OBX segment. For the purpose of this standard the acknowledgement response to receiving an electronic prescription is ACK^T02. Note: if an electronic repository exists the message exchange broker may forward the MDM^T02 message to it. The electronic repository responds with ACK^T Scenario 4 A patient attends a prescriber and is prescribed medication items. The patient visits a dispenser to have the medication items dispensed. Prior to dispensing a medication item, the dispenser decides a substitution is to be made for one of the medication items which requires authorisation by the prescriber. The authorisation to change the medication items is obtained and a prescriber subsequently issues an updated prescription Clinical examples It may occur that the dispenser feels it is necessary to change the dose of a medication due to an error on the prescription or other clinical factors (Use case 7). The duration that the medication is to be taken may require a change (Use case 7). The route of administration of the medication may need to be changed (Use case 7). The dispenser may have knowledge of an allergy that requires substitution for a different type of medication (Use case 7) Message flows Figure 5 below illustrates the message flows generated when a patient attends dispenser who modifies prescription items requiring authorisation from the prescriber. 115

116 Figure 4 Dispenser modifies prescription item and this requires authorisation from the prescriber Use case 7 Dispenser modifies some medication items (electronic prescription exists) A message is sent from the dispenser to the message exchange after substitution of a prescribed medication item. The message type used to indicate the medication items which were substituted is MDM^T02 and is sent from the dispenser to the message exchange. For the purpose of this standard, the acknowledgement response to receiving an electronic prescription is ACK^T02. This message may be sent back to the original prescriber. The prescriber may update the original prescription to note the updated content. The message type used to indicate certain prescribed medications items were changed is MDM^T02 with a MIME encapsulated Clinical Document Architecture (CDA) prescription document carried in the OBX segment. 116

117 For the purpose of this standard the acknowledgement response to the indication of medications dispensed is ACK^T02. The message is sent to the message exchange and may be forwarded from there to an electronic repository. 5.5 Scenario 5 A patient attends a doctor and is prescribed medication items on a paper prescription. The patient visits a pharmacy to have the medication items dispensed. Prior to dispensing medication a substitution is made for one of the medication items which requires authorisation by the doctor. The authorisation is obtained and a doctor sends another paper prescription to the pharmacy Clinical examples It may occur that the pharmacist feels it is necessary to change the dose of a medication due to an error on the prescription or other clinical factors (Use case 8). The duration that the medication is to be taken may require a change (Use case 8). The route of administration of the medication may need to be changed (Use case 8). The pharmacist may have knowledge of an allergy that requires substitution for a different type of medication (Use case 8) Message flows Figure 6 below illustrates the message flows generated when a patient attends dispenser who modifies prescription items requiring authorisation from the prescriber. In this instance no electronic prescription existed. 117

118 Figure 5 Pharmacist substitutes medication with required prescriber to authorise and issue a second prescription UC8 Dispenser modifies medication items (no electronic prescription exists) The message type used for the dispenser to notify the message exchange that medication has been dispensed is MDM^T02. For the purpose of this standard, the response is ACK^T02. This message may also be forwarded to the electronic repository from the message exchange. 5.6 Scenario 6 A patient attends a prescriber who generates an electronic prescription which is sent and stored in the message exchange. After the patient has left, the prescriber decides the prescription should be cancelled. 118

119 The patient subsequently attends a dispenser and provides the dispenser with a bar coded paper prescription which allows the dispenser to identify and retrieve the prescription from the message exchange. The dispenser retrieves a cancelled prescription indicating that the prescriber has decided that the prescription is not required. The dispenser informs the patient of the cancellation. A patient attends a prescriber who generates an electronic prescription which is sent and stored in the message exchange. The patient subsequently attends a dispenser and provides the dispenser with a bar coded paper prescription which allows the dispenser to identify and retrieve the prescription from the message exchange. The dispenser decides that the prescription should be cancelled. Authorisation is received from the prescriber and the dispenser cancels the prescription and informs the patient Clinical examples The prescriber or dispenser suspects medication misuse or abuse (Use case 9 and 10). The dispenser discovers the prescriber is not authorised to prescribe a certain type of medication (Use case 10). The dispenser may decide it is unsafe to dispense the medication prescribed (Use case 10). The dispenser may discover that the prescription is for an unlicensed medication and may cancel the prescription (Use case 10). 119

120 5.6.2 Message flows Figure 7 below illustrates the message flows generated when either a prescriber or dispenser cancels a prescription. Figure 6 Prescriber or dispenser cancels prescription Use case 9 Prescriber cancels prescription The message type used for the dispenser to notify the message exchange that medication has been dispensed is MDM^T02. For the purpose of this standard, the response is ACK^T02. This message may also be forwarded to the electronic repository from the message exchange. Use case 10 Dispenser cancels prescription The message type used for the dispenser to notify the message exchange that medication has been dispensed is MDM^T02. For the purpose of this standard, the response is ACK^T02. This message may also be forwarded to the electronic repository from the message exchange. 120

121 6 General implementation comments 6.1 XML schema General Practice Messaging Standard Version 3.0 The GPMS is based on the Health Level Seven (HL7) v2.4 messaging standard with XML encoding. Schema includes reference to the segments schema which includes reference to the fields schema which includes reference to the datatypes schema. For more information on this standard and HL7 v2.4 XML schema please see CE datatype usage The CE data type consists of six components and is used to transmit coded information. The components of the data type include: identifier text name of coding system alternative identifier alternative text name of alternative coding system. The identifier component contains a sequence of characters (the code) that uniquely identifies the item being referenced by the text component. The name of coding system component will serve to identify the coding scheme being used in the identifier component. The combination of the identifier and name of coding system components will be a unique code for a data item. HL7 permits local codes to be carried in the first three components. The three alternative components are defined analogously to the above for an alternate or local coding system. If the alternate text component is absent, and the alternate identifier is present, the alternate text will be taken to be the same as the text component. If the alternate coding system component is absent, it will be taken to mean the locally-defined system. 121

122 6.3 PID.32 element This field contains a coded value used to communicate information regarding the reliability of patient/person identifying data transmitted via a transaction. Values could indicate that certain fields on a PID segment for a given patient/person are known to be false (e.g., use of default or system-generated values for date of birth or person name). Please refer to table Identity reliability code for permitted values. If default values are supplied in the PID segment it is required that these values are identified through usage of the PID.32 field. 6.4 LOINC Codes LOINC stands for Logical Observation Identifier Names and Codes. The LOINC database provides a set of universal names and ID codes for identifying laboratory and clinical test results. The purpose is to facilitate the exchange and pooling of results, such as blood haemoglobin or serum potassium for clinical care, outcomes management, and research. The Regenstrief Institute maintains this database. The LOINC database (which identifies over 30,000 different lab tests and clinical observations), supporting documentation and the RELMA mapping program are all available through the Regenstrief Institute web site at or at The LOINC Codes can be used and distributed free of charge, provided existing codes are not modified. New local codes can be added, but must start with X in the number field to identify them as locally defined. The LOINC copyright notice and licence is reproduced in full in Appendix 6.0 of this document. The current version of the LOINC codes is 2.36, released 30 th June LOINC codes are being used in Ireland for referral messaging. A list of these codes is available in Appendix 5.0 of this document. 6.5 HD Datatype The HD datatype is used in fields that in earlier versions of HL7 used the IS data type. Thus, a single component HD (only the first component valued) will look like a simple IS data type for older systems expecting a single component in the place of the HD data type. If the first component for the HD data type is present, the second and third components are optional. If the third component is present, then the second must also be present (although in this case the first is optional). 122

123 The second and third components must either both be valued (both non-null), or both be not valued (both null).this means that if all three components of the HD are valued, the entity identified by the first component is the same as the entity identified by components two and three taken together. However, implementers may choose, by site agreement, to specify that if all three components of the HD are valued, the first component defines a member in the set defined by the second and third components. 123

124 7 Feedback on this document General Practice Messaging Standard Version 3.0 The Authority is fully committed to consulting on its work as widely as possible. We invite you to provide comments and feedback on this document or elements of the Standard, using the form in Appendix

125 Appendix 1 Feedback form The GPMS has been produced by the general practice messaging standards working group. We are happy to receive comments on the Standard and will endeavour to include them, where appropriate into the next revision of the Standard. Please complete the template below and sent your comment to: Standards and Technology Manager George's Court George's Lane Dublin 7. or, by to Kevin O Carroll (kocarroll@hiqa.ie) Name: Address: Organisation: Contact details: Phone: Title of Standard: General Practice Messaging Standard Version 3.0 General comments: Specific comments: No Page of issue number Suggested change/alternative text 125

126 Appendix 2 Abstract message definitions General Practice Messaging Standard Version 3.0 This section lists the abstract message definitions used as the basis for work message flows. Segment ID - The segment ID identifies each HL7 segment that may appear in the message. The segment IDs correspond to the IDs used in the standard HL7 documentation. Segment Sequence and Nesting - The allowed sequence of segments in a message instance is indicated by the sequence of segments in the message structure. Braces {..} surrounding a group of segments indicate one or more repetitions of the enclosed group may occur. Brackets [.] surrounding a group of segments indicates that the enclosed group is optional. If a group of segments is optional and may repeat it is enclosed in brackets and braces {[..]}. The column named Chapter refers to the relevant HL7 Chapter where the segment is defined. Table 28 - The ADT A01 abstract message definition. Segment ID Name Chapter MSH EVN PID [ PD1 ] [{ ROL }] [{ NK1 }] PV1 [ PV2 ] [{ ROL }] [{ DB1 }] [{ OBX }] [{ AL1 }] [{ DG1 }] [ DRG ] [{ PR1 [{ ROL }] }] [{ GT1 }] [{ IN1 [ IN2 ] [{ IN3 }] [{ ROL }] }] [ ACC ] [ UB1 ] [ UB2 ] [ PDA ] Message Header Event Type Patient Identification Additional Demographics Role Next of Kin / Associated Parties Patient Visit Patient Visit - Additional Info. Role Disability Information Observation/Result Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Insurance Insurance Additional Info. Insurance Additional Info - Cert. Role Accident Information Universal Bill Information Universal Bill 92 Information Patient Death and Autopsy

127 Table 29 - The ADT A03 abstract message definition. Segment ID Name Chapter MSH EVN PID [ PD1 ] [{ ROL }] PV1 [ PV2 ] [{ ROL }] [{ DB1 }] [{ DG1 }] [ DRG ] [{ PR1 [{ ROL }] }] [{ OBX }] [ PDA ] Message Header Event Type Patient Identification Additional Demographics Role Patient Visit Patient Visit - Additional Info. Role Disability Information Diagnosis Information Diagnosis Related Group Procedures Role Observation/Result Patient Death and Autopsy Table 30 - The ORU_R01 abstract message definition Segment ID Name Chapter MSH { [ PID [PD1] [{NK1}] [{NTE}] [ PV1 [PV2] ] ] { [ORC] OBR {[NTE]} [CTD] { [OBX] Message Header Patient Identification Additional Demographics Next of Kin/Associated Parties Notes and Comments Patient Visit Patient Visit - Additional Info Order common Observations Report ID Notes and comments Contact Data Observation/Result {[NTE]} } [{FT1}] {[CTI]} } } [DSC] Notes and comments Financial Transaction Clinical Trial Identification Continuation Pointer

128 Table 31 - The SUI abstract message definition Segment ID Name Chapter MSH SCH [ { NTE } ] [ { PID [ PD1 ] [ PV1 ] [ PV2 ] [ { OBX } ] [ { DG1 } ] } ] { RGS [ { AIS [ { NTE } ] } ] [ { AIG [ { NTE } ] } ] [ { AIL [ { NTE } ] } ] [ { AIP [ { NTE } ] } ] } Message Header Schedule Activity Information Notes and Comments Patient Identification Additional Demographics Patient Visit Patient Visit - Additional Info Observation/Result Diagnosis Resource Group Segment Appointment Information - Service Notes and Comments Appointment Information - General Resource Notes and Comments Appointment Information - Location Resource Notes and Comments Appointment Information - Personnel Resource Notes and Comments

129 Table 32 - The REF_I12 abstract message definition Segment ID Name Chapter MSH [RF1] [ AUT [CTD] ] { PRD [{CTD}] } PID [{NK1}] [{GT1}] [ { IN1 [IN2] [IN3] } ] [ACC] [{DG1}] [{DRG}] [{AL1}] [ { PR1 [ AUT [CTD] ] } ] [ { OBR [{NTE}] [ { OBX [{NTE}] } ] } ] [ PV1 [PV2] ] [ PV1 [PV2] ] [{NTE}] Message Header Referral Information Authorization Information Contact Data Provider Data Contact Data Patient Identification Next of Kin/Associated Parties Guarantor Insurance Insurance Additional Info Insurance Add l Info - Cert Accident Information Diagnosis Diagnosis Related Group Allergy Information Procedure Authorization Information Contact Data Observation Request Notes and Comments Observation/Result Notes and Comments Patient Visit Patient Visit Additional Info Patient Visit Patient Visit Additional Info Notes and Comments

130 Table 33 - The OML_O21 abstract message definition Segment ID Name Chapter MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { [ SAC [{OBX}] ] { ORC [ OBR [{ SAC [{OBX}] }] [TCD] [{NTE}] [{DG1}] [{ OBX [TCD] [{NTE}] }] [{ [PID [PD1]] [PV1 [PV2]] [{AL1}] { [ORC] OBR {[NTE]} { OBX [{NTE}] } } }] ] [{FT1}] [{CTI}] [BLG] } ] Message Header Notes and Comments (for Header) Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit- Additional Info Insurance Insurance Additional Info Insurance Add l Info - Cert. Guarantor Allergy Information Specimen Container Details Additional Specimen Characteristics Common Order Observation Request Specimen Container Details Additional Specimen Characteristics Test Code Details Notes and Comments (for Detail) Diagnosis Observation/Result Test Code Detail Notes and Comments (for Results) Patient Identification - previous result Additional Demographics - previous result Patient Visit - previous result Patient Visit Add. Info - previous result Allergy Information - previous result Common Order - previous result Order Detail - previous result Notes and Comments - previous result Observation/Result - previous result Notes and Comments - previous result Financial Transaction Clinical Trial Identification Billing Segment

131 Table 34 - The RRI_I12 abstract message definition Segment ID Name Chapter MSH [MSA] [RF1] [ AUT [CTD] ] Message Header Message Acknowledgment Referral Information Authorization Information Contact Data { PRD [{CTD}] Provider Data Contact Data } PID [ACC] [{DG1}] [{DRG}] [{AL1}] [ { PR1 [ AUT [CTD] ] } ] [ { OBR [{NTE}] [ { OBX [{NTE}] } ] } ] [ PV1 [PV2] ] [{NTE}] Patient Identification Accident Information Diagnosis Diagnosis Related Group Allergy Information Procedure Authorization Information Contact Data Observation Request Notes and Comments Observation/Result Notes and Comments Patient Visit Patient Visit Additional Info Notes and Comments

132 Table 35 - The ORL_O22 abstract message definition Segment ID Name Chapter MSH MSA [ERR] [{NTE}] [ [PID { [SAC [{OBX}] ] [{ ORC Message Header Message Acknowledgment Error Notes and Comments (for Header) Patient Identification Specimen Container Details Additional Specimen Characteristics Common Order ] ] [OBR [{SAC}] ] }] } Observation Request Specimen Container Details Table 34 - The ACK^varies^ACK General Acknowledgement ACK abstract message definition Segment ID Name Chapter MSH MSA {ERR} Message Header Message Acknowledgment Error Table 35 The MDM^T02 abstract message definition Segment ID Name Chapter MSH [{SFT}] EVN PID PV1 [{ ORC [{ TQ1 [{TQ2}] }] OBR [{ NTE }] }] TXA { OBX [{ NTE }] } Message Header Software Segment Event Type Patient Identification Patient Visit Common order segment Timing/Quantity Timing/Quantity Order Sequence Observation request segment Notes and comments about the observation (OBR) Document Notification Observation/Result (one or more required) Notes and comments about the observation (OBX)

133 Table 36 The QRY^T12 abstract message definition Segment ID Name Chapter MSH QRD [ QRF ] Message Header Query Definition Query Filter Table 37 The DOC^T12 abstract message definition Segment ID Name Chapter MSH Message Header 2 MSA Message Acknowledgement 2 [ERR] Error 2 [QAK] Query Acknowledgement 5 QRD Query Definition 2 { [EVN] Event Type 3 PID Patient Identification 3 PV1 Patient Visit 3 TXA Document Notification 9 [{OBX}] Observation 7 } [DSC] Continuation Pointer 2 133

134 Appendix 3 Reference tables General Practice Messaging Standard Version 3.0 Table 38 - HL7 User-defined Table 0001 Administrative sex Value F M O U A N S Female Male Other Unknown Ambiguous Not applicable Unspecific Table 39 - HL7 User-defined Table 0002 Marital status Value A D M S W C G P R E N I B U O T J K L Separated Divorced Married Single Widowed Common law Living together Domestic partner Registered domestic partner Legally Separated Annulled Interlocutory Unmarried Unknown Other Unreported Civil Partner Former Civil Partner Surviving Civil Partner Table 40- HL7 Table Event type Value A01 ADT/ACK - Admit/visit notification A03 ADT/ACK - Discharge/end visit I12 REF/RRI - Patient referral O21 OML - Laboratory order 022 ORL - General laboratory order response message to any OML R01 ORU/ACK - Unsolicited transmission of an observation message S12 SIU/ACK - Notification of new appointment booking S13 SIU/ACK - Notification of appointment rescheduling S14 SIU/ACK - Notification of appointment modification S15 SIU/ACK - Notification of appointment cancellation S16 SIU/ACK - Notification of appointment discontinuation S17 SIU/ACK - Notification of appointment deletion 134

135 Table 41 HL7 User-defined Table 0004 Patient class Value E I O P R B C N U G Emergency Inpatient Outpatient Preadmit Recurring patient Obstetrics Commercial Account Not Applicable Unknown General Practitioner Table 42- HL7 User-defined Table 0005 Race Value No suggested values defined Table 43 - HL7 User-defined Table 0006 Religion Value AGN ATH BAH BUD BMA BTH BTA BOT CFR CHR ABC AMT AME ANG AOG BAP CAT CRR CHS CMA COC COG COI COM COL EOT EVC EPI FWB FRQ GRE JWN LUT LMS Agnostic Atheist Baha'i Buddhist Buddhist: Mahayana Buddhist: Theravada Buddhist: Tantrayana Buddhist: Other Chinese Folk Religionist Christian Christian: American Baptist Church Christian: African Methodist Episcopal Christian: African Methodist Episcopal Zion Christian: Anglican Christian: Assembly of God Christian: Baptist Christian: Roman Catholic Christian: Christian Reformed Christian: Christian Science Christian: Christian Missionary Alliance Christian: Church of Christ Christian: Church of God Christian: Church of God in Christ Christian: Community Christian: Congregational Christian: Eastern Orthodox Christian: Evangelical Church Christian: Episcopalian Christian: Free Will Baptist Christian: Friends Christian: Greek Orthodox Christian: Jehovah's Witness Christian: Lutheran Christian: Lutheran Missouri Synod 135

136 Value MEN MET MOM NAZ ORT COT PRC PEN COP PRE PRO QUA REC REO SAA SEV SOU UCC UMD UNI UNU WES WMC CNF ERL HIN HVA HSH HOT JAI JEW JCO JOR JOT JRC JRF JRN MOS MSU MSH MOT NAM NRL NOE OTH SHN SIK SPI VAR Christian: Mennonite Christian: Methodist Christian: Latter-day Saints Christian: Church of the Nazarene Christian: Orthodox Christian: Other Christian: Other Protestant Christian: Pentecostal Christian: Other Pentecostal Christian: Presbyterian Christian: Protestant Christian: Friends Christian: Reformed Church Christian: Reorganized Church of Jesus Christ-LDS Christian: Salvation Army Christian: Seventh Day Adventist Christian: Southern Baptist Christian: United Church of Christ Christian: United Methodist Christian: Unitarian Christian: Unitarian Universalist Christian: Wesleyan Christian: Wesleyan Methodist Confucian Ethnic Religionist Hindu Hindu: Vaishnavites Hindu: Shaivites Hindu: Other Jain Jewish Jewish: Conservative Jewish: Orthodox Jewish: Other Jewish: Reconstructionist Jewish: Reform Jewish: Renewal Muslim Muslim: Sunni Muslim: Shiite Muslim: Other Native American New Religionist Nonreligious Other Shintoist Sikh Spiritist Unknown 136

137 Table 44 - HL7 User-defined Table 0007 Admission type Value A E L R N U C Accident Emergency Labor and Delivery Routine Newborn (Birth in healthcare facility) Urgent Elective General Practice Messaging Standard Version 3.0 Table 45 - HL7 Table Acknowledgment code Value AA Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error AR Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject CA Enhanced mode: Accept acknowledgment: Commit Accept CE Enhanced mode: Accept acknowledgment: Commit Error CR Enhanced mode: Accept acknowledgment: Commit Reject Table 46 - HL7 User-defined Table 0009 Ambulatory status Value A0 No functional limitations A1 Ambulates with assistive device A2 Wheelchair/stretcher bound A3 Comatose; non-responsive A4 Disoriented A5 Vision impaired A6 Hearing impaired A7 Speech impaired A8 Non-English speaking A9 Functional level unknown B1 Oxygen therapy B2 Special equipment (tubes, IVs, catheters) B3 Amputee B4 Mastectomy B5 Paraplegic B6 Pregnant B7 Not Pregnant B8 Pregnancy Unknown Table 47 - HL7 User-defined Table 0010 Physician ID Value No suggested values defined 137

138 Table 48 - HL7 User-defined Table 0023 Admit source Value 1 Physician referral 2 Clinic referral 3 HMO referral 4 Transfer from a hospital 5 Transfer from a skilled nursing facility 6 Transfer from another healthcare facility 7 Emergency room 8 Court/law enforcement 9 Information not available Table 49 HL7 User-defined Table Diagnosis code Value No suggested values defined Table 50 - HL7 User-defined Table 0052 Diagnosis type Value A W F Admitting Working Final Table 51 - HL7 User-defined Table Diagnosis coding method Value No suggested values defined Table 52 - HL7 User-defined Table 0064 Financial class Value 01 Medical Card 02 Public Patient 03 Semi Private Patient 04 Private Patient Table 53 - HL7 Table 0065 Specimen action code Value A G L O P R S Add ordered tests to the existing specimen Generated order; reflex order Lab to obtain specimen from patient Specimen obtained by service other than Lab Pending specimen; Order sent prior to delivery Revised order Schedule the tests specified below Table 54 - HL7 Table 0070 Specimen source code Value ABS Abscess 138

139 Value AMN ASP BPH BIFL BLDA BBL BLDC BPU BLDV BON BRTH BRO BRN CALC CDM CNL CTP CSF CVM CVX COL CBLD CNJT CUR CYST DIAF DOSE DRN DUFL EAR EARW ELT ENDC ENDM EOS RBC EYE EXHLD FIB FLT FIST FLU GAS GAST GEN GENC GENL GENV HAR IHG IT ISLT LAM WBC LN LNA Amniotic fluid Aspirate Basophils Bile fluid Blood arterial Blood bag Blood capillary Blood product unit Blood venous Bone Breath (use EXHLD) Bronchial Burn Calculus (=Stone) Cardiac muscle Cannula Catheter tip Cerebral spinal fluid Cervical mucus Cervix Colostrum Cord blood Conjunctiva Curettage Cyst Dialysis fluid Dose med or substance Drain Duodenal fluid Ear Ear wax (cerumen) Electrode Endocardium Endometrium Eosinophils Erythrocytes Eye Exhaled gas (=breath) Fibroblasts Filter Fistula Body fluid, unsp Gas Gastric fluid/contents Genital Genital cervix Genital lochia Genital vaginal Hair Inhaled Gas Intubation tube Isolate Lamella Leukocytes Line Line arterial 139

140 Value LNV LIQ LYM MAC MAR MEC MBLD MLK MILK NAIL NOS ORH PAFL PAT PRT PLC PLAS PLB PLR PMN PPP PRP PUS RT SAL SEM SER SKN SKM SPRM SPT SPTC SPTT STON STL SWT SNV TEAR THRT THRB TISS TISG TLGI TLNG TISPL TSMI TISU TUB ULC UMB UMED URTH UR URC URT URNS Line venous Liquid NOS Lymphocytes Macrophages Marrow Meconium Menstrual blood Milk Breast milk Nail Nose (nasal passage) Other Pancreatic fluid Patient Peritoneal fluid /ascites Placenta Plasma Plasma bag Pleural fluid (thoracentesis fld) Polymorphonuclear neutrophils Platelet poor plasma Platelet rich plasma Pus Route of medicine Saliva Seminal fluid Serum Skin Skeletal muscle Spermatozoa Sputum Sputum - coughed Sputum - tracheal aspirate Stone (use CALC) Stool = Fecal Sweat Synovial fluid (Joint fluid) Tears Throat Thrombocyte (platelet) Tissue Tissue gall bladder Tissue large intestine Tissue lung Tissue placenta Tissue small intestine Tissue ulcer Tube NOS Ulcer Umbilical blood Unknown medicine Urethra Urine Urine clean catch Urine catheter Urine sediment 140

141 Value USUB VOM BLD BDY WAT WICK WND WNDA WNDE WNDD XXX B BX E ED GC GS HP NF NT RS STORE UFB VAULT Unknown substance Vomitus Whole blood Whole body Water Wick Wound Wound abscess Wound exudate Wound drainage To be specified in another part of the message Blood Biopsy Effusion EDTA Guthrie Card Gallstones Heparinised Plasma Sodium Flouride No type Renal Stones STORE Urine Faeces EDTA VAULT 141

142 Table 55 - HL7 Table 0074 Diagnostic service section ID Message AU BG BLB CUS CTH CT CH CP EC EN HM ICU IMM LAB MB MCB MYC NMS NMR NRS OUS OT OTH OSL PHR PT PHY PF RAD RX RUS RC RT SR SP TX VUS VR XRC HIS CAR BS ML Audiology Blood Gases Blood Bank Cardiac Ultrasound Cardiac Catheterization CAT Scan Chemistry Cytopathology Electrocardiac (e.g., EKG, EEC, Holter) Electroneuro (EEG, EMG,EP,PSG) Hematology Bedside ICU Monitoring Immunology Laboratory Microbiology Mycobacteriology Mycology Nuclear Medicine Scan Nuclear Magnetic Resonance Nursing Service Measures OB Ultrasound Occupational Therapy Other Outside Lab Pharmacy Physical Therapy Physician (Hx. Dx, admission note, etc.) Pulmonary Function Radiology Radiograph Radiology Ultrasound Respiratory Care (therapy) Radiation Therapy Serology Surgical Pathology Toxicology Vascular Ultrasound Virology Cineradiograph Histopathology Cardiology Blood Sciences Molecular Testing 142

143 Table 56 - HL7 Table 0076 Message Type Message Chapter ACK General acknowledgment message 2 ADT ADT message 3 OML Laboratory order message 4 ORL Laboratory acknowledgment message (unsolicited) 7 ORU Unsolicited transmission of an observation message 7 REF Patient referral 11 RRD Pharmacy/treatment dispense acknowledgment message 4 RRE Pharmacy/treatment encoded order acknowledgment 4 message RRG Pharmacy/treatment give acknowledgment message 4 RRI Return referral information 11 SIU Schedule information unsolicited 10 Table 57 - HL7 User-defined Table Abnormal flags Message L Below low normal H Above high normal LL Below lower panic limits HH Above upper panic limits < Below absolute low-off instrument scale > Above absolute high-off instrument scale N Normal (applies to non-numeric results) A Abnormal (applies to non-numeric results) AA Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units) null No range defined, or normal ranges don't apply U Significant change up D Significant change down B Better--use when direction not relevant W Worse--use when direction not relevant S Susceptible. Indicates for microbiology susceptibilities only. R Resistant. Indicates for microbiology susceptibilities only. I Intermediate. Indicates for microbiology susceptibilities only. MS Moderately susceptible. Indicates for microbiology susceptibilities only. VS Very susceptible. Indicates for microbiology susceptibilities only. Table 58 - HL7 Table 0085 Observation results status codes interpretation Value C D F I N O P R S X U Record coming over is a correction and thus replaces a final result Deletes the OBX record Final results; Can only be changed with a corrected result. Specimen in lab; results pending Not asked; used to affirmatively document that the observation identified in the OBX was not sought when the universal service ID in OBR-4 implies that it would be sought. Order detail description only (no result) Preliminary results Results entered -- not verified Partial results Results cannot be obtained for this observation Results status change to final without retransmitting results already sent as preliminary. E.g., radiology changes status from preliminary to final 143

144 Value W Post original as wrong, e.g., transmitted for wrong patient Table 59 - HL7 Table 0102 Delayed acknowledgment type Value D F Message received, stored for later processing Acknowledgment after processing Table 60 - HL7 Table 0103 Processing ID Value D P T Debugging Production Training Table 61 - HL7 Table 0104 HL7 version identifier Value Date 2.0 Release 2.0 September D Demo 2.0 October Release 2. 1 March Release 2.2 December Release 2.3 March Release May Release 2.4 November 2000 Table 62 - HL7 Table 0105 Source of comment Value L P O Ancillary (filler) department is source of comment Orderer (placer) is source of comment Other system is source of comment Table 63 - HL7 User-defined Table 0112 Discharge disposition Value 01 Discharged to home or self care (routine discharge) 02 Discharged/transferred to another short term general hospital for inpatient care 03 Discharged/transferred to skilled nursing facility (SNF) 04 Discharged/transferred to an intermediate care facility (ICF) 05 Discharged/transferred to another type of institution for inpatient care or referred for outpatient services to another institution 06 Discharged/transferred to home under care of organised home health service organisation 07 Left against medical advice or discontinued care 08 Discharged/transferred to home under care of Home IV provider 09 Admitted as an inpatient to this hospital Discharge to be defined at state level, if necessary 20 Expired (i.e. dead) Expired to be defined at state level, if necessary 30 Still patient or expected to return for outpatient services (i.e. still a patient) Still patient to be defined at state level, if necessary (i.e. still a patient) 40 Expired (i.e. died) at home 144

145 Value 41 Expired (i.e. died) in a medical facility; e.g., hospital, SNF, ICF, or free standing hospice 42 Expired (i.e. died) - place unknown Table 64 - HL7 User-defined Table 0113 Discharged to location Value No suggested values defined Table 65 - HL7 Table 0123 Result status Value O I S A P C R F X Y Z Table 66 - HL7 Table 0125 Value type Value AD CE CF CK CN CP CX DT ED FT MO NM PN RP SN ST TM TN TS TX XAD XCN XON XPN XTN Order received; specimen not yet received No results available; specimen received, procedure incomplete No results available; procedure scheduled, but not done Some, but not all, results available Preliminary: A verified early result is available, final results not yet obtained Correction to results Results stored; not yet verified Final results; results stored and verified. Can only be changed with a corrected result. No results available; Order canceled. No order on record for this test. (Used only on queries) No record of this patient. (Used only on queries) Address Coded Entry Coded Element With Formatted Values Composite ID With Check Digit Composite ID And Name Composite Price Extended Composite ID With Check Digit Date Encapsulated Data Formatted Text (Display) Money Numeric Person Name Reference Pointer Structured Numeric String Data Time Telephone Number Time Stamp (Date & Time) Text Data (Display) Extended Address Extended Composite Name And Number For Persons Extended Composite Name And Number For Organisations Extended Person Name Extended Telecommunications Number 145

146 Table 67- HL7 Table 0127 Allergen type code Value DA FA MA MC EA AA PA LA Drug allergy Food allergy Miscellaneous allergy Miscellaneous contraindication Environmental Allergy Animal Allergy Plant Allergy Pollen Allergy Table 68 - HL7 Table 0128 Allergen severity code Value SV MO MI U Severe Moderate Mild Unknown Table 69 - HL7 Table 0136 Yes/no indicator Value Y N Yes No Table 70 - HL7 Table 0155 Acknowledgement type Value AL NE ER SU Always Never Error/reject conditions only Successful completion only Table 71 - HL7 Table 0161 Acknowledgement type Value N G T Substitutions are NOT authorized. (This is the default - null.) Allow generic substitutions. Allow therapeutic substitutions Table 72 - HL7 Table 0161 Route of Administration Value AP B DT EP ET GTT GU IMR IA IB Apply Externally Buccal Dental Epidural Endotrachial Tube* Gastrostomy Tube GU Irrigant Immerse (Soak) Body Part Intra-arterial Intrabursal 146

147 IC Intracardiac ICV Intracervical (uterus) ID Intradermal IH Inhalation IHA Intrahepatic Artery IM Intramuscular IN Intranasal IO Intraocular IP Intraperitoneal IS Intrasynovial IT Intrathecal IU Intrauterine IV Intravenous MTH Mouth/Throat MM Mucous Membrane NS Nasal NG Nasogastric NP Nasal Prongs* NT Nasotrachial Tube OP Ophthalmic OT Otic OTH Other/Miscellaneous PF Perfusion PO Oral PR Rectal RM Rebreather Mask* SD Soaked Dressing SC Subcutaneous SL Sublingual TP Topical TRA Tracheostomy* TD Transdermal TL Translingual UR Urethral VG Vaginal VM Ventimask WND Wound Table 73 - HL7 User-defined Table 0163 Administration site Value BE Bilateral Ears OU Bilateral Eyes BN Bilateral Nares BU Buttock CT Chest Tube LA Left Arm LAC Left Anterior Chest LACF Left Antecubital Fossa LD Left Deltoid LE Left Ear LEJ Left External Jugular OS Left Eye LF Left Foot LG Left Gluteus Medius LH Left Hand LIJ Left Internal Jugular 147

148 Value LLAQ Left Lower Abd Quadrant LLFA Left Lower Forearm LMFA Left Mid Forearm LN Left Naris LPC Left Posterior Chest LSC Left Subclavian LT Left Thigh LUA Left Upper Arm LUAQ Left Upper Abd Quadrant LUFA Left Upper Forearm LVG Left Ventragluteal LVL Left Vastus Lateralis NB Nebulized PA Perianal PERIN Perineal RA Right Arm RAC Right Anterior Chest RACF Right Antecubital Fossa RD Right Deltoid RE Right Ear REJ Right External Jugular OD Right Eye RF Right Foot RG Right Gluteus Medius RH Right Hand RIJ Right Internal Jugular RLAQ Rt Lower Abd Quadrant RLFA Right Lower Forearm RMFA Right Mid Forearm RN Right Naris RPC Right Posterior Chest RSC Right Subclavian RT Right Thigh RUA Right Upper Arm RUAQ Right Upper Abd Quadrant RUFA Right Upper Forearm RVL Right Vastus Lateralis RVG Right Ventragluteal Table 74 - HL7 User-defined Table 0164 Administration device Value AP Applicator BT Buretrol HL Heparin Lock IPPB IPPB IVP IV Pump IVS IV Soluset MI Metered Inhaler NEB Nebulizer PCA PCA Pump 148

149 Table 75 - HL7 User-defined Table 0165 administration method Value CH DI DU IF IS IR IVPB IVP NB PT PF SH SO WA WI Chew Dissolve Dust Infiltrate Insert Irrigate IV Piggyback IV Push Nebulized Pain Perfuse Shampoo Soak Wash Wipe Table 76 - HL7 User-defined Table 0166 RX component type Value B A Base Additive Table 77 - HL7 User-defined Table 0167 Substitution status Value N No substitute was dispensed. This is equivalent to the default (null) value. G A generic substitution was dispensed. T A therapeutic substitution was dispensed. 0 No product selection indicated 1 Substitution not allowed by prescriber 2 Substitution allowed - patient requested product dispensed 3 Substitution allowed - pharmacist selected product dispensed 4 Substitution allowed - generic drug not in stock 5 Substitution allowed - brand drug dispensed as a generic 7 Substitution not allowed - brand drug mandated by law 8 Substitution allowed - generic drug not available in marketplace Table 78 - HL7 User-defined Table 0171 Citizenship Value No suggested values defined Table 79 - HL7 User-defined Table 0172 Veterans military status Value No suggested values defined Table 80 - HL7 User-defined Table 0189 Ethnic group Value No suggested values defined 149

150 Table 81 - HL7 Table 0200 Name type Value A B C D I L M N P R S T U Alias Name Name at Birth Adopted Name Display Name Licensing Name Legal Name Maiden Name Nickname /"Call me" Name/Street Name Name of Partner/Spouse (retained for backward compatibility only) Registered Name (animals only) Coded Pseudo-Name to ensure anonymity Indigenous/Tribal/Community Name Unspecified Table 82 - HL7 Table Telecommunication use code Value PRN ORN WPN VHN ASN EMR NET BPN Primary Residence Number Other Residence Number Work Number Vacation Home Number Answering Service Number Emergency Number Network ( ) Address Beeper Number Table 83 - HL7 Table Telecommunication equipment type Value PH Telephone FX Fax MD Modem CP Cellular Phone BP Beeper Internet Internet Address: Use Only If Telecommunication Use Code Is NET X.400 X.400 address: Use Only If Telecommunication Use Code Is NET 150

151 Table 84 - HL7 User-defined Table 0203 Identifier type Value General Practice Messaging Standard Version 3.0 GMS GPN MRN PPSN CCEI VHI BUPA RAD LAB OTH UNK COOP RIS CN PASPID HLID NCIN CSP ID General Medical Services Number GP Electronic Patient Record Number Medical Record Number Personal Social Services Number Central Client Eligibility Index Voluntary Health Insurance Number BUPA Number Radiology Chart Number Laboratory Number Other Unknown Out of Hours Number Radiology Information System Chart Number Patient Admin System Patient ID No Healthlink ID National Client Index Number Cervical Check patient id Table 85 - HL7 Table 0206 Segment action code Value A D U Add/Insert Delete Update Table 86 - HL7 Table 0207 Processing mode Value A R I T Not present Archive Restore from archive Initial load Current processing, transmitted at intervals (scheduled or on demand) Not present (the default, meaning current processing) Table 87 - HL7 Table 0227 Substance manufacturer name Value AB AD ALP AR AVI BA BAY BP BPC CEN CHI CON EVN GRE Abbott Laboratories (includes Ross Products Division) Adams Laboratories Alpha Therapeutic Corporation Armour [Inactive use CEN] Aviron Baxter Healthcare Corporation Bayer Corporation(includes Miles, Inc. and Cutter Laboratories) Berna Products [Inactive use BPC] Berna Products Corporation (includes Swiss Serum and Vaccine Institute Berne) Centeon L.L.C. (includes Armour Pharmaceutical Company) Chiron Corporation Connaught [Inactive use PMC] Evans Medical Limited (an affiliate of Medeva Pharmaceuticals, Inc.) Greer Laboratories, Inc. 151

152 Value IAG IM IUS JPN KGC LED MA MED MIL MIP MSD NAB NYB NAV NOV OTC ORT PD PMC PRX SCL SI SKB USA WA WAL OTH UNK Immuno International AG Merieux [Inactive use PMC] Immuno-U.S., Inc. The Research Foundation for Microbial Diseases of Osaka University (BIKEN) Korea Green Cross Corporation Lederle [Inactive use WAL] Massachusetts Public Health Biologic Laboratories MedImmune, Inc. Miles [Inactive use BAY] Bioport Corporation (formerly Michigan Biologic Products Institute) Merck & Co., Inc. NABI (formerly North American Biologicals, Inc.) New York Blood Center North American Vaccine, Inc. Novartis Pharmaceutical Corporation (includes Ciba-Geigy Limited and Sandoz Limited) Organon Teknika Corporation Ortho Diagnostic Systems, Inc. Parkedale Pharmaceuticals (formerly Parke-Davis) Aventis Pasteur Inc. (formerly Pasteur Merieux Connaught; includes Connaught Laboratories and Pasteur Merieux) Praxis Biologics [Inactive use WAL] Sclavo, Inc. Swiss Serum and Vaccine Inst. [Inactive use BPC] SmithKline Beecham United States Army Medical Research and Materiel Command Wyeth-Ayerst [Inactive use WAL] Wyeth-Ayerst (includes Wyeth-Lederle Vaccines and Pediatrics, Wyeth Laboratories, Lederle Laboratories, and Praxis Biologics) Other manufacturer Unknown manufacturer 152

153 Table 88- HL7 User-defined Table 0278 Filler status codes Value General Practice Messaging Standard Version 3.0 Pending Waitlist Booked Started Complete Cancelled Dc Deleted Blocked Overbook Appointment has not yet been confirmed Appointment has been placed on a waiting list for a particular slot, or set of slots The indicated appointment is booked The indicated appointment has begun and is currently in progress The indicated appointment has completed normally (was not discontinued, canceled, or deleted) The indicated appointment was stopped from occurring (canceled prior to starting) The indicated appointment was discontinued (DC ed while in progress, discontinued parent appointment, or discontinued child appointment) The indicated appointment was deleted from the filler application The indicated time slot(s) is(are) blocked The appointment has been confirmed; however it is confirmed in an overbooked state Table 89 - HL7 User-defined Table 0280 Referral priority Value S STAT/ With Highest Priority A ASAP/ As soon as possible (after S) U Urgent E Early R Routine Table 90 - HL7 User-defined Table 0281 Referral type Value Lab Rad Med Skn Psy Hom Prostate Breast Lung Gastrointestinal Neurology Chest MRI General Laboratory Radiology Medical Skilled Nursing Psychiatric Home Care Prostate Breast Lung Gastrointestinal Neurology Chest MRI General Table 91 - HL7 User-defined Table 0282 Referral disposition Value WR RP AM SO Send Written Report Return Patient After Evaluation Assume Management Second Opinion 153

154 Table 92 - HL7 User-defined Table 0283 Referral status Value General Practice Messaging Standard Version 3.0 A P R E Accepted Pending Rejected Expired Table 93 - HL7 User-defined Table 0284 Referral category Value I O A E Inpatient Outpatient Ambulatory Emergency Table 94 - HL7 User-defined table 0286 Provider role Value RP PP CP RT Referring Provider Primary Care Provider Consulting Provider Referred to Provider Table 95- HL7 User-defined Table 0289 County code Value No values Defined Table 96 - HL7 User-defined Table 0292 County code Value No values Defined Table 97 - HL7 User-defined Table 0296 Primary language Value No suggested values defined 154

155 Table 98 HL7 User-defined Table Universal ID type Value General Practice Messaging Standard Version 3.0 DNS GUID HCD HL7 ISO L,M,N Random UUID x400 x500 DOH MCN.HLPracticeID An Internet dotted name. Either in ASCII or as integers Same as UUID. The CEN Healthcare Coding Scheme Designator. (Identifiers used in DICOM follow this assignment scheme.) Reserved for future HL7 registration schemes An International Standards Organization Object Identifier These are reserved for locally defined coding schemes Usually a base64 encoded string of random bits.the uniqueness depends on the length of the bits. Mail systems often generate ASCII string "unique names," from a combination of random bits and system names. Obviously, such identifiers will not be constrained to the base64 character set. Usually a base64 encoded string of random bits. The uniqueness depends on the length of the bits. Mail systems often generate ASCII string "unique names," from a combination of random bits Department of Health This code uses Ireland s national Medical Council Number concatenated using a. to the Healthlink Practice ID code to identify a GP at a practice. Table 99 HL7 User-defined Table Point of care Value MED SUR PSY MAT PAE EME OTH Medical Surgical Psychiatric Maternity Paediatric Emergency Other Table HL7 User-defined Table 0321 Dispense method Value TR UD F AD Traditional Unit Dose Floor Stock Automatic Dispensing Table HL7 User-defined Table 0326 Visitor indicator Value A V Account level (default) Visit level Table HL7 User-defined Table 0336 Referral reason Value S P O W Second Opinion Patient Preference Provider Ordered Work Load 155

156 Table HL7 Table Message error condition codes Error Condition Code Error Condition Text /Comment General Practice Messaging Standard Version 3.0 Success 0 Message accepted Success. Optional, as the AA conveys success. Used for systems that must always return a status code. Errors 100 Segment sequence error The message segments were not in the proper order, or required segments are missing. 101 Required field missing A required field is missing from a segment 102 Data type error The field contained data of the wrong data type, e.g. an NM field contained "FOO". 103 Table value not found A field of data type ID or IS was compared against the corresponding table, and no match was found. Rejection 200 Unsupported message The Message Type is not supported. type 201 Unsupported event The Event Code is not supported. code 202 Unsupported The Processing ID is not supported. processing id 203 Unsupported version id The Version ID is not supported. 204 Unknown key identifier The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a nonexistent patient. 205 Duplicate key identifier The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.). 206 Application record locked The transaction could not be performed at the application storage level, e.g. database locked. 207 Application internal error Table HL7 User-defined Table Degree Value No values Defined Table 105- HL7 User-defined Table 0361 Sending application Value TOREX.HEALTHLINK.12 PAS.HEALTHLINK.12 IPMISOFT.HEALTHLINK.12 TOREX.HEALTHLINK.10 WOODARD.HEALTHLINK.10 APEX.HEALTHLINK.10 MCKESSAN.HEALTHLINK.10 TELEPATH.HEALTHLINK.10 TOREX.HEALTHLINK.9 PAS.HEALTHLINK.9 TOREX.HEALTHLINK.8 A catchall for internal errors not explicitly covered by other codes. Torex, Healthlink Bridge Middleware, Discharge Notification Message Patient Administration System, Healthlink Bridge Middleware, Discharge Notification Message ipmisoft, Healthlink Bridge Middleware, Discharge Notification Message Torex, Healthlink Bridge Middleware, Message ID Lab Result Woodard, Healthlink Bridge Middleware, Message ID Lab Result Apex, Healthlink Bridge Middleware, Message ID Lab Result McKessan, Healthlink Bridge Middleware, Message ID Lab Result Telepath, Healthlink Bridge Middleware, Message ID Lab Result Message Torex, Healthlink Bridge, Healthlink Bridge Middleware, Waiting List Message Patient Administration System, Healthlink Bridge, Healthlink Bridge Middleware, Waiting List Message Torex, Healthlink Bridge, Healthlink Bridge Middleware, OPD Appointment Message 156

157 Value PAS.HEALTHLINK.8 IPMISOFT.HEALTHLINK.8 IMS.HEALTHLINK.7 KEOGHRIS.HEALTHLINK.7 MCKESSAN.HEALTHLINK.7 PAS.HEALTHLINK.7 IPMISOFT.HEALTHLINK.7 TOREX.HEALTHLINK.6 PAS.HEALTHLINK.6 IPMISOFT.HEALTHLINK.6 TOREX.HEALTHLINK.5 PAS.HEALTHLINK.5 AE.HEALTHLINK.4 TOREX.HEALTHLINK.4 IMS.HEALTHLINK.4 HLONLINE.HEALTHLINK.1 HLONLINE.HEALTHLINK.14 HLONLINE.HEALTHLINK.15 TOREX.HEALTHLINK.11 IPMISOFT.HEALTHLINK.17 SUNQUEST WINPATH HL7 KEOGHRIS ADASTRA ilab.ice APEX.ICE TOREXRIS ADASTRA2 HEALTHONE HELIXPM SOCRATES COMPLETEGP MEDICOM GPMAC AGFA DMF_OPENLIS DWISI HIPEHOS ILAB IPM IWM MAXIMS-RIS MILLENIUM NETACQUIRE TEAMS Patient Administration System, Healthlink Bridge Middleware, OPD Appointment Message ipmisoft, Healthlink Bridge Middleware, OPD Appointment Message IMS, Healthlink Bridge Middleware, Radiology Message Keogh Radiology System, Healthlink Bridge Middleware, Radiology Message KcKessan Radiology System, Healthlink Bridge Middleware, Radiology Message Patient Administration System, Healthlink Bridge Middleware, Radiology Message ipmisoft, Healthlink Bridge Middleware, Radiology Message Torex, Healthlink Bridge Middleware, Death Notification Message Patient Administration System, Healthlink Bridge Middleware, Death Notification Message ipmisoft, Healthlink Bridge Middleware, Death Notification Message Torex, Healthlink Bridge Middleware, Discharge Summary Message Torex, Healthlink Bridge Middleware, Discharge Summary Message A&E Information System, Healthlink Bridge Middleware, A&E Notification Message Torex, Healthlink Bridge Middleware, A&E Notification Message IMS A&E System, Healthlink Bridge Middleware, A&E Notification Message Healthlink Online, Healthlink Bridge Middleware, Lab Order Message Healthlink Online, Healthlink Bridge Middleware, Neurology Referral Message Healthlink Online, Healthlink Bridge Middleware, Neurology Response Message Torex, Healthlink Bridge, Healthlink Bridge Middleware, Laboratory Order NACK ipmisoft, Healthlink Bridge Middleware, Cardiology Message HSE NW Laboratory Information System HSE NE Laboratory Information System HSE NE Radiology Information System HSE NE Out of Hours Co-operative HSE SE Laboratory Information System with Anglia ICE Middleware HSE S Laboratory Information System with Anglia ICE Middleware St James s Hospital Radiology Information System HSE SE Out of Hours Co-operative, CareDoc Message Generated by HealthOne Practice Management System Message Generated by Helix Practice Manager Practice Management System Message Generated by Socrates Practice Manager Practice Management System Message Generated by CompleteGP Practice Management System Message Generated by Medicom Practice Management System Message Generated by GPMAC Practice Management System Message Generated by AGFA Message Generated by DMF_OPENLIS Message Generated by DWISI Message Generated by HIPEHOS Message Generated by ILAB Message Generated by IPM Message Generated by IWM Message Generated by MAXIMS-RIS Message Generated by MILLENIUM Message Generated by NETACOUIRE Message Generated by TEAMS 157

158 Value TOREXPAS DMF_EDS GE MLP-Appollo Message Generated by TOREXPAS Message Generated by DMF EDS Message generated by Euromedics radiology Message Generated by MLP-Appollo Table106 - HL7 User-defined Table 0362 Sending facility Value 0002 Caredoc 0003 Shannon Doc 0100 St. Mary s Hospital, Phoenix Park 0101 St. Colmcille's Hospital, Loughlinstown 0102 Naas General Hospital 0106 Cherry Orchard Hospital, Ballyfermot 0108 Connolly Hospital Blanchardstown 0201 Midland Regional Hospital, Portlaoise 0202 Midland Regional Hospital, Mullingar 0203 Midland Regional Hospital,Tullamore 0300 Midwestern Regional Hospital, Dooradoyle 0301 Midwestern Regional Maternity Hospital Limerick 0302 Midwestern Regional Orthopaedic Hospital, Croom 0304 Midwestern Regional Hospital, Nenagh 0305 Midwestern Regional Hospital, Ennis 0400 Louth County Hospital, Dundalk 0402 Cavan General Hospital 0403 Our Lady s Hospital, Navan 0404 Monaghan General Hospital 0500 Letterkenny General Hospital 0501 Sligo General Hospital 0502 Our Lady s Hospital, Manorhamilton 0600 Waterford Regional Hospital (Ardkeen) 0601 St. Luke s General Hospital, Kilkenny 0602 Lourdes Orthopaedic Hospital, Kilcreene 0605 Wexford General Hospital 0607 South Tipperary General Hospital, Clonmel 0608 Our Lady s Hospital, Cashel 0701 St. Mary s Orthopaedic Hospital, Gurranabraher 0703 Mallow General Hospital 0704 Bantry General Hospital 0705 St. Finbarr s Hospital, Cork 0724 Cork University Hospital 0726 Kerry General Hospital 0800 University College Hospital Galway (UCHG) 0801 Merlin Park University Hospital, Galway 0802 Mayo General Hospital 0803 Roscommon County Hospital 0805 Ballina District Hospital 0901 Adelaide Hospital, Dublin 0903 Meath Hospital, Dublin 0904 St. James's Hospital, Dublin 0908 Mater Misericordiae University Hospital, Dublin 0910 St. Vincent s University Hospital, Elm park 0912 St. Michael s Hospital, Dun Laoghaire 158

159 Value 0913 Mercy University Hospital, Cork 0915 South Infirmary/Victoria, Cork 0918 St. John s Hospital, Limerick 0919 Portiuncula Hospital, Ballinasloe 0922 Our Lady of Lourdes Hospital, Drogheda 0923 Beaumont Hospital, Dublin 0925 Peamount Hospital, Newcastle 0930 Coombe Women and Infants University Hospital, Dublin 0931 National Maternity Hospital, Holles St, Dublin 0932 Rotunda Hospital, Dublin 0934 Waterford Maternity Hospital 0940 The Children s University Hospital, Temple St, Dublin 0941 Our Lady s Children s Hospital, Crumlin 0943 National Children s Hospital, Harcourt St 0945 St. Anne s Hospital, Dublin 0946 Hume St. Hospital, Dublin 0947 St. Luke s Hospital, Rathgar 0950 Royal Victoria Eye & Ear Hospital, Dublin 0954 Incorporated Orthopaedic Hospital, Clontarf 0955 National Orthopaedic Hospital, Cappagh 0956 St. Mary s Auxiliary Hospital, Baldoyle 0960 National Rehabilitation Hospital, (NHR), Dun Laoghaire 0978 Our Lady s Hospice, Harold s Cross, Dublin 1225 St. Joseph's Unit, Harold s Cross 1270 Adelaide, Meath Incorporating National Children s Hospital (AMNCH), Tallaght 1762 St. Joseph s Hospital, Raheny * Please note that some hospitals listed above now closed/no longer acute hospitals but are included on this list to enable historical data analysis. Table HL7 User-defined Table Assigning Authority Value 0002 Caredoc 0003 Shannon Doc 0100 St. Mary s Hospital, Phoenix Park 0101 St. Colmcille's Hospital, Loughlinstown 0102 Naas General Hospital 0106 Cherry Orchard Hospital, Ballyfermot 0108 Connolly Hospital Blanchardstown 0201 Midland Regional Hospital, Portlaoise 0202 Midland Regional Hospital, Mullingar 0203 Midland Regional Hospital,Tullamore 0300 Midwestern Regional Hospital, Dooradoyle 0301 Midwestern Regional Maternity Hospital Limerick 0302 Midwestern Regional Orthopaedic Hospital, Croom 0304 Midwestern Regional Hospital, Nenagh 0305 Midwestern Regional Hospital, Ennis 0400 Louth County Hospital, Dundalk 0402 Cavan General Hospital 0403 Our Lady s Hospital, Navan 0404 Monaghan General Hospital 0500 Letterkenny General Hospital 159

160 Value 0501 Sligo General Hospital 0502 Our Lady s Hospital, Manorhamilton 0600 Waterford Regional Hospital (Ardkeen) 0601 St. Luke s General Hospital, Kilkenny 0602 Lourdes Orthopaedic Hospital, Kilcreene 0605 Wexford General Hospital 0607 South Tipperary General Hospital, Clonmel 0608 Our Lady s Hospital, Cashel 0701 St. Mary s Orthopaedic Hospital, Gurranabraher 0703 Mallow General Hospital 0704 Bantry General Hospital 0705 St. Finbarr s Hospital, Cork 0724 Cork University Hospital 0726 Kerry General Hospital 0800 University College Hospital Galway (UCHG) 0801 Merlin Park University Hospital, Galway 0802 Mayo General Hospital 0803 Roscommon County Hospital 0805 Ballina District Hospital 0901 Adelaide Hospital, Dublin 0903 Meath Hospital, Dublin 0904 St. James's Hospital, Dublin 0908 Mater Misericordiae University Hospital, Dublin 0910 St. Vincent s University Hospital, Elm park 0912 St. Michael s Hospital, Dun Laoghaire 0913 Mercy University Hospital, Cork 0915 South Infirmary/Victoria, Cork 0918 St. John s Hospital, Limerick 0919 Portiuncula Hospital, Ballinasloe 0922 Our Lady of Lourdes Hospital, Drogheda 0923 Beaumont Hospital, Dublin 0925 Peamount Hospital, Newcastle 0930 Coombe Women and Infants University Hospital, Dublin 0931 National Maternity Hospital, Holles St, Dublin 0932 Rotunda Hospital, Dublin 0934 Waterford Maternity Hospital 0940 The Children s University Hospital, Temple St, Dublin 0941 Our Lady s Children s Hospital, Crumlin 0943 National Children s Hospital, Harcourt St 0945 St. Anne s Hospital, Dublin 0946 Hume St. Hospital, Dublin 0947 St. Luke s Hospital, Rathgar 0950 Royal Victoria Eye & Ear Hospital, Dublin 0954 Incorporated Orthopaedic Hospital, Clontarf 0955 National Orthopaedic Hospital, Cappagh 0956 St. Mary s Auxiliary Hospital, Baldoyle 0960 National Rehabilitation Hospital, (NHR), Dun Laoghaire 0978 Our Lady s Hospice, Harold s Cross, Dublin 1225 St. Joseph's Unit, Harold s Cross 1270 Adelaide, Meath Incorporating National Children s Hospital (AMNCH), Tallaght 1762 St. Joseph s Hospital, Raheny PCRS Primary Care Reimbursement Service Table HL7 User-defined Table 0396 Coding System Value 160

161 Value 99zzz or L ACR ART AS4 AS4E ATC C4 C5 CAS CD2 CDCA CDCM CDS CE CLP CPTM CST CVX DCL DCM DQL E E5 E6 E7 ENZC FDDC FDDX FDK HB HCPCS HHC HI HL7nnnn HPC I10 I10P I9 ICDO ICS ICSD ISOnnnn IUPP IUPC JC8 LB LN MCD MCR MDDX MEDC MEDR MEDX MGPI MVX Local general code (where z is an alphanumeric character) American College of Radiology finding codes WHO Adverse Reaction Terms ASTM E1238/ E1467 Universal AS4 Neurophysiology Codes American Type Culture Collection CPT-4 CPT-5 Chemical abstract codes CDT-2 Codes CDC Analyte Codes CDC Methods/Instruments Codes CDC Surveillance CEN ECG diagnostic codes CLIP CPT Modifier Code COSTART CDC Vaccine Codes DICOM Class Label DICOM modality codes DICOM Query Label EUCLIDES Euclides quantity codes Euclides Lab method codes Euclides Lab equipment codes Enzyme Codes First DataBank Drug Codes First DataBank Diagnostic Codes FDA K10 HIBCC HCFA Common Procedure Coding System Home Health Care Health Outcomes HL7 Defined Codes where nnnn is the HL7 table number HCFA Procedure Codes (HCPCS) ICD-10 ICD-10 Procedure Codes ICD9 International Classification of Diseases for Oncology ICCS International Classification of Sleep Disorders ISO Defined Codes where nnnn is the ISO table number IUPAC/IFCC Property Codes IUPAC/IFCC Component Codes Japanese Chemistry Local billing code Logical Observation Identifier Names and Codes (LOINC ) Medicaid Medicare Medispan Diagnostic Codes Medical Economics Drug Codes Medical Dictionary for Drug Regulatory Affairs (MEDDRA) Medical Economics Diagnostic Codes Medispan GPI CDC Vaccine Manufacturer Codes 161

162 Value NDA NDC NIC NPI OHA OHA POS RC SDM SNM SNM3 SNT UC UMD UML UPC UPIN W1 W2 W4 WC NANDA National drug codes Nursing Interventions Classification National Provider Identifier Omaha System Omaha POS Codes Read Classification SNOMED- DICOM Microglossary Systemized Nomenclature of Medicine (SNOMED) SNOMED International SNOMED topology codes (anatomic sites) UCDS MDNS Unified Medical Language Universal Product Code UPIN WHO rec# drug codes WHO rec# drug codes WHO rec# code with ASTM extension WHO ATC Table HL7 User-defined Table 0430 Mode of arrival code Value A C F H P O U Ambulance Car On foot Helicopter Public Transport Other Unknown Table HL7 User-defined Table Identity reliability code Value UD Unknown/Default Date of Birth 162

163 Appendix 4 Healthlink to HL7 mapping Table 111 HL7 abstract message type mapping to Healthlink message type Healthlink Message Type HL7 Abstract Message Type Healthlink Link Message Type ID Laboratory Order OML O21 1 Inpatient Admission ADT A01 2 A & E Notification ADT A01 4 Discharge Summary REF I12 5 Death Notification ADT A03 6 Radiology Result ORU R01 7 OPD Appointment SIU S12 8 Waiting List SIU S12 9 Laboratory Result ORU R01 10 Laboratory NACK ORL_O22 11 Discharge Notification ADT A03 12 Acknowledgement ACK 13 Neurology Referral REF_I12 14 Neurology Referral Response RRI_I12 15 Co-op Discharge REF_I12 16 Cardiology Result ORU R01 17 Oesophageal and Gastric Cancer REF_I12 18 Referral Prostate Cancer Referral REF_I12 20 Prostate Cancer Referral Response RRI_I12 21 Breast Cancer Referral REF_I12 22 Breast Cancer Referral Response RRI_I

164 Appendix 5 LOINC Codes used for Referral Messaging in Ireland Table 112 LOINC codes Code History of allergies History of family member diseases History of present illness History of surgical procedures Respiratory Symptoms and Diseases Physical Findings History General History of alcohol use History of past illness History of tobacco use Details of Chest Signs Chest signs Radiology Study Reports Current Medication Physical exam.total Urinalysis Previous Mammogram CT Scan Chest X-Ray Laboratory Studies Physical mobility impairment PSA Test Urology Study Social History Height Weight Breast Examination Body Mass Index History of Asthma Diastolic Blood Pressure Systolic Blood Pressure Cigarettes Smoked per day Pulse Reason for Referral 164

165 Appendix 6 LOINC Copyright Notice and License The LOINC codes, LOINC table (regardless of format), LOINC Release Notes, LOINC Changes File, and LOINC Users' Guide are copyright , Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee. All rights reserved. The RELMA program, RELMA database and associated search index files (subject to the copyright above with respect to the LOINC codes and LOINC table included therein), RELMA Release Notes, and RELMA Users' Manual are copyright , Regenstrief Institute, Inc. All rights reserved. The LOINC panels and forms file and the LOINC hierarchies file (subject to the copyright above with respect to the LOINC codes and LOINC table to the extent included in the LOINC panels and forms file and the LOINC hierarchies file), are copyright , Regenstrief Institute, Inc. All rights reserved. LOINC and RELMA are registered United States trademarks of Regenstrief Institute, Inc. Permission is hereby granted in perpetuity, without payment of license fees or royalties, to use, copy, or distribute the RELMA program, RELMA Users' Manual, RELMA Release Notes, RELMA database and associated search index files, LOINC codes, LOINC Users' Guide, LOINC table (in all formats in which it is distributed by Regenstrief Institute, Inc. and the LOINC Committee), LOINC Release Notes, LOINC Changes File, LOINC panels and forms file, and LOINC hierarchies file (collectively, the "Licensed Materials") for any commercial or non-commercial purpose, subject to the following terms and conditions: 1. To prevent the dilution of the purpose of the LOINC codes and LOINC table of providing a definitive standard for identifying clinical information in electronic reports, users shall not use any of the Licensed Materials for the purpose of developing or promulgating a different standard for identifying patient observations, such as laboratory test results; other diagnostic service test results; clinical observations and measurements; reports produced by clinicians and diagnostic services about patients; panels, forms and collections that define aggregations of these observations; and orders for these entities in electronic reports and messages. 165

166 2. If the user elects to utilize the RELMA program, users receive the full RELMA database and associated search index files with the RELMA program, including the LOINC table and other database tables comprising the RELMA database. In addition to its use with the RELMA program, users may use the LOINC table by itself and may modify the LOINC table as permitted herein. Users may not use or modify the other database tables from the RELMA database or the associated search index files except in conjunction with their authorized use of the RELMA program, unless prior written permission is granted by the Regenstrief Institute, 3. Inc. To request written permission, please contact 4. Users shall not change the meaning of any of the LOINC codes. Users shall not change the name of, or any contents of, any fields in the LOINC table. Users may add new fields to the LOINC table to attach additional information to existing LOINC records. Users shall not change the content or structure of the LOINC panels and forms from the LOINC panels and forms file, but may notify the Regenstrief Institute of any potential inconsistencies or corrections needed by contacting 5. A user may delete records from the LOINC table to deal with the user's local requirements. A user also may add new records to the LOINC table to deal with the users' local requirements, provided that if new records are added, any new entry in the LOINC_NUM field of such new records must contain a leading alphabetic "X" so that the new codes and records cannot be confused with existing LOINC codes or new LOINC codes as they are defined in later releases of the LOINC table. Records deleted or added by users to deal with local requirements are not reflected in the official LOINC table maintained by the Regenstrief Institute and the LOINC Committee. Users must also make reasonable efforts to submit requests to LOINC for new records to cover observations that are not found in the LOINC table in order to minimize the need for X-codes. 6. LOINC codes and other information from the LOINC table may be used in electronic messages for laboratory test results and clinical observations such as HL7 ORU messages, without the need to include this Copyright Notice and License or a reference thereto in the message (and without the need to include all fields required by Section 7 hereof). When the LOINC code (from the LOINC_NUM field) is included in the message, users are encouraged, but not required, to include the corresponding LOINC short name (from the SHORTNAME field) or the LOINC long common name (from the LONG_COMMON_NAME field) in the message if the message provides a place for a text name representation of the code. 166

167 7. Users may make and distribute an unlimited number of copies of the Licensed Materials. Each copy thereof must include this Copyright Notice and License, and must include the appropriate version number of the Licensed Materials if the Licensed Materials have a version number, or the release date if the Licensed Materials do not have a version number. This Copyright Notice and License must appear on every printed copy of the LOINC table. Where the Licensed Materials are distributed on a fixed storage medium (such as diskette or CD-ROM), a printed copy of this Copyright Notice and License must be included on or with the storage medium, and a text file containing this information also must be stored on the storage medium in a file called "license.txt". Where the Licensed Materials are distributed via the Internet, this Copyright Notice and License must be accessible on the same Internet page from which the Licensed Materials are available for download. This Copyright Notice and License must appear verbatim on every electronic or printed copy of the RELMA Users' Manual and the LOINC Users' Guide. The RELMA Users' Manual and the LOINC Users' Guide may not be modified, nor may derivative works of the RELMA Users' Manual or LOINC Users' Guide be created, without the prior written permission of the Regenstrief Institute, Inc. To request written permission, please contact loinc@regenstrief.org. The Regenstrief Institute retains the right to approve any modification to, or derivative work of, the RELMA Users' Manual or the LOINC Users' Guide. 8. Subject to Section 1 and the other restrictions hereof, users may incorporate portions of the LOINC table, LOINC panels and forms file, and LOINC hierarchies file into another master term dictionary (e.g. laboratory test definition database), or software program for distribution outside of the user's corporation or organization, provided that any such master term dictionary or software program includes the following fields reproduced in their entirety from the LOINC table: LOINC_NUM, COMPONENT, PROPERTY, TIME_ASPCT, SYSTEM, SCALE_TYP, METHOD_TYP, STATUS, and SHORTNAME. Users are also required to either: (1) include the EXTERNAL_COPYRIGHT_NOTICE or (2) delete the rows that include third party copyrighted content (e.g., third party survey instruments and answers). If third party content is included, users are required to comply with any such third party copyright license terms. Users are encouraged, but not required, to also include the RelatedNames2 and the LONG_COMMON_NAME in any such database. Further description of these fields is provided in Appendix A of the LOINC Users' Guide. Every copy of the LOINC table, LOINC panels and forms file, and/or LOINC hierarchies file incorporated into or distributed in conjunction with another database or software program must include the following notice: 167

168 "This product includes all or a portion of the LOINC table, LOINC panels and forms file, and/or LOINC hierarchies file, or is derived from one or more of the foregoing, subject to a license from Regenstrief Institute, Inc. Your use of the LOINC table, LOINC codes, LOINC panels and forms file, and LOINC hierarchies file also is subject to this license, a copy of which is available at The current complete LOINC table, LOINC Users' Guide, LOINC panels and forms file, and LOINC hierarchies file are available for download at The LOINC table and LOINC codes are copyright , Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee. The LOINC panels and forms file and LOINC hierarchies file are copyright , Regenstrief Institute, Inc. All rights reserved. THE LOINC TABLE (IN ALL FORMATS), LOINC PANELS AND FORMS FILE, AND LOINC HIERARCHIES ARE PROVIDED "AS IS." ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. LOINC is a registered United States trademark of Regenstrief Institute, Inc. A small portion of the LOINC table may include content (e.g., survey instruments) that is subject to copyrights owned by third parties. Such content has been mapped to LOINC terms under applicable copyright and terms of use. Notice of such third party copyright and license terms would need to be included if such content is included." If the master term dictionary or software program containing the LOINC table, LOINC panels and forms file, and/or LOINC hierarchies file is distributed with a printed license, this statement must appear in the printed license. Where the master term dictionary or software program containing the LOINC table, LOINC panels and forms file, and/or LOINC hierarchies file is distributed on a fixed storage medium, a text file containing this information also must be stored on the storage medium in a file called "LOINC_short_license.txt". Where the master term dictionary or software program containing the LOINC table, LOINC panels and forms file, and/or LOINC hierarchies file is distributed via the Internet, this information must be accessible on the same Internet page from which the product is available for download. 9. Use and distribution of the Licensed Materials in ways that are not specifically discussed herein shall always be accompanied by the notice provided in Section 7 hereof. The guidelines for providing the notice that are contained in the last paragraph of Section 7 also shall apply. If a user has a question about whether a particular use of any of the Licensed Materials is permissible, the user is invited to contact the Regenstrief Institute by at loinc@regenstrief.org. 168

169 10. If the user desires to translate any of the Licensed Materials into a language other than English, then user shall notify Regenstrief via at loinc@regenstrief.org. Any such translation is a derivative work, and the user agrees and does hereby assign all right, title and interest in and to such derivative work: (1) to Regenstrief and the LOINC Committee if the translation is a derivative of the LOINC codes, LOINC Users' Guide, or LOINC table, and (2) to Regenstrief if the translation is a derivative work of the RELMA program, LOINC panels and forms file, LOINC hierarchies file, RELMA Users' Manual, RELMA database or associated search index files. Further, user shall fully cooperate with Regenstrief in the filing and reviewing of any copyright applications or other legal documents, and signing any documents (such as declarations, assignments, affidavits, and the like) that are reasonably necessary to the preparation of any such copyright application. The assignment granted by this paragraph extends to all proprietary rights both in the United States, and in all foreign countries. No other right to create a derivative work of any of the Licensed Materials is hereby granted (except the right to translate into a language other than English granted in this Section 9), and Regenstrief and the LOINC Committee respectively reserve all other rights not specifically granted herein. All such translations shall be electronically transmitted to Regenstrief, and such translations shall be made available and are subject to the same license rights and restrictions contained herein. Regenstrief will give credit on its website (and on screens in RELMA and in its users guides) to the user and/or entity that did the translation. 11. The Regenstrief Institute, Inc. and the LOINC Committee welcome requests for new LOINC content (terms, codes or associated material such as text descriptions and synonyms) and suggestions about revisions to existing content within the Licensed Materials. Any content submitted in conjunction with such a request is subject to the LOINC Submissions Policy, which is available at The names "Regenstrief," "Regenstrief Foundation," "Regenstrief Institute," and "LOINC Committee" may not be used in a way which could be interpreted as an endorsement or a promotion of any product or service without prior written permission of the Regenstrief Institute, Inc. Further, no right to use the trademarks of Regenstrief is licensed hereunder. To request written permission, please contact loinc@regenstrief.org. 169

170 13. DISCLAIMER: REGENSTRIEF INSTITUTE, INC. AND THE LOINC COMMITTEE, AS WELL AS ANY CONTRIBUTORS WHO HAVE PROVIDED TRANSLATIONS OF THE LICENSED MATERIALS, DO NOT ACCEPT LIABILITY FOR ANY OMISSIONS OR ERRORS IN THE LICENSED MATERIALS OR ANY OTHER MATERIALS OBTAINED FROM REGENSTRIEF INSTITUTE, INC. AND/OR THE LOINC COMMITTEE. THE LICENSED MATERIALS AND ALL OTHER MATERIALS OBTAINED FROM REGENSTRIEF INSTITUTE, INC. AND/OR THE LOINC COMMITTEE ARE PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND. ANY EXPRESSED OR IMPLIED WARRANTIES ARE HEREBY DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND WARRANTIES ARISING FROM A COURSE OF DEALING, TRADE USAGE, OR TRADE PRACTICE. FURTHER, NO WARRANTY OR REPRESENTATION IS MADE CONCERNING THE ACCURACY, COMPLETENESS, SEQUENCE, TIMELINESS OR AVAILABILITY OF THE LICENSED MATERIALS OR ANY OTHER MATERIALS OBTAINED FROM REGENSTRIEF INSTITUTE, INC. AND/OR THE LOINC COMMITTEE, OR ANY TRANSLATIONS OR DERIVATIVE WORKS OF ANY OF THE FOREGOING. IN NO EVENT SHALL REGENSTRIEF INSTITUTE, INC. OR THE LOINC COMMITTEE OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, RELIANCE, OR CONSEQUENTIAL DAMAGES OR ATTORNEYS' FEES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; OPPORTUNITY COSTS; LOSS OF USE, DATA, SAVINGS OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THE LICENSED MATERIALS OR ANY OTHER MATERIALS OBTAINED FROM REGENSTRIEF INSTITUTE, INC. AND/OR THE LOINC COMMITTEE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE OR IF SUCH DAMAGES WERE FORESEEABLE. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OR EXCLUSION OF CERTAIN WARRANTIES OR CONDITIONS, SO SOME OF THE FOREGOING MAY NOT APPLY TO YOU. 14. This license shall be construed and interpreted in accordance with the laws of the State of Indiana, United States of America, excluding its conflicts of law rules. 170

171 Notice of Third Party Content and Copyright Term: General Practice Messaging Standard Version 3.0 A small portion of the content of the LOINC table, LOINC panels and forms, LOINC hierarchies, RELMA database and associated search index files consists of content subject to copyright from third parties. This third party content is either used with permission or under the applicable terms of use. In all such cases, we have included the copyright notice. This third party content is highlighted in the program as follows: When such copyright content appears in the RELMA look-up grid, RELMA will highlight the row containing that content by printing in a different background color and using italics. It will also include a link in the (EXT (C)) column. By clicking on that link, users will get to the copyright notice and to the terms of use for the content of those LOINC-mapped terms. In the case of a LOINC table (e.g. the tab delimited file or the LOINC Access database) we include the copyright notice (up to 250 characters). We have included third party content that allows use and distribution at least for clinical, administrative and research purposes. The third party copyright owners generally ask for attribution of the source, allow the free use of the content for treatment, health care management, and research purposes. They generally forbid alteration of their content (e.g., survey questions and/or answers) and use for commercial purpose, which usually means the direct sale of the survey instruments, but they often do allow use of their content in commercial software, medical record and other clinical database systems, and the messaging of patient information collected through the use of these instruments. The details of the notice of copyright for any third party content can be found in association with the terms when using the RELMA look-up tool or the LOINC table. The copyright of the LOINC codes per se remain owned by Regenstrief Institute, Inc. and the LOINC Committee and subject to the LOINC Copyright Notice and License. In the future, we expect to include many more survey instruments and questionnaires from third parties with permission (especially those required by the U.S. federal government for payment and reimbursement) and believe that cataloguing all of these data collection forms in one comprehensive system (the LOINC table) along with laboratory and other clinical variables will facilitate the use of this data in direct clinical care, research and practice management. Taken from: 171

172 Appendix 7 Change History List of Changes from GPMS v001 to GPMS v Change ENV to correct abbreviation EVN where needed. 2. MSH.3 - Comment added in description field about HD Datatype. 3. Changed the cardinality of MSH.3/HD.1/HD.2/HD.3 from R to C. 4. Changed the cardinality of MSH.4/HD.1/HD.2/HD.3 from O to C. 5. Changed the cardinality of MSH.5/HD.1/HD.2/HD.3 from O to C. 6. Changed the cardinality of MSH.6/HD.1/HD.2/HD.3 from O to C. 7. Deleted length values from all subcomponents. Only top level components will have datatypes. 8. Included table value 0363 for HL7 element PID.3/CX.4/HD.1 (copied contents of 0362 to 0363 and included value code and description for PCRS in table Removed table 0203 from HL7 element PID.3/CX.4/HD.3 and replaced with table The XTN.1/2/3/4/6 and 7 data types were updated for PID.13, PID.14, OBR.17 and PRD.XTN.5 (Country code) was excluded. 11. The comment When used for backward compatibility, this field contains the patient s social security number for PID.19 was removed. 12. OBR.25 - Result Status Included a comment to refer the reader to the message flow for Corrected Results for workflow for updated results. 13. OBR.28/XCN.16 Included a comment to refer the reader to use cases Unsolicited Laboratory Result, Unsolicited Radiology Result and Corrected Result for specific usage of this field. 14. OBX.11 - Observation Result Status, Included a comment to refer the reader Please refer to message flow Corrected Results for workflow for updated results. 15. SCH.11/TQ.6 There is no table available in HL7 v2.4 for priority component. The values suggested in the HL7 v2.4 spec for the priority component are listed in the GPMS. 16. The segment PV2 Event Type/Additional information was included in the list of segments in the death notification message flow. 17. Acknowledgement messages were represented in the referral and response message flows. 18. The segment NTE Notes and Comments was included in the list of segments in the laboratory order message flow. 19. The following segments were included in the minimum laboratory order acknowledgement message response ORL_O22 contains the following segments:msh Message Header, MSA Message Acknowledgement and ERR Message Error Segment. 172

173 20. Acknowledgement messages were represented in the unsolicited radiology message flow. 21. Status information and copy to information were included in the notes section of the unsolicited radiology result message flow. 22. Acknowledgement messages were represented in the unsolicited laboratory message flow. 23. Status information and copy to information were included in the notes section of the unsolicited laboratory result message flow. 24. A new message flow for corrected results was created. 25. A new section (7) regarding LOINC codes was created and the LOINC codes currently available for referral messages listed in appendix Appendix 2.0 Abstract message definitions; the general acknowledgement ACK abstract message definition was included. 27. Appendix 3.0 Reference Tables. The value HLID:Healthlink ID was included in HL7 User-defined Table 0203 Identifier type (GPMS Table 70). 28. Additional values were include in HL7 User-defined Table 0281 Referral type provided by Healthlink. 29. A new table was created for HL7 User-defined Table Universal ID type and populated with HL7v2.4 values and Department of Health (DOH). 30. Values (provided by Healthlink) were included in HL7 User-defined Table 0361 sending application. 31. A new table HL7 User-defined Table 0363; assigning authority was created. The contents from Table 0362 were copied and an additional value PCRS was added. 32. A new table HL7 User-defined Table 0396; coding system was created. 33. A new table for LOINC codes was created. 34. Copyright and licensing was recreated from LOINC terms of use and is available in Appendix 6. List of Changes from GPMS v002 to GPMS v New section added to incorporate the electronic transfer of prescriptions from GP s to community pharmacy including the outpatients of hospitals. 36. Addition of new values to table Addition on new value to table Addition of new value to table Addition of new values to table Addition of new value to table Addition of new value to table Addition of new codes to table

174 174

175 Published by the. For further information please contact: Dublin Regional Office George s Court George s Lane Smithfield Dublin 7 Phone: +353 (0) URL: