DIAGNOSTIC TEXT AND OTHER TRANSCRIBED REPORTS MESSAGE SPECIFICATION

Health Information Messaging Standard HEALTH INFORMATION STANDARDS COMMITTEE FOR ALBERTA DIAGNOSTIC TEXT AND OTHER TRANSCRIBED REPORTS MESSAGE SPECIFICATION Status: Accepted in Draft Version 0.5 Status Date: April 28, 2011

Revision History Version Revision Date Summary of Changes 0 2005-Sep-30 Draft 0 2005-Nov-21 Accepted in Draft 0.1 2006-May-31 Include ORC segment in the message specification. Only the MWB (ORU_R01) file is revised to include the ORC segment as an optional segment in the message structure. The MWB (MDM) message structure does not support ORC segment and hence MDM profile was not revised. The ORC segment has Order Control field as the only entry and references HL70119 table. 0.2 2006-Dec-31 Include EVN Event Type segment in the MDM message profile. MDM messages sent to CH by ACB contain EVN segment. 0.3 (was incorrectly 2009-Aug-12 Fix Source Table specification in the ORU message. The fix affects the following fields: labelled as - Principal Result Interpreter 0.4) - Technician - Transcriptionist 0.5 2011-Apr-28 Added parsing/encoding character resolution OBX segment is optional and repeatable to allow for combined results Change references of RHA s to AHS Zones Changes are backward compatible with version 0.3 (previous version) Added support for DSR ID for all fields referencing a Facility Identifier by increasing fields that were 10 in length to 20 and adding a note to use DSR ID where possible. - MDM: MSH 4.1, MSH 6.1, PV1 3.4.1 - ORU: MSH 4.1, MSH 6.1, PV1 3.4.1 Removed ambiguous language and system specific references. Any system variations previously documented will be moved to conformance variations document. 2011 Government of Alberta 2 of 68

Table of Contents Revision History...2 General Overview...6 Business Process Overview...6 Process Flow...7 Report Description...7 Diagnostic Imaging Text Report...7 Operative Report...8 Patient History Report...8 Consultation Report...9 Discharge / Obstetrical Discharge Summary Report...10 Report of Procedure...11 E.E.G. Text Report...11 Clinic Report / Progress Note...12 Letter...12 E.C.G. Text Report...13 Report Process...15 Process Flow...15 Actors...16 Precondition...16 Narrative...16 Alternative Flow...17 Post Condition...17 Use Cases Specification...18 Use Case Diagram...18 Use Case: Communicate Transcribed Report (Ref# UC01)...18 Brief Description...18 Basic Flow of Events...19 Alternative Flows...19 Special Requirements...19 Preconditions...19 Postconditions...19 Additional Information...19 Use-Case: Communicate DI Text Report (Ref# UC02)...20 Brief Description...20 Basic Flow of Events...20 Alternative Flows...20 Special Requirements...20 Preconditions...20 Postconditions...20 Additional Information...20 Transaction Summary...21 Overview...21 MDM_T02...21 Message Purpose...21 Message Rules...21 Transaction Messages...24 Error Conditions...24 ORU_R01...25 Message Purpose...25 Message Rules...25 Transaction Messages...25 Error Conditions...25 Transaction Message Detail...25 Section Guide...25 Characteristics...26 Profile Type...26 2011 Government of Alberta 3 of 68

Interactions...26 Message Characteristics...26 Segment and Segment Group Definitions...27 Segment Table...28 Seq. (Sequence)...28 Name...29 Type...29 Table...29 Len. (Length)...29 Optionality...29 Card. (Cardinality)...29 Contents...29 Segment Element Details...30 General Notes...30 MDM - Transcribed Reports Delivery Message Specification...31 Parameters...31 Identifiers...31 Conformance...31 Message...31 Encoding Method...31 Message...32 Grammar...32 MSH Message Header Segment...32 EVN Event Type...33 PID Patient Identification...34 PV1 Patient Visit...36 TXA Document Notification Segment...39 OBX - Observation segment...42 ORU Observation Result / Unsolicited...44 Parameters...44 Identifiers...44 Conformance...44 Message...44 Encoding Method...44 Message...45 Grammar...45 MSH Message Header Segment...45 PID Patient Identification...47 PV1 Patient Visit...49 ORC Common Order Segment...51 OBR Observation Request Segment...52 OBX Observation Segment...55 HL70001 Sex (User)...56 HL70003 Event Type (HL7)...56 HL70004 Patient Class (User)...56 HL70062 Event Reason (User)...56 HL70076 Message Type (HL7)...56 HL70103 Processing ID (HL7)...56 HL70104 Version ID (HL7)...57 HL70119 Order Control Code (HL7)...57 HL70123 Result Status (HL7)...57 HL70125 Value Type (HL7)...57 HL70136 Yes/No Indicator (HL7)...58 HL70191 Main Type of Reference Data (HL7)...58 HL70270 Document Type (User)...58 HL70301 Universal ID Type (HL7)...58 HL70396 Coding System (HL7)...58 99-0001 Province Codes (Local)...59 2011 Government of Alberta 4 of 68

Appendix - B: Error Conditions...60 Appendix - C: HL7 Data Types...61 Appendix - D: Glossary...65 Appendix - E: Report Data Element Mapping to HL7...66 Segment/Fields...66 Common Elements to MDM and ORU Domain...66 Elements Different in MDM and ORU Domain...66 Appendix - F: Contact Information...68 2011 Government of Alberta 5 of 68

General Overview This document presents the message specifications for the Diagnostic Imaging Text and Other Transcribed Reports Message Specification project. The standardized set of message specifications detailed in this document will minimize the development effort required for sending and receiving Diagnostic Imaging Text and Other Transcribed Reports. This project is the result of needs identified by the Alberta Health System 2004-2007 IM/IT Electronic Health Record (EHR) Strategic Plan to deliver Diagnostic Imaging Text and Other Transcribed Reports to Physician Office Systems electronically within the province of Alberta. For this project, Alberta Health and Wellness (AHW) formed a Diagnostic Imaging Text and Other Transcribed Reports Working Group (DITR WG) including the following groups and organizations: 1. Alberta Health Services, 2. Physician Office System Program (POSP), 3. Canadian Healthcare Information Technology Trade Association (CHITTA), and 4. Alberta Health and Wellness The project team worked with the DITR WG to refine and developed a Health Level 7 (HL7) message specification that is to be used for the electronic delivery of Diagnostic Imaging Text and Other Transcribed Reports (DITR). A standard message specification developed by the Project team and presented in this document is a result of this cooperation and workshops that were on July 19, August 3 and 17, and September 8, 21, 30, 2005. Continued changes to the Alberta health system have triggered the need for additional amendments to the DITR message specification. The first, the formation of the Alberta Health Services which consolidated nine health regions into one health region. This organizational change generated the need to determine the differences between the DITR messages of all former health regions. The second, the addition of the Integration Coordination Centre (ICC) at Alberta Health Services has introduced new conformance requirements. In consultation with the Alberta HL7 Working Group, the ICC has assisted in identifying where the HL7 message specification could be improved. These changes have made the DITR messaging specification more robust. This document is comprised of two components: 1. A Process Flow, including diagrams, narrative describing each type of the report, workflow, use case model, description of the user-to-system interactions, and mapping between report data elements and HL7 fields. 2. A Message Profile, including transaction message details, transaction message tables and HL7 data types. Also, this section provides detailed descriptions for Unsolicited Transmission of an Observation Message (ORU) and Medical Document Management message specifications (MDM). Business Process Overview The purpose of this message specification is to provide a design standard for electronic transmission of diagnostic imaging textual reports and other transcribed reports from Alberta Health Services and Alberta Cancer Board to the Physician Office Systems (POS) and/or Electronic Medical Record (EMR). The standardized set of message specifications described in this document will minimize the development effort required for sending and receiving Diagnostic Imaging Text and Other Transcribed Reports. Currently, there are two message domains used in the province of Alberta - Observation Reporting (OBR and OBX) for transcribed reports and Document Management (MDM and TXA). The DITR WG has decided to build two message specifications and to support two message domains for this project as presented below: 1. MDM - This message is used to transport electronic copies of Transcribed Reports from the AHS Zone to a Designated Report Repository allowing the appropriate EMR to pick up the transcribed reports on a predefined schedule. This message supports the transmission of a new or updated 2011 Government of Alberta 6 of 68

document. The MDM message is concerned primarily with the management of documents, which are created as a result of the transcription process. 2. ORU - This message is used to transport electronic copies of Diagnostic Imaging Text and Other Transcribed Reports from an AHS facility to the appropriate Physician Office System(s) (POS). Note: The message specifications presented in this document are based on the DI Text and Transcribed Reports Message Specification (Alberta Health and Wellness, March 31, 2005) recommendations. Process Flow The Process Flow illustrates the workflow of reports from origination to destination. It also identifies each actor (i.e. a person/position or system) involved and the key activities they perform in completing the process. The Process Flow provides the framework to understanding the context and requirements of each message. The Process Flow includes: A short description of each report; A Process Map (a flowchart illustrating the process activities); A list and description of the actors who will participate in the process; A Storyboard (a narrative describing the activities performed by each actor in the process); and A Use Case. Note: The Storyboard text includes numbers in brackets. These numbers correspond to activities described in the process map. Report Description Diagnostic Imaging Text Report The Diagnostic Imaging Text Report is dictated after the diagnostic imaging exam is completed. The exam is performed during the current treatment of the patient or any follow-up for a patient s condition. The report is dictated by the radiologist, nuclear medicine physician, or resident doctor. The report indicates what imaging/procedure was completed, any findings from the study, the radiologist s diagnosis text and code, and any further recommendations/follow-up that are required. The report includes such data as the date & time of the examination, patient s first & last name, demographics, chart number, diagnostic imaging (DI) number, date of birth (DOB), provincial health number (PHN), inpatient/ outpatient (IP/OP) information, emergency information, clinic location, address, phone, and name of facility. Report copies are distributed as requested by the author of the report. Possible receivers of this report are: attending physician (hospitals), ordering physician (emergency), family physician, referring physician (medical centre), or any other doctors that are specified by the dictator of the report. In order for any recipient to receive a copy, the author must request that a copy be sent to them. Pediatric and Gynecological patient reports are only sent to the requesting physician no other copies are sent. Exceptions: AHS - Edmonton No Exceptions AHS - Calgary 2011 Government of Alberta 7 of 68

Exception # 1 There is no restriction that Pediatric and Gynecological patient reports are only to be sent to the requesting physician. Exception # 2 A report copy is sent by default to the family physician and ordering physician. AHS - Rural Exception # 1 There is no restriction that Pediatric and Gynecological patient reports are only to be sent to the requesting physician. Exception # 2 A report copy is sent by default to the family physician and ordering physician. Alberta Cancer Board No Exceptions Additional information: Sometimes an exam is incomplete or unsuccessful, but a report is still dictated to make the physician aware of the situation. Operative Report The Operative Report is dictated after a patient has either an inpatient or day surgery procedure with general anesthetic as part of his/her treatment. The admission can be an elective, emergency, etc. The report is dictated by the attending surgeon or a resident who dictates the report on behalf of the surgeon. The report describes the procedure that was performed, the preoperative & postoperative diagnoses, and operative findings. It contains the surgeon s impression of the procedure and the result of the operative procedure. The report may also contain diagnosis and recommendations for follow-up. The report contains such data as the responsible surgeon and other significant participants (assistants, anesthetists, etc.), patient s first & last name, patient s demographics, chart number, DOB, PHN, location, name of facility, date of procedure, postoperative plan, and listing of copies. Report copies are distributed as requested by the author of the report. The report may be received by anyone involved in direct care post-surgery. The recipient list may include a family physician, referring physician, or any other physician that the surgeon specifies. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton No Exceptions AHS - Calgary No Exceptions AHS - Rural No Exceptions Alberta Cancer Board No Exceptions Additional information: If an Operative Report has not been dictated when the patient has been discharged, the chart is considered deficient until the report is dictated and filed on the chart. Patient History Report The Patient History Report is dictated after a patient is admitted to the hospital for a disease, illness or other condition requiring further treatment and follow-up in the hospital. The report is dictated by the admitting physician, resident, or student intern. The report is created after an initial examination/admission or preoperational consultation. 2011 Government of Alberta 8 of 68

The report documents all the previous and present medical, physical and surgical history of the patient. The report contains a general description and assessment of the current conditions and complaints of the patient and provides a summary of past medical events and problems. The report may contain list of medications, allergies, past medical history, and family & social history. Additionally, the report may provide the reason for the patient s admission and possible diagnoses, preliminary laboratory and DI investigations, treatment plan and possible referrals for confirmation of diagnoses. The report contains such data as the admission date, the examining physician (including his or her signature), the patient s first & last name, chart number, DOB, PHN, location, name of facility (hospital or clinic), patient s demographics, the name of the author of the report, and listing of copies. Report copies are distributed as requested by the author of the report. The receiving list may include the admitting physician, family physician, or any other physician that the admitting physician specifies. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. The receiving physicians may refer the patient to another specialist for further consultation depending on what the illness or disease is. Exceptions: AHS - Edmonton Exception # 1 - In most cases, copies of the transcribed history are not sent out. The majority of histories transcribed for AHS Edmonton are for inpatients and only one copy is printed for the patient's chart. There are a few exceptions to this rule and these exceptions are specific to a site (i.e. Royal Alexandra Hospital, Rural Hospitals, etc). AHS - Calgary Exception # 1 Very few histories are transcribed; they are either provided by the admitting physician s office or are hand written on site. AHS - Rural No Exceptions Alberta Cancer Board No Exceptions Additional information: None Consultation Report The Consultation Report is dictated after a patient visits a specialist (consulting physician) as per a consultation request by the attending physician. The attending physician needs advice for further treatment and follow-up of a disease, injury or investigation pertaining to the patient s condition. The report is dictated by the consulting physician, resident, student intern, or nurse. The Consultation Report can be initial and repeat. This report provides expert opinions, impressions, a diagnosis, modified treatment plan and recommendations for care or treatment if appropriate. It may contain list of medications, allergies, past medical history, and family & social history, or initiate further testing or surgery. The report contains such data as the report date, the consultant s name, identification of the attending physician and the associated hospital or clinic. It provides the patient s first & last name, patient s demographics, chart number, DOB, PHN, room, location, name of facility, and listing of copies. Report copies are distributed as requested by the author of the report. The list may include the admitting/referring physician, consultant, family physician, or any other doctors that the consulting physician specifies. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton No Exceptions 2011 Government of Alberta 9 of 68

AHS - Calgary No Exceptions AHS - Rural No Exceptions Alberta Cancer Board No Exceptions Additional information: The Consultation Report is sometimes hand written. Discharge / Obstetrical Discharge Summary Report This report is created following a patient s discharge from the hospital after having the necessary treatment and management or, in the case of the obstetrical discharge, after a patient has had a delivery and confinement. The report is dictated by the most responsible physician, the admitting physician, the nurse practitioner, the resident, or the clinical clerk on behalf of the physician, or by the obstetrician (if discharge is obstetrical). The report gives an overview of the medically significant events that have occurred over the course of a clinical encounter. It may contain the list of medications, performed procedures, any allergies, medical history, family & social history, physical exam information, summary of present complaint, discharge diagnosis, diagnosis most responsible for stay, other diagnosis, any complications, follow-up recommendations in the community, and treatment plan. The obstetrical discharge report provides a summary of the obstetrical encounter, the care provided during an episode of care, treatments, procedures, medications, consultations and diagnostic procedures. Also, it contains information about a baby and primary mother. The report includes such data as the admission & discharge dates, the reason for admission, the name of the author of the report, listing of copies, the patient s first & last name, patient demographics, chart number, DOB, PHN, clinic location, and name of facility. Report copies are distributed as requested by the author of the report. A report copy is sent to the most responsible physician (i.e. surgeon if an OR is performed). The receiving list may contain a family physician, follow-up specialist, community health nurse, referring physician, or any other physician specified by the dictator of the report. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton Exception # 1 A "Short-Stay" form is used. This is a hand written summary that provides physicians with details about a patient's stay. This form can only be used for a stay that is less than 2 days or thereabouts. AHS - Calgary Exception # 1 A Delivery Note template is used. (Note: this template is categorized under the Operative Report type and is not a Discharge Summary.) AHS - Rural Exception # 1 A Delivery Report is created describing the birth and physical examination of the baby after the patient has had a normal delivery and confinement. A Discharge Summary is then created with any outpatient follow-up. Alberta Cancer Board No Exceptions Additional information: 2011 Government of Alberta 10 of 68

Discharge Summary and Obstetrical Discharge Summary reports can use the same template a newborn baby would normally go under mother unless there are complications then they get their own discharge summary report. This decision is under physician s discretion. Specific tumor groups require discharge letters be sent to the General Practitioner (GP) and the patient. Report of Procedure The Report of Procedure is dictated after a patient has had a day surgery or a minor, elective procedure for which no general anesthetic is required. If diagnosis is chronic, the procedure could be a part of continuing care for the patient. The report is dictated by the obstetrician, radiologist, nuclear medicine physician, resident, or student intern. The report summarizes the elements of a medical procedure performed on the patient. The report provides a narrative description of the procedure, diagnosis, the short clinical history, type of procedure performed, and findings. It may provide differential diagnoses pending path results and therapies. The report contains such data as the patient s first & last name, chart number, DOB, PHN, clinic location, and the name of the facility. Report copies are distributed as requested by the author of the report. The receiving list may include a family physician, referring physician, surgeon, and/or attending physician. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton No Exceptions AHS - Calgary No Exceptions AHS - Rural No Exceptions Alberta Cancer Board No Exceptions Additional information: Some procedures depicted by this report are: colposcopy, biopsy, caesarian section delivery, and gastroscopy. The report s outcome may indicate follow-up treatment. Frequently, the report is followed up by post imaging report. E.E.G. Text Report The Electroencephalogram (E.E.G.) Text Report is dictated after the E.E.G. is completed and sent to the interpreting physician to detail the results. The report is created by the neurologist who interprets the E.E.G. exam and tracings. The neurologist has to be qualified and accredited (CPSA) to interpret E.E.G. s. The report summarizes the neurologist s interpretation of the E.E.G. results, the procedure performed, and the diagnosis. It contains such data as the date & time of the examination and report generation, the patient s first & last name, demographics, chart number, DOB, PHN, clinic location, address and phone, the name of the author of the report, and listing of copies. Report copies are distributed as requested by the author of the report. Possible receivers are: attending physician (hospitals), referring physician (medical centre), or any other doctors that are specified. 2011 Government of Alberta 11 of 68

However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton No Exceptions AHS - Calgary No Exceptions AHS - Rural No Exceptions Alberta Cancer Board No Exceptions Additional information: This report is similar to the Diagnostic Imaging Text report. Clinic Report / Progress Note The Clinic Report / Progress Note is created when the patient is referred to and examined by a specialist in an outpatient clinic in the hospital during the patient s current treatment. The report is dictated by the consulting physician from the clinic, by a resident, nurse, or other allied health professional (physiologist, social worker, speech therapist, audiologist, etc.). The report provides summary of the patient s progress to date and further treatment required. It may contain list of medications, allergies, past medical history, family & social history, physician exam information, and summary of present complaint. Additionally, the report contains such data as the identification of the hospital or clinic, the responsible physician and other significant participants in the procedure, the patient s first & last name, demographics, chart number, DOB, PHN, and listing of copies. Report copies are distributed as requested by the author of the report. Possible receivers may be a family physician, referring physician, individuals involved in the patient s care, and responsible specialist. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton No Exceptions AHS - Calgary No Exceptions AHS - Rural No Exceptions Alberta Cancer Board Exception # 1 A Progress Note is used instead of a Clinic Report. Additional information: A Clinic report can be generated by a number of different clinics including; dermatology, ear, nose & throat, arthritis, neurology, and gerontology. Letter The Letter Report is created when a physician decides to communicate information to another physician, specialist, clinic, hospital, or other health authority. This type of a report is very generic: it communicates information to other entities for any purpose the physician desires. 2011 Government of Alberta 12 of 68

The report can be dictated by the consulting physician from the clinic, the treating physician, nurse, or other allied health professional (physiologist, social worker, speech therapist, audiologist, etc.). The report generally provides information regarding the patient s diagnosis and care. It may contain, among others, list of medications, allergies, past medical history, family & social history, physician exam information, and summary of present complaint. Report copies are distributed as requested by the author of the report. Possible receivers may be a family physician, referring physician, or any other external entity regarding any aspect of the care, treatment, access, insurability or personal aspect of medical care. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton Exception # 1 Not all letters are signed before distribution. Exception # 2 Letters are not completed for patients in the acute care setting, inpatients, day surgeries, etc. AHS - Calgary No Exceptions AHS - Rural No Exceptions Alberta Cancer Board No Exceptions Additional information: Report copies are still manually signed by the author of the letter and are not distributed until the author has signed each copy of the letter. This report is similar to the Clinic report except it is more personalized. E.C.G. Text Report The Electrocardiogram (E.C.G. Text Report is created when an E.C.G. exam is completed and the cardiologist interprets the results. The cardiologist must be an approved interpreting physician. The report communicates the diagnostic results of an E.C.G. including impressions and recommendations of the cardiologist to provide evidence based care of the patient. It contains the cardiologist s diagnosis text and code, the patient s first & last name, demographics, chart number, DOB, PHN, the date & time of the examination and generation of the report, clinic location, address and phone, and listing of copies. The report is distributed as requested by the author of the report. The distribution list may include the referring or ordering physician. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: AHS - Edmonton No Exceptions AHS - Calgary No Exceptions AHS - Rural Exception # 1 - For outpatients, copies are sent to the ordering physician, the cardiologist, and any other physician that the ordering physician requests. For inpatients, copies are sent to: the ER, the Outpatient Department, the Preadmission Clinic, the Cancer Clinic, the Nursing Ward, and to Cardiology. Alberta Cancer Board 2011 Government of Alberta 13 of 68

No Exceptions Additional information: This report is similar to the Diagnostic Imaging Text report. 2011 Government of Alberta 14 of 68

Report Process Process Flow START 1 Author dictates report into a dictation system 2 Transcriptionist accesses voice server for report 3 Transcriptionist transcribes report to a word processing application and sets version 4 5 6 7 Report complete? YES Transcriptionist saves report in electronic and/ or hard copy Transcriptionist attaches note to the report Review, verification, or signature required? YES NO NO YES 8 9 Owner reviews report Correction required? YES 10 Owner makes corrections to the report 11 Owner sends report for transcription? 12 Owner verifies and/or signs off report NO NO 13 Report messaging initiator triggers message generation 14 Messages are forwarded to the message management system 15 16 Message management system determines the recipient Recipient information valid? NO YES 17 18 Message management system delivers messages System error? YES 19 System administrator resolves error NO 20 21 Messages are unpacked into reports Owner / recipient(s) receive report END Legend: Processes presented with white boxes are in the scope of the project and related to use cases REF# UC1 and REF# UC2 2011 Government of Alberta 15 of 68

Actors ACTOR NAME Author Owner Recipient DESCRIPTION Any person who dictates the report physician, resident, nurse etc. A person with health authority to verify and sign off the report (for example, a resident can dictate the report on behalf of the surgeon, but the report has to be verified by the surgeon who performed surgery) Persons, organizations, or clinics listed as receivers by the author of the report Report Messaging Initiator A person/system responsible for initiating/triggering a message generation transcriptionist, system administrator, or system scheduled event Precondition The Author of the report decides to dictate summary information regarding an exam, surgery, hospital admission, consultation, discharge, surgery, or examination by a specialist. Narrative The Author dictates the report into a dictation system (1). The Transcriptionist accesses the voice system (2) and types the report using a word processing application (3). At this point, the report version is identified by either setting a date and time, or version/revision number (depending on the business rules defined by region or facility). Every report can be redistributed / modified several times and the version determinates each of them (3). If the report is not completed (4), the Transcriptionist attaches a note to the report stating what is missing (6). Both, complete and incomplete reports are saved in electronic and/or hard copy (5). In some regions, the report must be reviewed, verified and/or signed off by a physician or the other health authority responsible for the content of the report. If this verification is not required (7), the transcribed report is further processed (13). Otherwise, the report is reviewed (8) by the Owner of the report (a person / physician with authority to verify and sign off the report). The Owner may correct the report (9, 10) and send it back to the Transcriptionist (11, 3) for update, or the Owner may modify the report himself (12) after which the report is ready for messaging process (13). Both, verified and non-verified reports are processed by a message system (13). The process could be a scheduled event or initiated by the Report Messaging Initiator, who may be any person responsible for triggering this procedure for example, a system administrator. Messages are then forwarded (14) to a message management system responsible for the report distribution. If any system error occurs (18), the system administrator resolves the issue and restarts the process (19). Finally, messages are formatted into reports (20) and delivered to the Recipients (21). Currently, the report is distributed electronically, by auto fax, or by mail to the Recipients. The Author of the dictated report automatically receives a copy. In order for any other Recipients to receive a copy, the Author must request that a copy be sent to them. It is critical that the Author provides the complete name of the physician/recipient (16). For example, requesting a copy to be sent to the family physician is not sufficient - the Author must dictate the name and other details. The report will only be issued if the Recipient s information is accurately captured (15, 16, and 17). If reports do not have the Recipient information, they will be ignored with no feedback to the sending system. Reports without sufficient data are dismissed and excluded from the process of distribution. Only valid reports are received (21). After receiving the report, the Owner may revise/addend and/or verify the report and send it to the Transcriptionist for update and redistribution. Note that this process can occur more than once a report can be revisited several times and, consequently, can have several versions (3). 2011 Government of Alberta 16 of 68

Alternative Flow In AHS - Calgary, transcribed reports are not held for the author to review and verify before distribution. The electronic signature is not currently available in this region. Once a report is transcribed, it is wrapped up and is automatically distributed. If there are blanks in the report, an e-sticky note is attached to the report requesting the author to complete the blanks and fax it back to the transcription department. When the report is returned, a transcriptionist brings up the report, fills in the blanks and redistributes the report. If there is a correction or addendum, the author returns the report to the department where the report is revisited and redistributed. A physician may receive several versions of a report. In Calgary, the second copy of the DI Text Report is sent after report is verified regardless if any changes are made. In AHS - Edmonton, most DI reports have electronic signature availability. In AHS - Edmonton, different processes are used by each hospital site. For the electronic health record (NetCARE), all documents once typed can be viewed by individuals who have access. Therefore if the hard copy is not distributed, it is still accessible. If there is nothing wrong with the typed report (no missing information, etc), copies are distributed either by mail or by an autofax function (batch faxing). In some cases, copies are not distributed until the report is signed. Post Condition The report is filed in the Owner s/ Recipient s filing system. 2011 Government of Alberta 17 of 68

Use Cases Specification Use Case Diagram Transcription System Communicate Transcribed Report Communicate DI Text Report POS/EMR RIS Use Case: Communicate Transcribed Report (Ref# UC01) Brief Description The Communicate Transcribed Report process enables the transport of electronic copies of Transcribed Reports from the AHS Zone to a Designated Report Repository allowing the appropriate POS/EMR to pick up the transcribed reports on a predefined schedule. This process allows communication of the following report types: 1. CD (Cardiodiagnostics) 2. CN (Consultation) 3. DS (Discharge summary) 4. ED (Emergency department report) 5. HP (History and physical examination) 6. OP (Operative report) 7. PN (Procedure note) 8. PR (Progress note) 9. SP (Surgical pathology) 10. LT (Letter) Note: The above types are stored in the HL70270 Document type table HL7. 2011 Government of Alberta 18 of 68

Primary Actor: Transcription System Basic Flow of Events 1. This use case is triggered when the Transcription System generates a message batch. 2. The Transcription System sends the message batch to the Designated Report Repository. 3. The Designated Report Repository validates the batch according to the message specification document. 4. The Designated Report Repository commits the batch file to a safe storage and sends an acknowledgement to the Transcription System 5. The Designated Report Repository determines the recipients of the Transcript Report. 6. The Designated Report Repository enables the appropriate POS/EMR to pick up the transcribed reports on a predefined schedule. 7. An audit trail and archive record is created. Alternative Flows Validation process is not successful. If, at step 3 of the Basic Flow, the system determines that data is not valid: 1. The system creates an error notification to the Transcription System. 2. Reports identified as invalid are not processed further. 3. The use case resumes at step 3. Special Requirements The following message domain specifications apply to this process: MDM ORU Preconditions Reports are transcribed; report messages are generated, validated and ready to be communicated to the POS/EMR. Postconditions The POS/EMR receives the message reports successfully and reports can be obtained by the receiver. Additional Information Secondary Actors: POS/EMR. Offstage Actors: Health Records. 2011 Government of Alberta 19 of 68

Use-Case: Communicate DI Text Report (Ref# UC02) Brief Description The Communicate DI Text Report process enables the transport of diagnostic imaging text reports from the AHW Zone to a Designated Report Repository allowing the appropriate POS/EMR to pick up the reports on a predefined schedule. This process enables communication of the following report type: 1. DI (Diagnostic imaging) Note: The above type is stored in the HL70270 Document type table HL7. Primary Actors: Radiology Information System (RIS) / Transcription System Basic Flow of Events 1. This use case is triggered when the RIS / Transcription System generates a message batch. 2. The RIS or Transcription System sends the report batch file to the Designated Report Repository. 3. The Designated Report Repository validates the message according to the message specification document. 4. The Designated Report Repository commits the message to a safe storage and sends an acknowledgement back to the RIS/Transcription System 5. The Designated Report Repository determines the recipients of the diagnostic imaging text report. 6. The Designated Report Repository enables the appropriate POS/EMR to pick up the diagnostic imaging text report on a predefined schedule. 7. An audit trail and archive record is created. Alternative Flows Validation process is not successful. If, at step 3 of the Basic Flow, the system determines that data is not valid: 1. The system creates an error notification to the RIS/Transcription System. 2. Reports identified as invalid are not processed further. 3. The use case resumes at step 3. Special Requirements The following message domain specifications apply to this process: ORU Preconditions Report messages are generated, validated and ready to be communicated to the POS/EMR. Postconditions The POS/EMR receives the message reports successfully and reports can be obtained by the receiver. Additional Information Secondary Actors: POS/EMR. Offstage Actors: Health Records. 2011 Government of Alberta 20 of 68

Transaction Summary Overview This section provides detailed descriptions for ORU - Unsolicited Transmission of an Observation Message and MDM Medical Document Management message specifications. Each message specification will contain the following sections: Message Purpose This section describes what task the message performs. It also explains the circumstances in which the message should be used. Message Rules This section outlines specific business rules governing the message use and construction. Transaction Messages This section lists the HL7 message structures. For each message, the name of the message is linked to the detailed message specification in Transaction Message Details. Error Conditions This section indicates any non-general messages that may apply to the implementation of the message. Additional details on the error messages can be found in Error Conditions. MDM_T02 Message Purpose This message is used to transport electronic copies of Transcribed Reports from the AHS Zone to a Designated Report Repository allowing the appropriate EMR to pick up the transcribed reports on a predefined schedule. This message supports transmission of a new or updated document and status of the report. The medical document management message is concerned primarily with the management of documents, which are created as a result of a transcription process. These documents are created in two distinct contexts, one of which are related to an order, describing the procedures or activities associated with that order, and another, which occurs independent of the order process. The content of a document can be represented with one or more observation segments (OBX). Where headings or separations naturally exist within the text, it is preferred that each of these blocks be represented as a separate OBX record. Where systems are able to decompose the text into separate medical concepts, the most atomic level of granularity of content should be represented, ideally with each medical concept being represented in its own OBX segment. Many of these concepts can be represented as coded entities. Message Rules This message is used to transport electronic copies of following types Transcribed Reports: Value Description CD CN DS ED HP OP PN Cardiodiagnostics Consultation Discharge summary Emergency department report History and physical examination Operative report Procedure note 2011 Government of Alberta 21 of 68

PR SP Progress note Surgical pathology The following table describes the relationship between a TXA segments and an OBR segment for POS vendor translations. This translation can only occur from a MDM message to an ORU message. Seq. MDM Field Data Type Length Seq. OBR Field Data Type TXA-1 Set ID- TXA SI 4 OBR-1 Set ID - Observation Request Length TXA Field Definition SI 4 This field contains a number that uniquely identifies this transaction TXA-2 Document Type IS 2 OBR-4 Universal CE Service Identifier This field identifies the type of document (as defined in the transcription system). HL7-0270 TXA-3 Document content presentation ID 2 No Mapping Required 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. HL7-0191 TXA-4 Activity Date/Time TS 26 OBR-7 Observation Date/Time TS 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. TXA-5 Primary Activity Provider Code/Name XCN OBR- 34.1 Technician - name This field contains the name of the person identified in the document as being responsible for performing the procedure or activity. TXA-6 Origination Date/Time TS 26 OBR- 34.2 start date/time TS 26 This field contains the date and time the document was created (i.e., dictated, recorded, etc.). TXA-7 Transcription Date/Time TS 26 OBR- 35.2 Transcriptionist - Start date/time TS This field contains the date and time the input was actually transcribed. TXA-8 Not Supported This field contains the date and time the document was edited. TXA-9 Not Supported 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. TXA-10 Not Supported 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. TXA-11 Transcriptionist Code/Name XCN OBR- 35.1 Transcriptionist - name CN This field identifies the person responsible for transcribing the document. TXA-12 Unique Document Number EI 99 OBR-3 Filler Order Number EI 99 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 2011 Government of Alberta 22 of 68

Seq. MDM Field Data Type TXA-13 Parent Document Number Length Seq. OBR Field Data Type EI 99 OBR- 29.2 parent's filler order number Length TXA Field Definition EI 99 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. TXA-14 Not Supported TXA-15 Not Supported TXA-16 Unique Document File Name ST 60 OBR- 4.5 This field is the placer application s order number. This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Universal Service Identifier - alternate text ST 60 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. TXA-17 Document Completion Status ID 2 OBR- 25 Result Status ID 1 This field identifies the current completion state of the document. See chart below to map HL7-0271 status to HL7-0123 TXA-18 Not Supported ID 2 This is an optional field, which identifies the degree to which special confidentiality protection should be applied to this information. TXA-19 Not Supported TXA-20 Not Supported TXA-21 Not Supported This is an optional field which identifies a document s availability for use in patient care. If an organization 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 Canceled 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. This optional field identifies the storage status of the document. This free text field (limited to 30 characters) contains the reason for document status change. TXA- 22.1 TXA- 22.15 Authentication Person Authentication Person - Date/time Action Performed PPN TS OBR- 32.1 OBR- 32.2 Principal Result Interpreter - name Principal Result Interpreter - Start date/time CN TS This field identifies the person responsible for authenticating the document. Date the report was authenticated. TXA-23 Distributed Copies (Code and Name of Recipients) XCN OBR- 28 Result Copies To XCN This field identifies the person(s) who are to receive copies of the report. 2011 Government of Alberta 23 of 68

The following chart maps the HL7-0270 document completion status codes to the HL7-0123 result status codes. HL70270 Document completion status HL0125 Result Status Code Name Code Name AU Authenticated F Final Result PA Pre-authenticated P Preliminary CA Cancelled X Cancelled Transaction Messages Send: MDM_T02 Response: None Error Conditions NONE 2011 Government of Alberta 24 of 68

ORU_R01 Message Purpose This message is used to transport electronic copies of Diagnostic Imaging Text and Other Transcribed Reports from an AHS facility to the appropriate Physician Office System(s) (POS). The content of a document is represented within observation segments (OBX). Each OBX segment represents separate medical concepts. These concepts are represented as coded entities. Message Rules This message is used to transport electronic copies of following types Transcribed Reports: Value Description CD Cardiodiagnostics CN Consultation DS Discharge summary ED Emergency department report HP History and physical examination OP Operative report PN Procedure note PR Progress note SP Surgical pathology DI Diagnostic Imaging Transaction Messages Send: ORU_R01 Response: None Error Conditions NONE Transaction Message Detail Section Guide This section provides detailed specifications about a specific HL7 message or set of messages. It breaks down exactly where and how each piece of information will be conveyed, as well as restrictions on the content of the data including cardinality, table restrictions, length restrictions, etc. The structure uses a format adopted by the HL7 organization to document message profiles, and includes a detailed breakdown of the contents of each message into their constituent segment groups, segments, fields, components and sub-components. This specification is sufficient for an implementer to build a messaging interface. However, we strongly recommend joining the HL7 organization and obtaining a copy of the HL7 specifications. In particular, implementers should familiarize themselves with Chapter 2 of the relevant version of the HL7 standard, which provides detailed information about the structure of HL7 messages and such information as escape characters. 2011 Government of Alberta 25 of 68

Characteristics This section contains information specific to the HL7 Conformance Profile format. The Identifier is a unique id assigned to the profile and is used in registering profiles in an HL7 repository. Profile Type Indicates what kind of profile is being displayed. The Encoding Method indicates what format of HL7 messages may be used. Interactions Each document will contain one or more interactions, with each interaction identifying a message, as well as the acknowledgment responsibilities associated with that message. Message Characteristics This section discusses general properties associated with the message. Message Delimiters In constructing a message, certain special characters are used. They are the segment terminator, the field separator, the component separator, subcomponent separator, repetition separator, and escape character. The segment terminator is always a carriage return (in ASCII, a hex 0D). The other delimiters are defined in the MSH segment, with the field delimiter in the 4th character position, and the other delimiters occurring as in the field called Encoding Characters, which is the first field after the segment ID. The delimiter values used in the MSH segment are the delimiter values used throughout the entire message. In the absence of other considerations, HL7 recommends the suggested values found in the table below. Delimiter Suggested Value Encoding Character Position Usage Field Separator - Separates two adjacent data fields within a segment. It also separates the segment ID from the first data field in each segment. Component Separator Subcomponent Separator Repetition Separator ^ 1 Separates adjacent components of data fields where allowed. & 4 Separates adjacent subcomponents of data fields where allowed. If there are no subcomponents, this character may be omitted. ~ 2 Separates multiple occurrences of a field where allowed. Escape Character \ 3 Escape character for use with any field represented by an ST, TX or FT data type, or for use with the data (fourth) component of the ED data type. If no escape characters are used in a message, this character may be omitted. However, it must be present if subcomponents are used in the 2011 Government of Alberta 26 of 68

message. At any given site, the subset of the possible delimiters may be limited by negotiations between applications. This implies that the receiving applications will use the agreed upon delimiters, as they appear in the Message Header segment (MSH), to parse the message. Identifiers This section lists three types of identifiers; 1. Message Profile Identifiers, 2. Static Publish/Subscribe Identifiers 3. Dynamic Publish/Subscribe Identifiers. Some applications may reference one or more of these identifiers. The Identifier is made up of the transaction number, an indication of whether the message is being sent from Regional Health Authorities to Physician Office Systems. The version number for the transaction in turn follows this. Transaction version numbers can be interpreted as follows: The number prior to the period is the major version number. A change in the major version number denotes a significant change in the operation of the transaction, and a break in compatibility with the prior version. The number following the period is the minor version number. The minor version number is incremented each time the functionality changes in a manner that is backward compatible with the previous version. The static and dynamic Publish/Subscribe Identifiers are HL7 fields intended for applications that use a publish/subscribe mechanism for routing. Dynamic Profile Role indicates whether the profile is from the perspective of the sender or the receiver. The role indicates whether the profile defines what will be sent, or what will be accepted. For example, if an element is marked 'Not Supported' in a Sender profile, it means the value will never be sent. If it is marked 'Not Supported' in a Receiver profile, it means the value will be ignored if it is sent. Accept Acknowledgment and Application Acknowledgment corresponds to the values found in fields MSH.15 and MSH.16, respectively. They indicate what types of acknowledgments are expected on receipt of the message. Acknowledgment Mode indicates whether the messages use HL7's 'immediate' or 'deferred' acknowledgment mechanism. Message These properties identify the specific message type, trigger event and message structure used by the message. These are the same values as will be present in the MSH.9 field. Grammar This is the HL7-format grammar for the message. It lists each segment used in the message, and uses '[]' to indicate optional segments or segment groups and '{}' to indicate repeating segments or segment groups. Clicking on the segment name or brackets will automatically jump to the segment or group in question. Segment and Segment Group Definitions Each segment and segment-group used within a message will have a separate description, beginning with the short name of the segment/segment group and the long descriptive name for the segment/segment group. With each segment and segment group definition will be an indication of the Usage (Obligation) and Cardinality of the element. Usage indicates whether the segment or segment group must be present, and if so, under what circumstances. Possible usage values are: Mnemonic Description Definition R Required This means that the element must be present under all circumstances. 2011 Government of Alberta 27 of 68

Mnemonic Description Definition RE Required or Empty This means that the element must be supported (i.e. applications must be capable of sending/receiving the value), but there may be circumstances where the value is unavailable or non-applicable, in which case it does not need to be present. C Conditional This means that the element must be present under certain circumstances. The specific circumstances will be detailed in the Condition Predicate associated with the element. CE Conditional or Empty This means that the element is only allowed to be present under certain circumstances. The specific circumstances will be detailed in the Condition Predicate associated with the element. X Not Supported This means that the application does not send or it will ignore the element. It is not an error to send the element, however, the data within the element will not be processed by the application. NP Not Permitted This is similar to Not Supported, however in this case it is an error to send the element. This usage code is only used for elements that is not supported, but which if sent, could contain information that would materially alter the interpretation of elements that are supported. NOTE: Depending on the generation settings, the standard profile display format may include message elements that are defined as part of the standard HL7 message definition, but which may be not supported or not permitted by this specific use of the message. These elements are included in the message as an aid to developers who may be writing applications for multiple systems or those who wish to understand how the message corresponds to the underlying HL7 specification. Elements that are not supported or not permitted will be shown with a grey background. Alternatively, non-supported elements may be excluded from the specification altogether. HL7 NOTE: HL7 has the concept of a 'NULL' value, which is represented as two empty double-quote characters (""). Unless specifically identified for a particular element, Items marked as 'Required' or 'Conditional' will not support 'NULL' values. Other elements will treat 'NULL' values as Not Present. Cardinality indicates the minimum and maximum number of repetitions of the segment or group that are permitted. There may also be additional text providing guidelines or additional descriptive information about the use of the segment or segment group. For segment groups or segments with a usage of 'C' (conditional) or 'CE' (conditional or empty), the specific condition predicate under which the element is allowed or required will be specified. Segment Table The segment table provides a detailed breakdown of the fields, components and datatypes that are used within a segment in a given context. Note that the definitions of the contents and behaviors of the components of a particular datatype may differ from those defined by HL7. The definition of a datatype may restrict the generic behavior. For example, a component that is generically defined as RE (optional), might be defined within a particular field as Required or Not Permitted. NOTE: Sometimes the same segment may be used in multiple locations within a message. Each location where the segment is used will have its own table, and the segment definition may vary from location to location within the message due to different data requirements. Seq. (Sequence) This indicates the position of the message element within the message. All fields within the segment are assigned a number, starting with 1. If components or sub-components are listed, the sequence number of 2011 Government of Alberta 28 of 68

the parent field will identify them, followed by a period and then the sequence number of the component. E.g. 3.1.4 would refer to the fourth sub-component of the first component of the third field. If there are additional details available for the element described by the row, the sequence number will be blue, indicating that it is a hyperlink that can be clicked on to link to the descriptive information below the table. Name This is the descriptive name for the field, datatype component or sub-component. The hierarchy of elements can be seen by the indentation level of the descriptive name. Type This indicates the datatype associated with the field, component or sub-component. 'CM' datatypes have extensions to their names to differentiate them from other CM datatypes with different content. The extensions were defined in HL7 2.5, but are effective for all HL7 versions. The more detailed names have no impact on the content of the actual message and are included for descriptive purposes only. Table For coded values, this indicates the table from which the code values must be drawn. In some cases multiple tables may be specified. For complex code datatypes, such as CE, CNE and CWE, the table will be identified at a level above the datatype components because the datatypes allow for multiple codes to be transmitted, and only one of the codes needs to be drawn from the specified table(s). Some tables may be included as part of the specification. If the table is present, the table number will be highlighted blue to indicate that a hyperlink to the table definition is available. Len. (Length) This indicates the maximum length supported for the element. If a message is sent with contents exceeding one of the maximum lengths, an error message will be raised, either as part of an acknowledgment message (where one exists), or within the receiving application in the absence of an acknowledgment. HL7 has traditionally assigned maximum lengths to complex datatypes indicating the maximum length for a series of datatype components. However, wherever possible, lengths have also been provided for the individual message components. Where the over-all length is a simple sum of the components, no higher-level length is specified. For repeating elements, the maximum length applies to each individual repetition, not to the sum of the repetitions. Optionality This defines whether the field, component or sub-component must be present, and if so, under what circumstances. The possible usage values are defined above in the table under 'Segment and Segment Group Definitions'. For elements with a usage of 'C' (conditional) or 'CE' (conditional or empty), the Usage code will be blue, indicating that there is a hyperlink to the section below the table where the predicate explaining the conditions under which the element is allowed or required are specified. Card. (Cardinality) This indicates the number of times the element may be present. The first number indicates the minimum number of times the element may be present, the second number the maximum number of times. A '*' indicates that there is no limitation on the number of repetitions. Contents This section contains several types of information. If the content of the message element is fixed (i.e. it is only permitted to be a single specific value in every occurrence of the element), then that value will be displayed in bold. If there is no 'fixed' value, an example value will generally be provided. In some cases the example value will be too large to fit in the space available. In that case, a string saying 'example' will be displayed that acts as a hyperlink to the example in the section following the segment table. 2011 Government of Alberta 29 of 68

Segment Element Details Following each segment table will be a list of details for those segment elements that require additional description. Each element will be identified with the same sequence and name as found in the segment table. It will also identify the datatype. The potential details provided include: General implementation notes and descriptions, Condition Predicates for elements with a usage of 'C' or 'CE', external references that might provide additional information about the element, and Example values. In some cases, there will only be a link to the datatype. This indicates that there are additional notes, Rules or references associated with the datatype that can be found in Section E. General Notes Throughout this specification, we have tried to be consistent with the HL7 specification, both through the segments and fields we use, and the data we pass using them. However, there are instances when we have found it necessary to make small moves away from the standard. For example, we might make a field repeating where the specification calls for a single occurrence. Alternatively we might change an ID coded value field into a CE field. Whenever we make such changes, they will be clearly identified in this document, preceded by the text 'HL7 Note: 2011 Government of Alberta 30 of 68

MDM - Transcribed Reports Delivery Message Specification The following represents the DITR HL7 message structure that enables the delivery of transcribed reports (excluding diagnostic imaging text reports) to physician office systems. MDM is used for transcription and Alberta Cancer Board and AHS - Calgary for transcribed reports. All stakeholders creating DI text reports utilize the ORU specification for messaging. All health authorities in the province engaging in the electronic delivery of transcribed reports to physician offices will develop their interfaces according to this specification. Parameters Identifiers Static Profile ID: {ConfSig(1) Health Information Standards Committee for Alberta(1) 2.3(5) static-profile(1) MDM(15) T02(144) null(0) (1) 0.5(1) Sender(1)} Dynamic Profile ID: {ConfSig(1) Health Information Standards Committee for Alberta(1) 2.3(5) dynamic-profile(2) AccNE_AppAL(2) immed_mode_ack(2)} Conformance Role: Conformance Type: Accept Acknowledgement: Application: Acknowledgement: Acknowledgement Mode: Sender Implementable NE AL Immediate Message HL7 Version: 2.3 Message Type: MDM Trigger Event: T02 Message Structure: MDM_T02 Encoding Method ER7 2011 Government of Alberta 31 of 68

Message Grammar MSH EVN PID PV1 TXA { [OBX] } MSH Message Header Segment (Usage: Required Cardinality: 1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Field Separator ST 1 R 1..1 2 Encoding Characters ST 4 R 1..1 ^~\& 3 Sending Application HD 15 RE 0..1 3.1 namespace ID IS 15 R 1..1 4 Sending Facility HD 20 RE 0..1 4.1 namespace ID IS 20 R 1..1 5 Receiving Application HD 30 RE 0..1 5.1 namespace ID IS 30 R 1..1 6 Receiving Facility HD 30 RE 0..1 6.1 namespace ID IS 30 R 1..1 6.2 universal ID ST 3 RE 0..1 6.3 universal ID type ID HL70301 3 RE 0..1 7 Date / Time of Message TS 26 RE 0..1 7.1 Date/Time NM 26 R 1..1 9 Message Type CM_MSG 7 R 1..1 9.1 message type ID HL70076 3 R 1..1 MDM 9.2 trigger event ID HL70003 3 R 1..1 T02 10 Message Control ID ST 20 R 1..1 11 Processing ID PT 3 R 1..1 11.1 processing ID ST HL70103 3 R 1..1 P 12 Version ID ID HL70104 8 R 1..1 2.3 3.1. namespace ID Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 4.1. namespace ID Where possible the Delivery Site Registry (DSR) ID or DSR mnemonic should be used. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 5.1. namespace ID Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 6.1. namespace ID Where possible the Delivery Site Registry (DSR) ID or DSR mnemonic should be used. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 7.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 9.2. trigger event T02 - Original document notification and content 2011 Government of Alberta 32 of 68

EVN Event Type (Usage: Required Cardinality: 1..1) The EVN segment is used to communicate necessary trigger event information to receiving applications. Valid event types for all chapters are contained in HL7 table 0003 - Event Type. Seq. Name Type Table Len. Opt. Card. Contents 1 Event Type Code ID HL70003 3 R 1..1 2 Recorded Date/Time TS 26 R 1..1 2.1 Date/Time NM 26 R 1..1 3 Date/Time Planned Event TS 26 RE 0..1 3.1 Date/Time NM 26 R 1..1 4 Event Reason Code ID HL70062 3 RE 0..1 5 Operator ID CN HL70188 60 RE 0..1 5.1 ID number (ST) ST 15 RE 0..1 5.2 family name ST 50 RE 0..1 5.3 given name ST 50 RE 0..1 5.4 middle initial or name ST 50 RE 0..1 6 Event Occurred TS 26 RE 0..1 6.1 Date/Time NM 26 R 1..1 1. Event Type Code This field has been retained for backward compatibility only. 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. 2. Recorded Date/Time This field contains the date/time that the event was recorded. Most systems will default to the system date/time when the transaction was entered, but they should also permit an override. 2.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 3. Date/Time Planned Event This field contains the date/time that the event is planned. 3.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 4. Event Reason Code This field contains the reason for this event (e.g., patient request, physician order, census management, etc.). Suggested values are contained in the user-defined table 0062. 5. Operator ID This field identifies the individual responsible for triggering the event. Suggested values are contained in user-defined table 0188 - Operator ID 6. Event Occurred This field contains the date/time that the event actually occurred. For example, on a transfer (A02 (transfer a patient), this field could contain the date/time the patient was actually transferred. On a cancellation event, this field should contain the date/time that the event being canceled occurred. 6.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZZ] 2011 Government of Alberta 33 of 68

PID Patient Identification (Usage: Required Cardinality: 1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient ID SI 4 RE 0..1 2 Patient ID ( ID) CX 16 RE 0..1 2.1 ID ST 16 R 1..1 2.4 assigning authority HD 3 R 1..1 2.4.1 namespace ID IS 99-0001 2 R 1..1 AB 3 Patient ID (Internal ID) CX 20 RE 0..* 3.1 ID ST 15 R 1..1 4 Alternate Patient ID CX 12 RE 0..1 4.1 ID ST 15 R 1..1 4.4 assigning authority HD 3 R 1..1 4.4.1 namespace ID IS 99-0001 3 R 1..1 Ex. BC 5 Patient Name XPN 150 R 1..1 5.1 family name ST 50 R 1..1 5.2 given name ST 50 RE 0..1 5.3 middle initial or name ST 50 RE 0..1 7 Date of Birth TS 26 R 1..1 7.1 Date/Time NM 26 R 1..1 8 Sex IS HL70001 1 R 1..1 13 Phone Number - Home TN 40 RE 0..* 18 Patient Account Number CX 20 RE 0..1 18.1 ID ST 12 R 1..1 29 Patient Death Date and Time TS 26 RE 0..1 29.1 Date/Time NM 26 R 1..1 30 Patient Death Indicator ID HL70136 1 RE 0..1 2. Patient ID ( ID) AHW identifier 2.1. ID Unique Lifetime Identifier / Personal Health Number 2.4.1. namespace ID The mnemonic of the province of Alberta. 3. Patient ID (Internal ID) This field may contain the facility's patient identifier. 4. Alternate Patient ID This field may contain the community patient identifier or out-of-province identifier. 4.4.1. namespace ID The mnemonic of the province 5.1. family name This component contains the family name alone. 5.2. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 5.3. middle initial or name This component may contain the middle initial or middle name only. 2011 Government of Alberta 34 of 68

7.1. Date/Time YYYYMMDD 13. Phone Number - Home If available, this field will contain the patient's home phone number. 18. Patient Account Number This field contains the Patient Account Number assigned by accounting to which all charges, payments, etc., are recorded. It is used to identify the patient's account. 29.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 2011 Government of Alberta 35 of 68

PV1 Patient Visit (Usage: Required Cardinality: 1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient Visit SI 4 RE 0..1 2 Patient Class ID HL70004 1 R 1..1 3 Assigned Patient Location PL 30 RE 0..1 3.1 point of care (IS) IS 20 R 1..1 3.4 facility (HD) HD 10 RE 0..1 3.4.1 namespace ID IS 20 R 1..1 7 Attending Doctor XCN 60 RE 0..1 7.1 ID number (ST) ST 15 R 1..1 7.2 family name ST 50 R 1..1 7.3 given name ST 50 RE 0..1 7.4 middle initial or name ST 50 RE 0..1 7.8 source table ID 30 R 1..1 8 Referring Doctor XCN 60 RE 0..1 8.1 ID number (ST) ST 15 R 1..1 8.2 family name ST 50 R 1..1 8.3 given name ST 50 RE 0..1 8.4 middle initial or name ST 50 RE 0..1 8.8 source table ID 30 R 1..1 9 Consulting Doctor XCN 60 RE 0..* 9.1 ID number (ST) ST 15 R 1..1 9.2 family name ST 50 R 1..1 9.3 given name ST 50 RE 0..1 9.4 middle initial or name ST 50 RE 0..1 9.8 source table ID 30 R 1..1 17 Admitting Doctor XCN 60 RE 0..1 17.1 ID number (ST) ST 15 R 1..1 17.2 family name ST 50 R 1..1 17.3 given name ST 50 RE 0..1 17.4 middle initial or name ST 50 RE 0..1 17.8 source table ID 30 R 1..1 19 Visit Number CX 3 RE 0..1 19.1 ID ST 30 R 1..1 19.4 assigning authority HD 3 R 1..1 19.4.1 namespace ID IS 99-0001 2 R 1..1 44 Admit Date/Time TS 3 RE 0..1 44.1 Date/Time NM 3 R 1..1 45 Discharge Date/Time TS 3 RE 0..1 45.1 Date/Time NM 3 R 1..1 3.1. point of care (IS) This field contains the defined patient location at the time of the encounter. Note: Table values should be obtained from the AHS Zone. 3.4.1. namespace ID Where possible the Delivery Site Registry (DSR) ID or DSR mnemonic should be used. 7. Attending Doctor 2011 Government of Alberta 36 of 68

This field may contain the defined Provider Id and name of the attending doctor if these elements are available. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 7.2. family name This component contains the family name alone. 7.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 7.4. middle initial or name This component may contain the middle initial or middle name only. 7.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 8. Referring Doctor This field may contain the defined Provider Id and name of the referring doctor if these elements are available. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 8.2. family name This component contains the family name alone. 8.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 8.4. middle initial or name This component may contain the middle initial or middle name only. 8.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 9. Consulting Doctor This field may contain the defined Provider Id and name of the consulting doctor if these elements are available. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 9.2. family name This component contains the family name alone. 9.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 9.4. middle initial or name This component may contain the middle initial or middle name only. 9.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. 17. Admitting Doctor This field may contain the defined Provider Id and name of the admitting doctor if these elements are available. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 17.2. family name This component contains the family name alone. 2011 Government of Alberta 37 of 68

17.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 17.4. middle initial or name This component may contain the middle initial or middle name only. 17.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 44. Admit Date/Time This field contains the admit date/time. 44.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 45. Discharge Date/Time This field contains the discharge date/time. 45.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 2011 Government of Alberta 38 of 68

TXA Document Notification Segment (Usage: Required Cardinality: 1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID- TXA SI 4 RE 0..1 2 Document Type IS HL70270 2 R 1..1 3 Document Content ID HL70191 2 RE 0..1 Presentation 4 Activity Date/Time TS 26 R 1..1 4.1 Date/Time NM 26 R 1..1 5 Primary Activity Provider XCN 60 R 1..1 Code/Name 5.1 ID number (ST) ST 15 R 1..1 5.2 family name ST 50 R 1..1 5.3 given name ST 50 RE 0..1 5.4 middle initial or name ST 50 RE 0..1 5.8 source table ID 3 R 1..1 6 Origination Date/Time TS 26 RE 0..1 6.1 Date/Time NM 26 R 1..1 7 Transcription Date/Time TS 26 CE 0..1 7.1 Date/Time NM 26 R 1..1 11 Transcriptionist Code/Name XCN 48 RE 0..1 11.1 ID number (ST) ST 15 R 1..1 11.2 family name ST 50 R 1..1 11.3 given name ST 50 RE 0..1 11.4 middle initial or name ST 50 RE 0..1 11.8 source table ID 3 R 1..1 12 Unique Document Number EI 99 R 1..1 12.1 entity identifier ST 55 R 1..1 12.2 namespace ID IS 44 RE 0..1 13 Parent Document Number EI 30 RE 0..1 13.1 entity identifier ST 55 R 1..1 13.2 namespace ID IS 44 RE 0..1 16 Unique Document File ST 60 RE 0..1 Name 17 Document Completion ID HL70271 2 R 1..1 Status 22 Authentication Person, PPN 60 CE 0..* Time Stamp 22.1 ID number ST 15 R 1..1 22.2 family name ST 50 R 1..1 22.3 given name ST 50 RE 0..1 22.4 middle initial or name ST 50 RE 0..1 22.8 source table ID 3 R 1..1 22.15 Date/Time Action TS 3 RE 0..1 Performed 22.15.1 Date/Time NM 26 R 1..1 23 Distributed Copies (Code XCN 60 RE 0..* and Name of Recipients) 23.1 ID number (ST) ST 15 R 1..1 2011 Government of Alberta 39 of 68

23.2 family name ST 50 R 1..1 23.3 given name ST 50 RE 0..1 23.4 middle initial or name ST 50 RE 0..1 23.8 source table ID 3 R 1..1 1. Set ID- TXA This field contains the number that identifies this transaction. 2. Document Type This field identifies the type of document. 3. Document Content Presentation This field identifies the method by which this document was obtained or originated. 4. Activity Date/Time Contains the key clinical date, which could be the procedure date, discharge date or dictation date. 4.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 5. Primary Activity Provider Code/Name This field contains the name of the person identified in the document as being responsible for performing the procedure or activity. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 5.1. ID number (ST) This field may contain the defined Provider Id and name of the Primary Activity Provider if these elements are available. 5.2. family name This component contains the family name alone. 5.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 5.4. middle initial or name This component may contain the middle initial or middle name only. 5.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 6.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 7.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 11. Transcriptionist Code/Name This field identifies the person transcribing the document. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 11.1. ID number (ST) This field may contain the defined Provider Id and name of the Transcriptionist if these elements are available. 11.2. family name This component contains the family name alone. 11.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 2011 Government of Alberta 40 of 68

11.4. middle initial or name This component may contain the middle initial or middle name only. 11.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 22. Authentication Person, Time Stamp This field may contain the defined Provider Id and name of the Authentication Person if these elements are available. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. Condition Predicate: This field is valued when the status of TXA-17-document completion status is equal to AU (authenticated) or LA (legally authenticated). 22.1. ID number This field may contain the defined Provider Id and name of the Authentication Person if these elements are available. 22.2. family name This component contains the family name alone. 22.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 22.4. middle initial or name This component may contain the middle initial or middle name only. 22.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 22.15.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 23. Distributed Copies (Code and Name of Recipients) This field identifies the persons who received a copy of this document. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 23.1. ID number (ST) This field may contain the defined Provider Id and name of the person(s) who receive a copy of this report, if these elements are available. 23.2. family name This component contains the family name alone. 23.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 23.4. middle initial or name This component may contain the middle initial or middle name only. 23.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 2011 Government of Alberta 41 of 68

< Report Content > Segment Group (Usage: Required Cardinality:1..*) OBX - Observation segment (Usage: Cardinality: 0..1 ) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - OBX SI 4 RE 0..1 2 Value Type ID HL70125 2 R 1..1 3 Observation Identifier CE 590 RE 0..1 3.1 identifier ST 15 R 1..1 3.2 text ST 60 R 1..1 3.3 name of coding system ST HL70396 10 RE 0..1 3.4 alternate identifier ST 15 RE 0..1 3.5 alternate text ST 60 RE 0..1 3.6 name of alternate coding ST 10 RE 0..1 system 5 Observation Value VARIES 0 R 1..1 16 Responsible Observer XCN 80 RE 0..1 16.1 ID number (ST) ST 15 R 1..1 16.2 family name ST 50 R 1..1 16.3 given name ST 50 RE 0..1 16.4 middle initial or name ST 50 RE 0..1 16.8 source table ID 3 R 1..1 2. Value Type This field contains the format of the observation value in OBX-5. This field may contain a value of "ED" encapsulated data type OBX-5 Observation Value may contain a PDF file. 3. Observation Identifier This component represents the type of report i.e. Operative Report, Progress Note, etc. and if required the subsection within the report i.e. Diagnosis and Treatment, Reason for Referral, Physical Examination, Plan. 5. Observation Value This field contains the diagnostic image text or transcribed report. OBX-2 (Value Type) contains the data type for this field according to which observation field is formatted. 16. Responsible Observer This field identifies the person who observed portions of the exam or procedure. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 16.1. ID number (ST) This field may contain the defined Provider Id and name of the responsible observer if these elements are available. 16.2. family name This component contains the family name alone. 16.3. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "First" or "First Second". 16.4. middle initial or name 2011 Government of Alberta 42 of 68

This component may contain the middle initial or middle name only. 16.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. <End Report Content> 2011 Government of Alberta 43 of 68

ORU Observation Result / Unsolicited The following represents the DITR HL7 message structure that enables the delivery of diagnostic imaging text reports to physician office systems. All stakeholders creating DI text reports utilize the ORU specification for messaging. Parameters Identifiers Static Profile ID: {ConfSig(1) Health Information Standards Committee for Alberta(1) 2.3(5) static-profile(1) ORU(24) R01(104) null(0) (1) 0.5(1) Sender(1)} Dynamic Profile ID: {ConfSig(1) Health Information Standards Committee for Alberta(1) 2.3(5) dynamic-profile(2) AccNE_AppAL(2) defer_mode_ack(1)} Conformance Role: Conformance Type: Accept Acknowledgement: Application: Acknowledgement: Acknowledgement Mode: Sender Implementable NE AL Deferred Message HL7 Version: 2.3 Message Type: ORU Trigger Event: R01 Message Structure: ORU_R01 Encoding Method ER7 2011 Government of Alberta 44 of 68

Message Grammar MSH PID PV1 { [ORC] OBR { [OBX] } } MSH Message Header Segment (Usage: Required Cardinality: 1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Field Separator ST 1 R 1..1 2 Encoding Characters ST 4 R 1..1 ^~\& 3 Sending Application HD 15 RE 0..1 3.1 namespace ID IS 15 R 1..1 4 Sending Facility HD 20 RE 0..1 4.1 namespace ID IS 20 R 1..1 5 Receiving Application HD 30 RE 0..1 5.1 namespace ID IS 30 R 1..1 6 Receiving Facility HD 30 RE 0..1 6.1 namespace ID IS 30 R 1..1 6.2 universal ID ST 3 RE 0..1 6.3 universal ID type ID HL70301 3 RE 0..1 7 Date / Time of Message TS 26 RE 0..1 7.1 Date/Time NM 26 R 1..1 9 Message Type CM_MSG 7 R 1..1 9.1 message type ID HL70076 3 R 1..1 ORU 9.2 trigger event ID HL70003 3 R 1..1 R01 10 Message Control ID ST 20 R 1..1 11 Processing ID PT 3 R 1..1 11.1 processing ID ST HL70103 3 R 1..1 P 12 Version ID ID HL70104 8 R 1..1 2.3 1. Field Separator 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. HISCA Compliant 2. Encoding Characters This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. 3. Sending Application 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. AHS Zone defined (see 3.1 namespace ID) 3.1. namespace ID Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 4. Sending Facility This field identifies the sending application among multiple identical instances of the application running on behalf of different organizations. AHS Zone defined (see 4.1 namespace ID) 2011 Government of Alberta 45 of 68

4.1. namespace ID Where possible the Delivery Site Registry (DSR) ID or DSR mnemonic should be used. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 5. Receiving Application This field uniquely identifies the receiving 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. AHS Zone defined (see 5.1 namespace ID) 5.1. namespace ID Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 6. Receiving Facility This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. AHS Zone defined (see 6.1 namespace ID) 6.1. namespace ID Where possible the Delivery Site Registry (DSR) ID or DSR mnemonic should be used. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 7. Date / Time of Message This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone. 7.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 9. Message Type This field contains the message type, trigger event. 10. Message Control ID This field contains a number or other identifier that uniquely identifies the message. 2011 Government of Alberta 46 of 68

PID Patient Identification (Usage: Required Cardinality:1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient ID SI 4 RE 0..1 2 Patient ID ( ID) CX 16 RE 0..1 2.1 ID ST 16 R 1..1 2.4 assigning authority HD 3 R 1..1 2.4.1 namespace ID IS 99-0001 2 R 1..1 AB 3 Patient ID (Internal ID) CX 20 RE 0..* 3.1 ID ST 15 R 1..1 4 Alternate Patient ID CX 15 RE 0..1 4.1 ID ST 15 R 1..1 4.4 assigning authority HD 3 RE 0..1 4.4.1 namespace ID IS 99-0001 3 R 1..1 5 Patient Name XPN 150 R 1..1 5.1 family name ST 50 R 1..1 5.2 given name ST 50 RE 0..1 5.3 middle initial or name ST 50 RE 0..1 7 Date of Birth TS 26 R 1..1 7.1 Date/Time NM 26 R 1..1 8 Sex IS HL70001 1 R 1..1 13 Phone Number - Home TN 40 RE 0..* 18 Patient Account Number CX 20 RE 0..1 18.1 ID ST 12 R 1..1 29 Patient Death Date and Time TS 26 RE 0..1 29.1 Date/Time NM 26 R 1..1 30 Patient Death Indicator ID HL70136 1 RE 0..1 1. Set ID - Patient ID This field contains the number that identifies this transaction. 2. Patient ID ( ID) AHW assigned identifier 2.1. ID Unique Lifetime Identifier / Personal Health Number 3. Patient ID (Internal ID) This field may contain the facility's patient identifier. 4. Alternate Patient ID This field may contain the community patient identifier or out-of-province identifier. 4.4. assigning authority The mnemonic of the province 4.4.1. namespace ID The mnemonic of the province responsible for assigning the alternate patient identifier. 5.1. family name This component contains the family name alone. 5.2. given name This component may either be the given name alone (with other names in subsequent components) or the unformatted name. e.g. "Mary" or "Mary Ellen". 2011 Government of Alberta 47 of 68

5.3. middle initial or name This component may contain the middle initial or middle name only. 7.1. Date/Time YYYYMMDD 8. Sex Gender of patient. 18. Patient Account Number This field contains the Patient Account Number assigned by accounting to which all charges, payments, etc., are recorded. It is used to identify the patient's account. 29.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 2011 Government of Alberta 48 of 68

PV1 Patient Visit (Usage: Required Cardinality:1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient Visit SI 4 RE 0..1 2 Patient Class ID HL70004 1 R 1..1 3 Assigned Patient Location PL 30 RE 0..1 3.1 point of care (IS) IS 20 R 1..1 3.4 facility (HD) HD 0 RE 0..1 3.4.1 namespace ID IS 20 R 1..1 7 Attending Doctor XCN 60 RE 0..1 7.1 ID number (ST) ST 15 R 1..1 7.2 family name ST 50 R 1..1 7.3 given name ST 50 RE 0..1 7.4 middle initial or name ST 50 RE 0..1 7.8 source table ID 30 R 1..1 8 Referring Doctor XCN 60 RE 0..1 8.1 ID number (ST) ST 15 R 1..1 8.2 family name ST 50 R 1..1 8.3 given name ST 50 RE 0..1 8.4 middle initial or name ST 50 RE 0..1 8.8 source table ID 30 R 1..1 9 Consulting Doctor XCN 60 RE 0..* 9.1 ID number (ST) ST 15 R 1..1 9.2 family name ST 50 R 1..1 9.3 given name ST 50 RE 0..1 9.4 middle initial or name ST 50 RE 0..1 9.8 source table ID 30 R 1..1 17 Admitting Doctor XCN 60 RE 0..1 17.1 ID number (ST) ST 15 R 1..1 17.2 family name ST 50 R 1..1 17.3 given name ST 50 RE 0..1 17.4 middle initial or name ST 50 RE 0..1 17.8 source table ID 30 R 1..1 19 Visit Number CX 3 RE 0..1 19.1 ID ST 30 R 1..1 19.4 assigning authority HD 3 R 1..1 19.4.1 namespace ID IS 99-0001 2 R 1..1 44 Admit Date/Time TS 3 RE 0..1 44.1 Date/Time NM 3 R 1..1 45 Discharge Date/Time TS 3 RE 0..1 45.1 Date/Time NM 3 R 1..1 3.1. point of care (IS) This field contains the defined patient location at the time of the encounter. Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 3.4.1. namespace ID Where possible the Delivery Site Registry (DSR) ID or DSR mnemonic should be used. 7. Attending Doctor 2011 Government of Alberta 49 of 68

This field may contain the defined Provider ID and name of the attending doctor if these elements are available. 7.2. family name This component may either be the family name alone (with other names in subsequent components) or the unformatted name. e.g. "First Second Last" or "Last, First Second". 7.8. source table This field contains the identification of the organization responsible for assigning the attending doctor identifier. Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 8. Referring Doctor This field may contain the defined Provider ID and name of the referring doctor if these elements are available. 8.2. family name This component may either be the family name alone (with other names in subsequent components) or the unformatted name. e.g. "First Second Last" or "Last, First Second". 8.8. source table This field contains the identification of the organization responsible for assigning the referring doctor identifier. Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 9. Consulting Doctor This field may contain the defined Provider ID and name of the consulting doctor if these elements are available. 9.2. family name This component may either be the family name alone (with other names in subsequent components) or the unformatted name. e.g. "First Second Last" or "Last, First Second". 9.8. source table This field contains the identification of the organization responsible for assigning the consulting doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 17. Admitting Doctor This field may contain the defined Provider ID and name of the admitting doctor if these elements are available. 17.2. family name This component may either be the family name alone (with other names in subsequent components) or the unformatted name. e.g. "First Second Last" or "Last, First Second". 17.8. source table This field contains the identification of the organization responsible for assigning the admitting doctor identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 44. Admit Date/Time This field contains the admit date/time. 44.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 45.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 2011 Government of Alberta 50 of 68

<Segment Group> (Usage: Required Cardinality: 1..*) ORC Common Order Segment (Usage: Cardinality: 0..1 ) The Common Order segment is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message. ORC is mandatory in Order Acknowledgement (ORR) messages if an order detail segment is present but is not required otherwise. Seq. Name Type Table Len. Opt. Card. Contents 1 Order Control ID HL70119 2 R 1..1 1. Order Control The Order Control identifier field determines the function of the order segment. The field may be considered as the "trigger event" identifier for orders. The codes fall into 3 categories: a) event request, b) event acknowledgement and c) event notification 2011 Government of Alberta 51 of 68

OBR Observation Request Segment (Usage: Required Cardinality: 1..1) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Observation SI 4 RE 0..1 Request 3 Filler Order Number EI 22 RE 0..1 3.1 entity identifier ST 55 R 1..1 3.2 namespace ID IS 44 R 1..1 4 Universal Service Identifier CE HL70270 200 R 1..1 4.1 identifier ST 15 R 1..1 4.2 text ST 60 R 1..1 4.3 name of coding system ST HL70396 10 R 1..1 4.4 alternate identifier ST 15 RE 0..1 4.5 alternate text ST 60 RE 0..1 4.6 name of alternate coding ST 10 RE 0..1 system 7 Observation Date/Time TS 26 R 1..1 7.1 Date/Time NM 26 R 1..1 16 Ordering Provider XCN 120 RE 0..* 16.1 ID number (ST) ST 15 R 1..1 16.2 family name ST 50 R 1..1 16.3 given name ST 50 RE 0..1 16.4 middle initial or name ST 50 RE 0..1 20 Filler Field 1 ST HL70272 15 RE 0..1 21 Filler Field 2 ST HL70273 15 RE 0..1 25 Result Status ID HL70123 1 R 1..1 28 Result Copies To XCN 150 RE 0..* 28.1 ID number (ST) ST 15 R 1..1 28.2 family name ST 50 R 1..1 28.3 given name ST 50 RE 0..1 28.4 middle initial or name ST 50 RE 0..1 28.9 assigning authority HD 30 R 1..1 28.9.1 namespace ID IS 30 R 1..1 29 Parent Number CM_EIP 150 RE 0..1 29.2 parent's filler order EI 3 RE 0..1 number 29.2.1 entity identifier ST 55 R 1..1 29.2.2 namespace ID IS 44 R 1..1 32 Principal Result Interpreter CM_NDL 200 RE 0..1 32.1 name CN 3 R 1..1 32.1.1 ID number (ST) ST 15 R 1..1 32.1.2 family name ST 50 R 1..1 32.1.3 given name ST 50 RE 0..1 32.1.4 middle initial or name ST 50 RE 0..1 32.1.8 source table ID 3 R 1..1 32.2 start date/time TS 3 RE 0..1 32.2.1 Date/Time NM 26 R 1..1 34 Technician CM_NDL 200 RE 0..* 2011 Government of Alberta 52 of 68

34.1 name CN 3 R 1..1 34.1.1 ID number (ST) ST 15 R 1..1 34.1.2 family name ST 50 RE 0..1 34.1.3 given name ST 50 RE 0..1 34.1.4 middle initial or name ST 50 RE 0..1 34.1.8 source table ID 30 R 1..1 34.2 start date/time TS 3 RE 0..1 34.2.1 Date/Time NM 26 R 1..1 35 Transcriptionist CM_NDL 200 RE 0..* 35.1 name CN 3 R 1..1 35.1.1 ID number (ST) ST 15 R 1..1 35.1.2 family name ST 50 R 1..1 35.1.3 given name ST 50 RE 0..1 35.1.4 middle initial or name ST 50 RE 0..1 35.1.8 source table ID 30 R 1..1 35.2 start date/time TS 3 RE 0..1 35.2.1 Date/Time NM 26 R 1..1 3. Filler Order Number Unique report identifier. The combination of the "entity identifier" and the "namespace ID" ensure uniqueness within the POSP. 4. Universal Service Identifier Identifies the type of report being delivered. See HL7-0270 for report types. 7. Observation Date/Time Contains the key clinical date, which could be the procedure date, discharge date or dictation date. 7.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 16. Ordering Provider This field identifies the provider who ordered the test. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 20. Filler Field 1 This field is definable for any use by the sending application. 21. Filler Field 2 This field is definable for any use by the sending application. 25. Result Status Result Status for implementation of Diagnostic Imaging Text and Transcribed Reports represents the document status. 28. Result Copies To This is repeatable field. It is used to provide a list of providers who are to receive copies of the report. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 28.9. assigning authority This field contains the identification of the organization responsible for assigning the copy to identifier(s). Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 29. Parent Number Filler Order Number of parent report. 2011 Government of Alberta 53 of 68

29.2. parent's filler order number The combination of the "entity identifier" and the "namespace ID" ensure uniqueness within the POSP. 32. Principal Result Interpreter This field may contain the defined Provider ID and name of the result interpreter/authenticator if these elements are available. Parsing Resolution: For OBR 32, 34 and 35, EMR systems should confirm if an "&" is present as an encoding character. If so, parse the message according to the HL7 standard. If the "&" is not present, assume the family name, given name, middle initial or name, and source table are separated by the component separator "^". 32.1.8. source table This field contains the identification of the organization responsible for assigning the principal result interpreter identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 32.2.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 34. Technician This field may contain the defined Provider ID and name of the technician/report dictator if these elements are available. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. Parsing Resolution: For OBR 32, 34 and 35, EMR systems should confirm if an "&" is present as an encoding character. If so, parse the message according to the HL7 standard. If the "&" is not present, assume the family name, given name, middle initial or name, and source table are separated by the component separator "^". 34.1.8. source table This field contains the identification of the organization responsible for assigning the transcriptionist identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 34.2. start date/time Report dictate date. 34.2.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 35. Transcriptionist This field may contain the defined Provider ID and name of the transcriptionist if these elements are available. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. Parsing Resolution: For OBR 32, 34 and 35, EMR systems should confirm if an "&" is present as an encoding character. If so, parse the message according to the HL7 standard. If the "&" is not present, assume the family name, given name, middle initial or name, and source table are separated by the component separator "^". 35.1.8. source table This field contains the identification of the organization responsible for assigning the transcriptionist identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. 35.2.1. Date/Time YYYYMMDD[HHMM[SS[.SSSS]]][+-ZZZ Z] 2011 Government of Alberta 54 of 68

<Report Content> Segment Group (Usage: Required Cardinality: 1..*) OBX Observation Segment (Usage: Cardinality: 0..1 ) Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - OBX SI 4 RE 0..1 2 Value Type ID HL70125 2 R 1..1 3 Observation Identifier CE 590 R 1..1 3.1 identifier ST 15 R 1..1 3.2 text ST 60 R 1..1 3.3 name of coding system ST HL70396 10 RE 0..1 3.4 alternate identifier ST 15 RE 0..1 3.5 alternate text ST 60 RE 0..1 3.6 name of alternate coding ST 10 RE 0..1 system 5 Observation Value VARIES 65536 R 1..1 16 Responsible Observer XCN 80 RE 0..1 16.1 ID number (ST) ST 15 R 1..1 16.2 family name ST 50 R 1..1 16.3 given name ST 50 RE 0..1 16.4 middle initial or name ST 50 RE 0..1 16.8 source table ID 30 R 1..1 1. Set ID - OBX This component represents the order of the sections within a report. For the first occurrence of the segment, the segment number shall be one, for the second occurrence, the sequence number shall be two, etc. 2. Value Type This field contains the format of the observation value in OBX-5. For Diagnostic Imaging Text and Transcribed Report this field cannot contain the value "NM". 3. Observation Identifier This component represents the type of report i.e. Operative Report, Progress Note, etc. and if required the subsection within the report i.e. Diagnosis and Treatment, Reason for Referral, Physical Examination, Plan. 5. Observation Value This field contains the diagnostic image text or transcribed report. OBX-2 (Value Type) contains the data type for this field according to which observation field is formatted. 16. Responsible Observer This field may contain the defined Provider Id and name of the responsible observer if these elements are available. 16.8. source table This field contains the identification of the organization responsible for assigning the responsible observer identifier. Note: Table values must be obtained from the Integration Coordination Centre (ICC) at Alberta Health Services. <End Report_Content> <End Segment Group> 2011 Government of Alberta 55 of 68

Appendix - A: Tables HL70001 Sex (User) Code Name Comments F Female M Male U Unknown HL70003 Event Type (HL7) Code Name Comments R01 ORU/ACK - Unsolicited transmission of an observation T02 MDM/ACK - Original document notification and content HL70004 Patient Class (User) Code Name Comments A Ambulatory Outpatient B Obstetrics E Emergency I Inpatient K 30-day Outpatient Visit M Emergency O Outpatient P Preadmit R Recurring Patient HL70062 Event Reason (User) Code Name Comments 1 Patient request 2 Physician order 3 Census Management HL70076 Message Type (HL7) Code Name Comments MDM Documentation Message ORU Observation result / unsolicited HL70103 Processing ID (HL7) Code Name Comments D Debugging P Production T Training 2011 Government of Alberta 56 of 68

HL70104 Version ID (HL7) Code Name Comments 2 Release 2.0 September 1988 2.0D Demo 2.0 October 1988 2.1 Release 2.1 March 1990 2.2 Release 2.2 December 1994 2.3 Release 2.3?? 1996 HL70119 Order Control Code (HL7) Code Name Comments OC Order cancelled RE Observations to follow HL70123 Result Status (HL7) Code Name Comments C Correction to results F Final Results; results stored and verified. Can only be changed with a corrected result. P Preliminary A verified early result is available final results not yet obtained HL70125 Value Type (HL7) Code Name Comments AD Address CE Coded Entry CF Coded Element With Formatted Values CK Composite ID With Check Digit CN Composite ID And Name CP Composite Price CX Extended Composite ID With Check Digit DT Date ED Encapsulated Data Used when sending PDF files. FT Formatted Text (Display) Used when sending formatted display text. ID Coded Value MO Money NM Numeric PN Person Name RP Reference Pointer SN Structured Numeric ST String Data TM Time TN Telephone Number TS Time Stamp (Date & Time) TX Text Data (Display) Used when sending display text XAD Extended Address XCN Extended Composite Name And Number For Persons XON Extended Composite Name And Number For 2011 Government of Alberta 57 of 68

XPN XTN Organizations Extended Person Number Extended Telecommunications Number HL70136 Yes/No Indicator (HL7) Code Name Comments N No Y Yes HL70191 Main Type of Reference Data (HL7) Code Name Comments AP Other application data, typically uninterpreted binary data AU Audio Data FT Formatted Text IM Image Data NS Non-scanned Image SD Scanned Document SI Scanned Image TX Machine Readable Text Document HL70270 Document Type (User) Code Name Comments CD Cardiodiagnostics CN Consultation DI Diagnostic imaging DS Discharge summary ED Emergency department report HP History and physical examination OP Operative report PN Procedure note PR Progress note SP Surgical pathology AU Authenticated DI Dictated DO Documented IN Incomplete IP In progress PA Pre-authenticated HL70301 Universal ID Type (HL7) Code Name Comments L,M,N These are reserved for locally defined coding schemes HL70396 Coding System (HL7) Code Name Comments NDC National Drug Code 2011 Government of Alberta 58 of 68

99annnn Local code where annnn is the local code set These are Alberta Health and Wellness specific codes. The alpha indicates the regional health authority the code is associated with. The number indicates the code assigned. Some of these codes will be replaced with equivalent HISCA numbers. DIN Drug Identification Number GPN General Product Number HISCAnnn Health Information Standards Committee for Alberta where nnn is the HISCA table number HL7nnnn Health Level Seven where nnnn is the HL7 table number ISOnnnn International Standards Organization where nnnn is the ISO table number LN Logical Observation Identifier Names and Codes (LOINC) 99-0001 Province Codes (Local) Code Name Comments AB Alberta BC British Columbia MB Manitoba NB New Brunswick NL Newfoundland and Labrador NT Northwest Territories NU Nunavut ON Ontario PE Prince Edward Island QC Quebec SK Saskatchewan NS Nova Scotia YT Yukon 2011 Government of Alberta 59 of 68

Appendix - B: Error Conditions This section intentionally left blank. 2011 Government of Alberta 60 of 68

Appendix - C: HL7 Data Types The data types in this section are listed in alphabetical order. Data Type Category/ Data type Data Type Name HL7 V2.3 Section Reference Notes/Format Alphanumeric ST String 2.8.38 TX Text data 2.8.43 FT Formatted text 2.8.17 Numerical CQ Composite quantity with units 2.8.9 <quantity (NM)> ^ <units (CE)> MO Money 2.8.23 <quantity (NM)> ^ <denomination (ID)> NM Numeric 2.8.25 SI Sequence ID 2.8.36 SN Structured numeric 2.8.37 <comparator> ^ <num1 (NM)> ^ <separator/suffix> ^ <num2 (NM)> Identifier ID Coded values for HL7 tables 2.8.19 IS Coded value for 2.8.20 HD user-defined tables Hierarchic designator 2.8.18 <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Used only as part of EI and other data types. EI Entity identifier 2.8.15 <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> RP Reference pointer 2.8.34 <pointer (ST) > ^ < application ID (HD)> ^ <type of data (ID)> ^ <subtype (ID)> PL Person location 2.8.26 <point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility (HD)> ^ < location status (IS )> ^ <person location type (IS)> ^ <building (IS )> ^ <floor (IS )> ^ <location description (ST)> PT Processing type 2.8.29 <processing ID (ID)> ^ <processing mode (ID)> Date/Time DT Date 2.8.13 YYYY[MM[DD]] TM Time 2.8.39 HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ] TS Time stamp 2.8.42 YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/- ZZZZ] ^ <degree of precision> Code Values CE Coded element 2.8.3 <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)> CF CK Coded element with formatted values Composite ID with check digit 2.8.4 <identifier (ID)> ^ <formatted text (FT)> ^ <name of coding system (ST)> ^ <alternate identifier (ID)> ^ <alternate formatted text (FT)> ^ <name of alternate coding system (ST)> 2.8.5 <ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> 2011 Government of Alberta 61 of 68

Data Type Category/ Data type CN CX XCN Data Type Name HL7 V2.3 Section Reference Composite ID number and name Extended composite ID with check digit Extended composite ID number and name Notes/Format 2.8.7 <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> 2.8.10 <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD) )> ^ <identifier type code (IS)> ^ < assigning facility (HD) 2.8.46 In Version 2.3, use instead of the CN data type. <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> Generic CM Composite 2.8.6 No new CM s are allowed after HL7 Version 2.2. Hence there are no new CM s in Version 2.3. Demographics AD Address 2.8.1 <street address (ST)> ^ < other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ <address type (ID)> ^ <other geographic designation (ST)> PN Person name 2.8.28 <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> TN Telephone number 2.8.40 [NN] [(999)]999-9999[X99999][B99999][C any text] XAD Extended address 2.8.45 In Version 2.3, replaces the AD data type. <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> XPN Extended person 2.8.48 In Version 2.3, replaces the PN data type. name <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name XON Extended composite name and ID number for organizations type code (ID) > 2.8.47 <organization name (ST)> ^ <organization name type code (IS)> ^ <ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)> 2011 Government of Alberta 62 of 68

Data Type Category/ Data type XTN Data Type Name HL7 V2.3 Section Reference Extended telecommunications number Notes/Format 2.8.49 In Version 2.3, replaces the TN data type. [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)> Specialty/Chapter Specific Waveform CD Channel definition 2.8.2 For waveform data only, see Chapter 7, Section 7.15.3. <channel identifier (*)> ^ <channel number (NM)> & <channel name (ST)>> ^ <electrode names (*) > ^ <channel sensitivity/units (*) > ^ <calibration parameters (*)> ^ <sampling frequency (NM)> ^ <minimum/maximum data values (*)> MA Multiplexed array 2.8.22 For waveform data only, see Chapter 7, Section 7.15.2. <sample 1 from channel 1 (NM)> ^ <sample 1 from channel 2 (NM)> ^ <sample 1 from channel 3 (NM)>...~<sample 2 from channel 1 (NM)> ^ <sample 2 from channel 2 (NM)> ^ <sample 2 from channel 3 (NM)>...~ NA Numeric array 2.8.24 For waveform data only, see Chapter 7, Section 7.15.1. <value1 (NM)> ^ <value2 (NM)> ^ <value3 (NM)> ^ <value4 (NM)> ^... ED Encapsulated data 2.8.14 Supports ASCII MIME-encoding of binary data. <source application (HD) > ^ <main type of data (ID)> ^ <data subtype (ID)> ^ <encoding (ID)> ^ <data (ST)> Price data CP Composite price 2.8.8 In Version 2.3, replaces the MO data type. <price (MO)> ^ <price type (ID)> ^ <from value (NM)> ^ <to value (NM)> ^ <range units (CE)> ^ <range type (ID)> 2011 Government of Alberta 63 of 68

Data Type Category/ Data type Data Type Name HL7 V2.3 Section Reference Notes/Format Patient Administration/Financial Information FC Financial class 2.8.16 <financial class (ID)> ^ <effective date (TS)> Extended Queries QSC QIP RCD Query selection criteria Query input parameter list: Row column definition: 2.8.31 <name of field (ST)> ^ <relational operator (ID)> ^ <value (ST)> ^ <relational conjunction (ID)> 2.8.30 <field name (ST) > ^ <value1 (ST) & value2 (ST) & value3 (ST)...> 2.8.32 <HL7 item number (ST)> ^ <HL7 data type (ST)> ^ <maximum column width (NM)> Master Files DLN Driver s license 2.8.11 <license number (ST)> ^ <issuing state, number province, country (IS)> ^ <expiration date (DT) JCC Job code/class 2.8.21 <job code (IS)> ^ <job class (IS)> Medical Records/Information Management PPN VH Visiting hours 2.8.44 <start day range (ID)> ^ <end day range (ID)> ^ <start hour range (TM)> ^ <end hour range (TM)> Performing person time stamp: 2.8.27 <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(id)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ < date/time action performed (TS)> Time Series: DR Date/time range 2.8.12 Scheduling Chapter Only: <range start date/time (TS)> ^ <range end date/time (TS)> RI Repeat interval 2.8.33 Scheduling Chapter Only: <repeat pattern (IS)> ^ <explicit time interval (ST)> SCV Scheduling class value pair 2.8.35 Scheduling Chapter Only: <parameter class (IS)> ^ <parameter value (IS)> TQ Timing/quantity 2.8.41 For timing/quantity specifications for orders, see Chapter 4, Section 4.4. <quantity (CQ)> ^ <interval (*)> ^ <duration (*)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing (*)> 2011 Government of Alberta 64 of 68

Appendix - D: Glossary The following is a list of references used to construct this message specification: Laboratory Test Results Delivery Message Specifications HISCA Diagnostic Imaging Messaging Standard (Accepted in Draft v0.1) HISCA - HL7 Library 2011 Government of Alberta 65 of 68

Appendix - E: Report Data Element Mapping to HL7 Segment/Fields The following charts provide a mapping from the generic report data element to the corresponding HL7 segment and field. The table is provided only for demonstration purposes to ensure that there is no loss of clinical data. It is not recommended for stakeholders to use for translating between the two message specifications. Common Elements to MDM and ORU Domain Report Data Element Seg. HL7 Data Element Sending Application MSH.3 Sending Application Sending Facility (RHA) MSH.4 Sending Facility Receiving Application MSH.5 Receiving Application Receiving Facility (POS) MSH.6 Receiving Facility PHN/ULI PID.2 Patient ID ( ID) RHA MRN PID.3 Patient ID (Internal ID) Facility MRN PID.4 Alternate Patient ID Patient Name PID.5 Patient Name Patient Date of Birth PID.7 Date of Birth Patient Gender PID.8 Sex Patient Home Phone Number PID.13 Phone Number - Home Site Administrative Number PID.18 Patient Account Number Patient Death Date and Time PID.29 Patient Death Date and Time Patient Death Indicator PID.30 Patient Death Indicator Accommodation/Site Unit PV1.3 Assigned Patient Location Attending/Family Doctor PV1.7 Attending Doctor Referring Doctor PV1.8 Referring Doctor Consulting Doctor PV1.9 Consulting Doctor Admitting Doctor PV1.17 Admitting Doctor Patient Visit Number PV1.19 Visit Number Admit date PV1.44 Admit Date/Time Discharge Date PV1.45 Discharge Date/Time Report Section Heading OBX.4 Observation Sub-ID Report Content OBX.5 Observation Value Physician performing the partial consult/exam OBX.16 Responsible Observer Elements Different in MDM and ORU Domain Report Data Element Seg. HL7 Data Element Seg. HL7 DATA ELEMENT Unique Document Unique report identifier. OBR.3 Filler Order Number TXA-12 Number Universal Service Report Type OBR.4 Identifier TXA-2 Document Type Key Clinical Date OBR.7 Observation Date/Time TXA-4 Activity Date/Time Physician performing the consult/exam OBR.34 Technician TXA-5 Primary Activity Provider Code/Name 2011 Government of Alberta 66 of 68

Report Data Element Seg. HL7 Data Element Seg. Report Status OBR.25 Result Status TXA-17 Carbon Copy / Copy to: OBR.28 Result Copies To TXA-23 Unique identifier of parent report OBR.29 Parent Number TXA-13 Physician verifying the Principal Result report OBR.32 Interpreter TXA-22 Transcriptionist OBR.35 Transcriptionist TXA-11 Transcribed Date OBR.35.2 start date/time TXA-7 HL7 DATA ELEMENT Document Completion Status Distributed Copies (Code and Name of Recipients) Parent Document Number Authentication Person, Time Stamp Transcriptionist Code/Name Transcription Date/Time 2011 Government of Alberta 67 of 68

Appendix - F: Contact Information Name Responsibility Email Integration Coordination Centre (ICC) Stewards for table values (where icc@albertahealthservices.ca referenced in specification) Alberta HL7 Working Group HL7 message maintenance and abhl7@gov.ab.ca change requests Alberta Conformance Standards Working Group Conformance Issues conformance@gov.ab.ca 2011 Government of Alberta 68 of 68