HEALTH INFORMATION STANDARDS COMMITTEE FOR ALBERTA

HEALTH INFORMATION MESSAGING STANDARD HEALTH INFORMATION STANDARDS COMMITTEE FOR ALBERTA DIAGNOSTIC IMAGING TEXT AND OTHER TRANSCRIBED REPORTS MESSAGE SPECIFICATION Status: Accepted in Draft Version 0.4 Status Date: August 12, 2009

On September 16, 2009 the Health Information Standards Committee for Alberta (HISCA) Accepted in Draft, three (3) Diagnostic Imaging submissions including the Alberta Diagnostic Imaging Reporting Requirement, the Diagnostic Imaging Text and other Transcribed Reports Message Specification, and the Alberta Diagnostic Imaging HL7 Message Specifications. These submissions are now required to be reviewed by peers and other interested parties as a part of the HISCA process. Following this review, Stakeholder feedback will be consolidated and presented back to the project teams for consideration and/or dispute resolution. Please find and review the attached copies of the submissions and return your comments or concerns to the HISCA secretariat at HISCA@gov.ab.ca. Request for Comments until October 28, 2009. Once again, thank you for your assistance. Susan Anderson, Chair Health Information Standards Committee for Alberta Date

VERSION HISTORY Version Version Date Summary of Changes Changes marked 0 2005-Sep-30 Draft No 0 2005-Nov-21 Accepted in Draft No 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. No 0.2 2006-Dec-31 Include EVN Event Type segment in the MDM message profile. No MDM messages sent to CH by ACB contain EVN segment. 0.3 2009-Aug-12 Fix Source Table specification in the ORU message. The fix affects the following fields: - Principal Result Interpreter - Technician - Transcriptionist

TABLE OF CONTENTS GENERAL OVERVIEW...1 BUSINESS PROCESS OVERVIEW...2 PROCESS FLOW...3 REPORT DESCRIPTION...3 Diagnostic Imaging Text Report...3 Operative Report...4 Patient History Report...4 Consultation Report...5 Discharge / Obstetrical Discharge Summary Report...6 Report of Procedure...7 E.E.G. Text Report...7 Clinic Report / Progress Note...8 Letter...9 E.C.G. Text Report...9 REPORT PROCESS...11 Process Flow...11 Actors...12 Precondition...12 Narrative...12 Alternative Flow...13 Post Condition...13 USE CASES SPECIFICATION...14 Use Case Diagram...14 Use Case: Communicate Transcribed Report (Ref# UC01)...14 Use-Case: Communicate DI Text Report (Ref# UC02)...16 TRANSACTION SUMMARY...18 OVERVIEW...18 MDM_T02...18 Message Purpose...18 Message Rules...18 Transaction Messages...22 Error Conditions...22 ORU_R01...23 Message Purpose...23 Message Rules...23 Transaction Messages...23 Error Conditions...23 TRANSACTION MESSAGE DETAIL...24 SECTION GUIDE...24 Characteristics...24 Profile Type...24 Interactions...24 Message Characteristics...24 Segment and Segment Group Definitions...25 Segment Table...26 Segment Element Details...27 General Notes...28

MDM MESSAGE SPECIFICATION...29 MDM - Transcribed Reports Delivery Message Specification...29 MSH - Message header segment...30 EVN Event Type segment...33 PID - Patient Identification...34 PV1 - Patient visit...37 TXA - Transcription document header segment...41 Report Content...47 OBX Observation Segment...47 End Report Content...48 ORU MESSAGE SPECIFICATION...49 ORU - Diagnostic Imaging Text and Other Transcribed Reports Delivery Message Specification...49 MSH - Message header segment...50 PID - Patient Identification...53 PV1 - Patient visit...56 ORC Common Order Segment...60 OBR Observation Request Segment...61 Report Content...67 OBX Observation Segment...67 End Report Content...68 TRANSACTION MESSAGE TABLES...69 HL70001 SEX (USER)...69 HL70003 EVENT TYPE (HL7)...69 HL70004 PATIENT CLASS (USER)...75 HL70062 EVENT REASON (USER)...75 HL70076 MESSAGE TYPE (HL7)...75 HL70103 PROCESSING ID (HL7)...78 HL70104 VERSION ID (HL7)...78 HL70123 RESULT STATUS (HL7)...79 HL70125 VALUE TYPE (HL7)...79 HL70136 YES/NO INDICATOR (HL7)...80 HL70270 DOCUMENT TYPE (HL7)...80 HL70271 DOCUMENT COMPLETION STATUS (HL7)...81 HL70396 CODING SYSTEM (HL7)...82 99-0001 PROVINCIAL CODES (USER)...83 ERROR CONDITIONS...84 HL7 DATA TYPES...85 GLOSSARY...89 APPENDIX A - REPORT DATA ELEMENT MAPPING TO HL7 SEGMENT/FIELDS...90 Common Elements to MDM and ORU Domain...90 Elements Different in MDM and ORU Domain...90

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. Capital Health, 2. Calgary Health Region, 3. Regional Shared Health Information Program (RSHIP), 4. Alberta Cancer Board, 5. Physician Office System Program (POSP), 6. Canadian Healthcare Information Technology Trade Association (CHITTA), and 7. 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. 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). 2009 Government of Alberta Page 1 of 97

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 Regional Health Authorities 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 Regional Health Authority (RHA) 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 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 RHA 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. 2009 Government of Alberta Page 2 of 97

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: Capital Health Region No Exceptions Calgary Health Region 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. 2009 Government of Alberta Page 3 of 97

Regional Shared Health Information Program 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: Capital Health Region No Exceptions Calgary Health Region No Exceptions Regional Shared Health Information Program 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. 2009 Government of Alberta Page 4 of 97

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: Capital Health Region Exception # 1 - In most cases, copies of the transcribed history are not sent out. The majority of histories transcribed for the Capital Health Region 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). Calgary Health Region Exception # 1 Very few histories are transcribed; they are either provided by the admitting physician s office or are hand written on site. Regional Shared Health Information Program 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: 2009 Government of Alberta Page 5 of 97

Capital Health Region No Exceptions Calgary Health Region No Exceptions Regional Shared Health Information Program 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: Capital Health Region 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. Calgary Health Region Exception # 1 A Delivery Note template is used. (Note: this template is categorized under the Operative Report type and is not a Discharge Summary.) Regional Shared Health Information Program 2009 Government of Alberta Page 6 of 97

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: 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: Capital Health Region No Exceptions Calgary Health Region No Exceptions Regional Shared Health Information Program 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. 2009 Government of Alberta Page 7 of 97

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. However, in order for any recipients to receive a copy, the author must request that a copy be sent to them. Exceptions: Capital Health Region No Exceptions Calgary Health Region No Exceptions Regional Shared Health Information Program 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: Capital Health Region No Exceptions Calgary Health Region No Exceptions Regional Shared Health Information Program No Exceptions Alberta Cancer Board 2009 Government of Alberta Page 8 of 97

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. 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: Capital Health Region 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. Calgary Health Region No Exceptions Regional Shared Health Information Program 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. 2009 Government of Alberta Page 9 of 97

Exceptions: Capital Health Region No Exceptions Calgary Health Region No Exceptions Regional Shared Health Information Program 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 No Exceptions Additional information: This report is similar to the Diagnostic Imaging Text report. 2009 Government of Alberta Page 10 of 97

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 2009 Government of Alberta Page 11 of 97

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). 2009 Government of Alberta Page 12 of 97

ALTERNATIVE FLOW In the Calgary Health Region, 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 the Calgary Health Region, the second copy of the DI Text Report is sent after report is verified regardless if any changes are made. In the Capital Health Region, most DI reports have electronic signature availability. In the Capital Health Region, 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. 2009 Government of Alberta Page 13 of 97

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 Regional Health Authority 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. 2009 Government of Alberta Page 14 of 97

Primary Actor: Transcription System A.1.I.1 A.1.I.2 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 A.1.I.2.1 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. A.1.I.3 Special Requirements The following message domain specifications apply to this process: MDM ORU A.1.I.4 Preconditions Reports are transcribed; report messages are generated, validated and ready to be communicated to the POS/EMR. A.1.I.5 Postconditions The POS/EMR receives the message reports successfully and reports can be obtained by the receiver. A.1.I.6 Additional Information Secondary Actors: POS/EMR. Offstage Actors: Health Records. 2009 Government of Alberta Page 15 of 97

USE-CASE: COMMUNICATE DI TEXT REPORT (REF# UC02) A.1.I.7 Brief Description The Communicate DI Text Report process enables the transport of diagnostic imaging text reports from the Regional Health Authority 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 A.1.I.8 A.1.I.9 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 A.1.I.9.1 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. A.1.I.10 Special Requirements The following message domain specifications apply to this process: ORU A.1.I.11 Preconditions Report messages are generated, validated and ready to be communicated to the POS/EMR. A.1.I.12 Postconditions The POS/EMR receives the message reports successfully and reports can be obtained by the receiver. A.1.I.13 Additional Information Secondary Actors: POS/EMR. 2009 Government of Alberta Page 16 of 97

Offstage Actors: Health Records. 2009 Government of Alberta Page 17 of 97

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 Section E 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 Section G - Error Conditions. MDM_T02 MESSAGE PURPOSE This message is used to transport electronic copies of Transcribed Reports from the Regional Health Authority 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 Cardiodiagnostics Consultation Discharge summary Emergency department report History and physical examination Operative report 2009 Government of Alberta Page 18 of 97

PN PR SP Procedure note 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 Length TXA Field Definition TXA-1 Set ID- TXA SI 4 OBR-1 Set ID - Observation Request 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. 2009 Government of Alberta Page 19 of 97

Seq. MDM Field Data Type TXA-10 Not Supported Length Seq. OBR Field Data Type Length TXA Field Definition 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 TXA-13 Parent Document Number EI 99 OBR- 29.2 parent's filler order number 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 This field is the placer application s order number. TXA-15 Not Supported 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. TXA-16 Unique Document File Name ST 60 OBR- 4.5 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. 2009 Government of Alberta Page 20 of 97

Seq. MDM Field Data Type TXA-19 Not Supported Length Seq. OBR Field Data Type Length TXA Field Definition 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. TXA-20 Not Supported This optional field identifies the storage status of the document. TXA-21 Not Supported This free text field (limited to 30 characters) contains the reason for document status change. TXA- 22.1 Authentication Person PPN OBR- 32.1 Principal Result Interpreter - name CN This field identifies the person responsible for authenticating the document. TXA- 22.15 Authentication Person - Date/time Action Performed TS OBR- 32.2 Principal Result TS Interpreter - Start date/time 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. 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 2009 Government of Alberta Page 21 of 97

TRANSACTION MESSAGES Send: MDM_T02 Response: None ERROR CONDITIONS NONE 2009 Government of Alberta Page 22 of 97

ORU_R01 MESSAGE PURPOSE This message is used to transport electronic copies of Diagnostic Imaging Text and Other Transcribed Reports from an RHA 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 CN DS ED HP OP PN PR SP DI Cardiodiagnostics Consultation Discharge summary Emergency department report History and physical examination Operative report Procedure note Progress note Surgical pathology Diagnostic Imaging TRANSACTION MESSAGES Send: ORU_R01 Response: None ERROR CONDITIONS NONE 2009 Government of Alberta Page 23 of 97

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. 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. Identifiers This section lists three types of identifiers; Message Profile Identifiers, Static Publish/Subscribe Identifiers 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 2009 Government of Alberta Page 24 of 97

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. 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. 2009 Government of Alberta Page 25 of 97

Mnemonic Description Definition 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 doublequote 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. A.1.I.14 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 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. A.1.I.15 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. 2009 Government of Alberta Page 26 of 97

A.1.I.16 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. A.1.I.17 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. A.1.I.18 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. A.1.I.19 Obligation 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. A.1.I.20 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. A.1.I.21 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. 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', 2009 Government of Alberta Page 27 of 97

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: 2009 Government of Alberta Page 28 of 97

MDM MESSAGE SPECIFICATION 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 Calgary Health Region 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. A.1.I.22 Characteristics Message Characteristics Profile Type: Implementation Encoding Method ER7 A.1.I.23 Medical Document Management A.1.I.23.1 Message Characteristics Role Sender Accept Acknowledgement: NE Application Acknowledgement: NE Acknowledgement Mode: NA A.1.I.23.2 Message Message Type: Trigger Event: Message Structure: MDM T02 MDM_T02 A.1.I.23.3 HL7 Grammar MSH EVN PID PV1 TXA { OBX } 2009 Government of Alberta Page 29 of 97

MSH - MESSAGE HEADER SEGMENT (Usage: Required Cardinality: 1..1) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. Seq. Name Type Table Len. Opt. Card. Contents 1 Field Separator ST 1 R 1..1 Fixed 2 Encoding Characters ST 4 R 1..1 Fixed ^~\& 3 Sending Application HD RE 0..1 3.1 namespace ID IS 15 R 1..1 4 Sending Facility HD RE 0..1 4.1 namespace ID IS 20 R 1..1 5 Receiving Application HD RE 0..1 5.1 namespace ID IS 30 R 1..1 6 Receiving Facility HD RE 0..1 6.1 namespace ID IS 30 R 1..1 7 Date / Time of Message TS RE 0..1 7.1 Date/Time NM 26 R 1..1 9 Message Type CM_MSG R 1..1 9.1 message type ID HL70076 3 R 1..1 Fixed MDM 9.2 trigger event ID HL70003 3 R 1..1 Fixed T02 10 Message Control ID ST 20 R 1..1 11 Processing ID PT R 1..1 11.1 processing ID ST HL70103 1 R 1..1 Fixed P 12 Version ID ID HL70104 3 R 1..1 Fixed 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 standard defines this character as:. The receiving application must use the character sent in this field as the delimiter to separate fields within a segment. 2. Encoding Characters 2009 Government of Alberta Page 30 of 97

This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. HISCA standard defines the values as: ^~\&. The receiving application must use the characters sent in this field as the delimiter to separate field components, repeated components, escaping a character and subcomponent separation. 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. RHA defined (see 3.1 namespace ID) 3.1. namespace ID Note: Table values should be obtained from the RHA 4. Sending Facility This field identifies the sending application among multiple identical instances of the application running on behalf of different organizations. RHA defined (see 4.1 namespace ID) 4.1. namespace ID Note: Table values should be obtained from the RHA 3. 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. RHA defined (see 5.1 namespace ID) 5.1. namespace ID Note: Table values should be obtained from the RHA 6. Receiving Facility This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. RHA defined (see 6.1 namespace ID) 6.1. namespace ID Note: Table values should be obtained from the RHA 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 Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 9. Message Type This field contains the message type and trigger event. 2009 Government of Alberta Page 31 of 97

9.1 message type Fixed: MDM 9.2 trigger event T02 - Original document notification and content 10 Message Control ID This field contains a number or other identifier that uniquely identifies the message. 11 Processing ID Processing mode defines whether the message is part of a production, training, or debugging system 11.1 processing ID Fixed: P 12 Version ID Fixed: 2.3 2009 Government of Alberta Page 32 of 97

EVN EVENT TYPE SEGMENT (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 R 1..1 2.1 Date/Time NM 26 R 1..1 3 Date/Time Planned Event TS R 1..1 3.1 Date/Time NM 26 RE 0..1 4 Event Reason Code ID HL70062 3 RE 0..1 5 Operator ID XCN 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 RE 0..1 6.1 Date/Time NM 26 RE 0..1 1. Event Type Code This field has been retained for backward compatibility only. HL7 recommends 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 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[HHHMM[SS[.SSSS]]][+-ZZZZ] 3. Date/Time Planned Event This field contains the date/time that the event is planned 3.1. Date/Time 2009 Government of Alberta Page 33 of 97

2009 Government of Alberta Page 34 of 97

YYYYMMDD[HHHMM[SS[.SSSS]]][+ZZZZ] 4. Event Reason Code This field contains the reason for this event (e.g., patient request, physician order, census management, etc.). 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[HHHMM[SS[.SSSS]]][+-ZZZZ] PID - PATIENT IDENTIFICATION (Usage: Required Cardinality: 1..1) The PID segment is used as the primary means of communicating patient identification information referenced in the accompanying report. Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient ID SI 4 RE 0..1 2 Patient ID (External ID) CX RE 0..1 2.1 ID ST 16 R 1..1 2.4 assigning authority HD R 1..1 2.4. 1 namespace ID IS 99-0001 2 R 1..1 e.g. AB 3 Patient ID (Internal ID) CX R 1..1 3.1 ID ST 15 R 1..1 4 Alternate Patient ID CX RE 0..5 4.1 ID ST 15 R 1..1 4.4. 1 namespace ID IS 99-0001 2 R 1..1 e.g. BC 5 Patient Name XPN R 1..1 5.1 family name ST 50 R 1..1 2009 Government of Alberta Page 35 of 97

Seq. Name Type Table Len. Opt. Card. Contents 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 R 1..1 7.1 Date/Time NM 26 R 1..1 8 Sex IS HL70001 1 R 1..1 13 Phone Number - Home XTN RE 0..1 13.1 Telephone Number ST 40 R 1..1 18 Patient Account Number CX RE 0..1 18.1 ID ST 12 R 1..1 29 Patient Death Date and Time TS 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 (External ID) This field contains the Alberta Unique Lifetime Identifier (ULI) / Personal Health Number (PHN). 2.1. ID ULI/PHN value. 2.4.1. namespace ID The mnemonic of the province of Alberta AB 3. Patient ID (Internal ID) This field may contain the facility s patient identifier. 3.1. ID identifier (Alpha and/or numeric up to 15 characters in length) 4. Alternate Patient ID This field may contain the community patient identifier or out-of-province identifier. 4.1. ID identifier (Alpha and/or numeric up to 15 characters in length) 2009 Government of Alberta Page 36 of 97

4.4.1. namespace ID The mnemonic of the province assigning the out-of-province identifier 5. Patient Name 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". 5.3. middle initial or name This component may contain the middle initial or middle name only. 7. Date of Birth Date the patient was born. Format: YYYYMMDD 8. Sex This field indicates the gender of the associated patient. 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. Patient Death Date and Time Date and time the patient died. Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 30. Patient Death Indicator Yes/No indicator. Rule: If PID-29 is valued, then this field must be set to Y. 2009 Government of Alberta Page 37 of 97

PV1 - PATIENT VISIT (Usage: Required Cardinality: 1..1) The PV1 segment is used to communicate information on the encounter documented in the accompanying report. Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient Visit SI 4 RE 0..1 2 Patient Class IS HL70004 1 R 1..1 3 Assigned Patient Location PL RE 0..1 3.1 point of care (IS) IS 20 RE 0..1 3.4 facility (HD) HD HD RE 0..1 3.4.1 namespace ID IS 10 R 1..1 7 Attending Doctor XCN 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 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 RE 0..5 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 RE 0..1 17.1 ID number (ST) ST 15 R 1..1 17.2 family name ST 50 R 1..1 2009 Government of Alberta Page 38 of 97

Seq. Name Type Table Len. Opt. Card. Contents 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 44 Admit Date/Time RE 0..1 44.1 Date/Time NM 26 R 1..1 45 Discharge Date/Time RE 0..1 45.1 Date/Time NM 26 R 1..1 1. Set ID - Patient Visit This field contains the number that identifies this transaction. 2. Patient Class Note: Local codes added to the table. A=Ambulatory Outpatient (Capital Health, Calgary Health Region), M=Emergency (Calgary Health Region), K=30 Day Outpatient Visit (Calgary Health Region) 3. Assigned Patient Location This field contains the patient s location where the encounter occurred. 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 RHA. 3.4. facility (HD) HD Facility defining the point of care value. 3.4.1. namespace Note: Table values should be obtained from the RHA 7. Attending Doctor This field may contain the defined Provider Id and name of the attending doctor if these elements are available. Note: Table values should be obtained from the RHA. 7.1. family name This component contains the family name alone. 7.2. given name 2009 Government of Alberta Page 39 of 97

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". 7.3. 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 should be obtained from the RHA. 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 should be obtained from the RHA. 8.1. family name This component contains the family name alone. 8.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". 8.3. 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 referring doctor identifier. Note: Table values should be obtained from the RHA. 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 should be obtained from the RHA. 9.1. family name This component contains the family name alone. 9.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". 9.3. 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 consulting doctor identifier. Note: Table values should be obtained from the RHA. 2009 Government of Alberta Page 40 of 97

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 should be obtained from the RHA. 17.1. family name This component contains the family name alone. 17.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". 17.3. 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 admitting doctor identifier. Note: Table values should be obtained from the RHA. 44. Admit Date and Time Date and time the patient was admitted into the facility. Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 45. Discharge Date and Time Date and time the patient was discharged from the facility. Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 2009 Government of Alberta Page 41 of 97

TXA - TRANSCRIPTION DOCUMENT HEADER SEGMENT (Usage: Required Cardinality: 1..1) The TXA segment contains information specific to a transcribed document but does not include the text of the document. The message is created as a result of a document status change. 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 Presentation ID HL70191 2 RE 0..1 4. Activity Date/Time TS RE 0..1 4.1 Date/Time NM 26 R 1..1 5. Primary Activity Provider Code/Name XCN R 1..1 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.9 assigning authority HD R 1..1 5.9.1 namespace ID IS 30 R 1..1 6. Origination Date/Time TS RE 0..1 6.1 Date/Time NM 26 R 1..1 7. Transcription Date/Time TS CE 0..1 7.1 Date/Time NM 26 R 1..1 8. Edit Date/Time TS X 0..* 8.1 Date/Time NM 26 X 1..1 9. Originator Code/Name XCN X 0..1 9.1 ID number (ST) ST 15 X 1..1 9.2 family name ST 50 X 1 1 9.3 given name ST 50 X 0..1 9.4 middle initial or name ST 50 X 0..1 10. Assigned Document Authenticator XCN X 0..* 10.1 ID number (ST) ST 15 X 1..1 2009 Government of Alberta Page 42 of 97

Seq. Name Type Table Len. Opt. Card. Contents 10.2 family name ST 50 X 1..1 10.3 given name ST 50 X 0..1 10.4 middle initial or name ST 50 X 0..1 11. Transcriptionist Code/Name XCN 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.9 assigning authority HD R 1..1 11.9.1 namespace ID IS 30 R 1..1 12. Unique Document Number EI 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 RE 0..1 13.1 entity identifier ST 55 R 1..1 13.2 namespace ID IS 44 RE 0..1 15. Filler Order Number EI X 0..1 15.1 entity identifier ST 55 X 1..1 15.2 namespace ID IS 44 X 0..1 16. Unique Document File Name ST 30 RE 0..1 17. Document Completion Status ID HL70271 2 R 1..1 18. Document Confidentiality Status ID 2 X 0..1 19. Document Availability Status ID 2 X 0..1 22. Authentication Person, Time Stamp PPN CE 0..* 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.9 assigning authority HD R 1..1 22.9.1 namespace ID IS 30 R 1..1 22.15 Date/Time Action Performed TS RE 0..1 2009 Government of Alberta Page 43 of 97

Seq. Name Type Table Len. Opt. Card. Contents 22.15.1 Date/Time NM 26 R 1..1 23 Distributed Copies (Code and Name of Recipients) XCN RE 0..* 23.1 ID number (ST) ST 15 R 1..1 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.9 assigning authority HD R 1..1 23.9.1 namespace ID IS 30 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. See table HL70270 for valid values. 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. 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 should be obtained from the RHA. 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". 5.3. middle initial or name This component may contain the middle initial or middle name only. 2009 Government of Alberta Page 44 of 97

5.9.1 Namespace ID This field contains the identification of the organization responsible for assigning the primary activity provider identifier. Note: Table values should be obtained from the RHA. 6. Origination Date/Time This field contains the date and time the document was created (i.e., dictated, recorded, etc.). 6.1 Date/Time Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 7. Transcription Date/Time This field contains the date and time the input was actually transcribed. Rule: This field is valued based upon the presence of a value in TXA-17- document status of anything except "dictated". 7.1 Date/Time Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 11. Transcriptionist Code/Name This field identifies the person transcribing the document. Note: Table values should be obtained from the RHA. 11.1. family name This component contains the family name alone. 11.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". 11.3. middle initial or name This component may contain the middle initial or middle name only. 11.9.1 namespace ID This field contains the identification of the organization responsible for assigning the primary activity provider identifier. Note: Table values should be obtained from the RHA. 12. Unique Document Number This field contains a unique document identification number assigned by the sending system. This document number is used to assist the receiving system in matching future updates to the document, as well as to identify the document in a query. 2009 Government of Alberta Page 45 of 97

13. Parent Document Number 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. 16. Unique Document File Name 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. 17. Document Completion Status This field identifies the current completion state of the document. 22. Authentication Person, Time Stamp This field may contain the defined Provider Id and name of the result interpreter/authenticator if these elements are available. Note: Table values should be obtained from the RHA. Rule: This field is valued when the status of TXA-17-document completion status is equal to AU (authenticated). 22.1. family name This component contains the family name alone. 22.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". 22.3. middle initial or name This component may contain the middle initial or middle name only. 22.15 Date/Time Action Performed Date the report was authenticated. 23. Distributed Copies (Code and Name of Recipients) This field identifies the person(s) who are to receive a copy of this document. Note: Table values should be obtained from the RHA. 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. "Mary" or "Mary Ellen". 23.4. middle initial or name 2009 Government of Alberta Page 46 of 97

This component may contain the middle initial or middle name only. 2009 Government of Alberta Page 47 of 97

REPORT CONTENT (Usage: Required Cardinality: 1..*) The OBX segment is allowed to repeat. This provides the capability to sectionalize the report. OBX OBSERVATION SEGMENT (Usage: Required Cardinality: 1..1) This segment provides details about a particular report. 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 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 E.g. HL70270 3.4 alternate identifier ST 15 RE 0..1 3.5 alternate text ST 60 RE 0..1 3.6 name of alternate coding system ST 10 RE 0..1 4. Observation Sub-ID ST 20 C 0..1 5. Observation Value VARIES 65536 R 1..1 16. Responsible Observer XCN 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.9 assigning authority HD R 1..1 16.9.1 namespace ID IS 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. 2009 Government of Alberta Page 48 of 97

3. Observation Identifier This component represents the type of report i.e. OP - Operative Report, PR - Progress Note, etc. and if required the subsection within the report i.e. Diagnosis and Treatment, Reason for Referral, Physical Examination, Plan. 4. Observation Sub-ID This component represents the title of the sub-sections within a report. 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 the observation value 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. Note: Table values should be obtained from the RHA. 16.1. family name This component contains the family name alone. 16.2. given name END REPORT CONTENT 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". 16.3. middle initial or name This component may contain the middle initial or middle name only. 16.9.1 namespace ID This field contains the identification of the organization responsible for assigning the responsible observer identifier. Note: Table values should be obtained from the RHA. 2009 Government of Alberta Page 49 of 97

ORU MESSAGE SPECIFICATION ORU - DIAGNOSTIC IMAGING TEXT AND OTHER TRANSCRIBED REPORTS DELIVERY MESSAGE SPECIFICATION The following represents the DITR HL7 message structure that enables the delivery of Diagnostic Imaging Text and Other Transcribed Reports to physician office systems. ORU is currently used for diagnostic imaging text by all stakeholders creating DI text reports and for other transcribed reports by Capital Health and RSHIP. All health authorities in the province engaging in the electronic delivery of Diagnostic Imaging Text and Other Transcribed Reports to physician offices will develop their interfaces according to this specification. A.1.I.24 Characteristics Message Characteristics Profile Type: Implementation Encoding Method ER7 A.1.I.25 Observational Results (Unsolicited) A.1.I.25.1 Message Characteristics Role Sender Accept Acknowledgement: NE Application Acknowledgement: NE Acknowledgement Mode: NA A.1.I.25.2 Message Message Type: Trigger Event: Message Structure: ORU R01 ORU_R01 A.1.I.25.3 HL7 Grammar MSH PID PV1 { [ORC] OBR { OBX } } 2009 Government of Alberta Page 50 of 97

MSH - MESSAGE HEADER SEGMENT (Usage: Required Cardinality: 1..1) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. Seq. Name Type Table Len. Opt. Card. Contents 1 Field Separator ST 1 R 1..1 Fixed 2 Encoding Characters ST 4 R 1..1 Fixed ^~\& 3 Sending Application HD RE 0..1 3.1 namespace ID IS 15 R 1..1 4 ending Facility HD RE 0..1 4.1 namespace ID IS 20 R 1..1 5 Receiving Application HD RE 0..1 5.1 namespace ID IS 30 R 1..1 6 Receiving Facility HD RE 0..1 6.1 namespace ID IS 30 R 1..1 7 Date / Time of Message TS RE 0..1 7.1 Date/Time NM 26 R 1..1 9 Message Type CM_MSG R 1..1 9.1 message type ID HL70076 3 R 1..1 Fixed ORU 9.2 trigger event ID HL70003 3 R 1..1 Fixed R01 10 Message Control ID ST 20 R 1..1 11 Processing ID PT R 1..1 11.1 processing ID ST HL70103 1 R 1..1 Fixed P 12 Version ID ID HL70104 3 R 1..1 Fixed 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 standard defines this character as:. The receiving application must use the character sent in this field as the delimiter to separate fields within a segment. 2. Encoding Characters 2009 Government of Alberta Page 51 of 97

This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. HISCA standard defines the values as: ^~\&. The receiving application must use the characters sent in this field as the delimiter to separate field components, repeated components, escaping a character and subcomponent separation. 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. RHA defined (see 3.1 namespace ID) 3.1. namespace ID Note: Table values should be obtained from the RHA 4. Sending Facility This field identifies the sending application among multiple identical instances of the application running on behalf of different organizations. RHA defined (see 4.1 namespace ID) 4.1. namespace ID Note: Table values should be obtained from the RHA 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. RHA defined (see 5.1 namespace ID) 5.1. namespace ID Note: Table values should be obtained from the RHA 6. Receiving Facility This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. RHA defined (see 6.1 namespace ID) 6.1. namespace ID Note: Table values should be obtained from the RHA 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 Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 9. Message Type This field contains the message type and trigger event. 2009 Government of Alberta Page 52 of 97

9.1 message type Fixed: ORU 9.2 trigger event Fixed: R01 10. Message Control ID This field contains a number or other identifier that uniquely identifies the message. 11. Processing ID Processing mode defines whether the message is part of a production, training, or debugging system 11.1 processing ID Fixed: P 12. Version ID Fixed: 2.3 2009 Government of Alberta Page 53 of 97

PID - PATIENT IDENTIFICATION (Usage: Required Cardinality: 1..1) The PID segment is used as the primary means of communicating patient identification information referenced in the accompanying report. Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient ID SI 4 RE 0..1 2 Patient ID (External ID) CX RE 0..1 2.1 ID ST 16 R 1..1 2.4 assigning authority HD R 1..1 2.4. 1 namespace ID IS 99-0001 2 R 1..1 e.g. AB 3 Patient ID (Internal ID) CX R 1..1 3.1 ID ST 15 R 1..1 4 Alternate Patient ID CX RE 0..5 4.1 ID ST 15 R 1..1 4.4. 1 namespace ID IS 99-0001 2 R 1..1 e.g. BC 5 Patient Name XPN 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 R 1..1 7.1 Date/Time NM 26 R 1..1 8 Sex IS HL70001 1 R 1..1 13 Phone Number - Home XTN RE 0..1 13.1 Telephone Number ST 40 R 1..1 18 Patient Account Number CX RE 0..1 18.1 ID ST 12 R 1..1 29 Patient Death Date and Time TS 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 2009 Government of Alberta Page 54 of 97

This field contains the number that identifies this transaction. 2. Patient ID (External ID) This field contains the Alberta Unique Lifetime Identifier (ULI) / Personal Health Number (PHN). 2.1. ID ULI/PHN value. 2.4.1. namespace ID The mnemonic of the province of Alberta AB 3. Patient ID (Internal ID) This field may contain the facility s patient identifier. 3.1. ID identifier (Alpha and/or numeric up to 15 characters in length) 4. Alternate Patient ID This field may contain the community patient identifier or out-of-province identifier. 4.1. ID identifier (Alpha and/or numeric up to 15 characters in length) 4.4.1. namespace ID The mnemonic of the province assigning the out-of-province identifier 5. Patient Name 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". 5.3. middle initial or name This component may contain the middle initial or middle name only. 7. Date of Birth Date the patient was born. Format: YYYYMMDD 8. Sex This field indicates the gender of the associated patient. 2009 Government of Alberta Page 55 of 97

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. Patient Death Date and Time Date and time the patient died. Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 30. Patient Death Indicator Yes/No indicator. Rule: If PID-29 is valued, then this field must be set to Y. 2009 Government of Alberta Page 56 of 97

PV1 - PATIENT VISIT (Usage: Required Cardinality: 1..1) The PV1 segment is used to communicate information on the encounter documented in the accompanying report. Seq. Name Type Table Len. Opt. Card. Contents 1 Set ID - Patient Visit SI 4 RE 0..1 2 Patient Class IS HL70004 1 R 1..1 3 Assigned Patient Location PL RE 0..1 3.1 point of care (IS) IS 20 RE 0..1 3.4 facility (HD) HD HD RE 0..1 3.4.1 namespace ID IS 10 R 1..1 7 Attending Doctor XCN 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 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 RE 0..5 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 RE 0..1 17.1 ID number (ST) ST 15 R 1..1 17.2 family name ST 50 R 1..1 2009 Government of Alberta Page 57 of 97

Seq. Name Type Table Len. Opt. Card. Contents 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 44 Admit Date/Time RE 0..1 44.1 Date/Time NM 26 R 1..1 45 Discharge Date/Time RE 0..1 45.1 Date/Time NM 26 R 1..1 1. Set ID - Patient Visit This field contains the number that identifies this transaction. 2. Patient Class Note: Local codes added to the table. A=Ambulatory Outpatient (Capital Health, Calgary Health Region), M=Emergency (Calgary Health Region), K=30 Day Outpatient Visit (Calgary Health Region) 3. Assigned Patient Location This field contains the patient s location where the encounter occurred. 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 RHA. 3.4. facility (HD) HD Facility defining the point of care value. 3.4.1. namespace Note: Table values should be obtained from the RHA 7. Attending Doctor This field may contain the defined Provider Id and name of the attending doctor if these elements are available. Note: Table values should be obtained from the RHA. 7.1. family name This component contains the family name alone. 7.2. given name 2009 Government of Alberta Page 58 of 97

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". 7.3. 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 should be obtained from the RHA. 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 should be obtained from the RHA. 8.1. family name This component contains the family name alone. 8.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". 8.3. 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 referring doctor identifier. Note: Table values should be obtained from the RHA. 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 should be obtained from the RHA. 9.1. family name This component contains the family name alone. 9.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". 9.3. 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 consulting doctor identifier. Note: Table values should be obtained from the RHA. 2009 Government of Alberta Page 59 of 97

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 should be obtained from the RHA. 17.1. family name This component contains the family name alone. 17.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". 17.3. 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 admitting doctor identifier. Note: Table values should be obtained from the RHA. 44. Admit Date and Time Date and time the patient was admitted into the facility. Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 45. Discharge Date and Time Date and time the patient was discharged from the facility. Format: YYYYMMDD[HHHMM[SS[.SSSS]]][+-ZZZZ] 2009 Government of Alberta Page 60 of 97

ORC COMMON ORDER SEGMENT (Usage: Required but may be empty 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) message 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. Note: Table values should be obtained from the RHA RE = Resulted. OC = Cancelled 2009 Government of Alberta Page 61 of 97

OBR OBSERVATION REQUEST SEGMENT (Usage: Required Cardinality: 1..1) The Observation Request Segment is used to transmit information specific to a diagnostic imaging text or transcribed report. Seq. Name Type Table Len. Opt. Card. Contents 1. Set ID - Observation Request SI 4 RE 0..1 3. Filler Order Number EI RE 0..1 3.1 entity identifier ST 55 R 1..1 3.2 namespace ID IS 44 RE 0..1 4. Universal Service Identifier CE 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 E.g. HL70270 4.4 alternate identifier ST 15 RE 0..1 4.5 alternate text ST 60 RE 0..1 4.6 name of alternate coding system ST 10 RE 0..1 7. Observation Date/Time TS R 1..1 7.1 Date/Time NM 26 R 1..1 16. Ordering Provider XCN 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 16.8 source table ID 30 R 1..1 20. Filler Field 1 ST 15 RE 0..1 21. Filler Field 2 ST 15 RE 0..1 22. Results Rpt/Status Chng - Date/Time TS X 0..1 22.1 Date/Time NM 26 X 1..1 25. Result Status ID HL70123 1 R 1..1 27. Quantity/Timing TQ X 0..1 27.4 start date/time TS X 0..1 27.4.1 Date/Time NM 26 X 1..1 2009 Government of Alberta Page 62 of 97

Seq. Name Type Table Len. Opt. Card. Contents 28. Result Copies To XCN 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.8 source table ID 30 R 1..1 29. Parent Number CM_EIP CE 0..1 29.2 parent's filler order number EI RE 0..1 29.2.1 entity identifier ST 55 R 1..1 29.2.2 namespace ID IS 44 RE 0..1 32. Principal Result Interpreter CM_NDL RE 0..1 32.1 name CN 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 30 R 1..1 32.2 start date/time TS RE 0..1 32.2.1 Date/Time NM 26 R 1..1 33. Assistant Result Interpreter CM_NDL X 0..* 34. Technician CM_NDL RE 0..* 34.1 name CN 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 RE 0..1 34.2.1 Date/Time NM 26 R 1..1 35. Transcriptionist CM_NDL RE 0..* 35.1 name CN R 1..1 35.1.1 ID number (ST) ST 15 R 1..1 2009 Government of Alberta Page 63 of 97

Seq. Name Type Table Len. Opt. Card. Contents 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 1. Set ID - Observation Request This field contains the number that identifies this transaction. 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. 16. Ordering Provider This field identifies the provider who ordered the test. Note: Table values should be obtained from the RHA. 16.1. family name This component contains the family name alone. 16.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". 16.3. middle initial or name 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 ordering provider identifier. Note: Table values should be obtained from the RHA. 20. Filler Field 1 This field is definable for any use by the sending application. 2009 Government of Alberta Page 64 of 97

21. Filler Field 1 This field is definable for any use by the sending application. 25. Result Status Result Status for implementation of Diagnostic Imaging Text and Other 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. Table values should be obtained from the RHA. 28.1. family name This component contains the family name alone. 28.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". 28.3. middle initial or name This component may contain the middle initial or middle name only. 28.8. source table This field contains the identification of the organization responsible for assigning the copy to identifier(s). Note: Table values should be obtained from the RHA. 29. Parent Number Filler Order Number of parent report. 32. Principal Result Interpreter This field may contain the defined Provider Id and name of the result interpreter/authenticator if these elements are available. Table values should be obtained from the RHA. 32.1.1. family name This component contains the family name alone. 32.1.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". 32.1.3. middle initial or name This component may contain the middle initial or middle name only. 32.1.8. source table 2009 Government of Alberta Page 65 of 97

This field contains the identification of the organization responsible for assigning the principal result interpreter identifier. Note: Table values should be obtained from the RHA. 32.2 start date/time Date the report was authenticated. 34. Technician This field contains the name of the person identified in the document as being responsible for performing the procedure or activity. Table values should be obtained from the RHA. 34.1.1. family name This component contains the family name alone. 34.1.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". 34.1.3. middle initial or name This component may contain the middle initial or middle name only. 34.1.8. source table This field contains the identification of the organization responsible for assigning the technician identifier. Note: Table values should be obtained from the RHA. 34.2 start date/time Date the report was dictated. 35. Transcriptionist This field may contain the defined Provider Id and name of the transcriptionist if these elements are available. Table values should be obtained from the RHA. 35.1.1. family name This component contains the family name alone. 35.1.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". 35.1.3. middle initial or name This component may contain the middle initial or middle name only. 35.1.8. source table This field contains the identification of the organization responsible for assigning the transcriptionist identifier. Note: Table values should be obtained from the RHA. 2009 Government of Alberta Page 66 of 97

35.2 start date/time Date the report was transcribed. 2009 Government of Alberta Page 67 of 97

REPORT CONTENT (Usage: Required Cardinality: 1..*) The OBX segment is allowed to repeat. This provides the capability to sectionalize the report. OBX OBSERVATION SEGMENT (Usage: Required Cardinality: 1..1) This segment provides details about a particular report. 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 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 E.g. HL70270 3.4 alternate identifier ST 15 RE 0..1 3.5 alternate text ST 60 RE 0..1 3.6 name of alternate coding system ST 10 RE 0..1 4 Observation Sub-ID ST 20 C 0..1 5 Observation Value VARIES 65536 R 1..1 16 Responsible Observer XCN 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.9 assigning authority HD R 1..1 16.9.1 namespace ID IS 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. 2009 Government of Alberta Page 68 of 97

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. 4. Observation Sub-ID This component represents the title of the sub-sections within a report. 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 the observation value 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.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. "Mary" or "Mary Ellen". END REPORT CONTENT 16.4. middle initial or name This component may contain the middle initial or middle name only. 16.9.1 namespace ID This field contains the identification of the organization responsible for assigning the responsible observer identifier. Note: Table values should be obtained from the RHA. 2009 Government of Alberta Page 69 of 97

TRANSACTION MESSAGE TABLES HL70001 SEX (USER) Code Name Comments F Female M Male U Unknown HL70003 EVENT TYPE (HL7) Code Name Comments A01 ADT/ACK - Admit a patient A02 ADT/ACK - Transfer a patient A03 ADT/ACK - Discharge a patient A04 ADT/ACK - Register a patient A05 ADT/ACK - Preadmit a patient A06 ADT/ACK - Transfer an outpatient to inpatient A07 ADT/ACK - Transfer an inpatient to outpatient A08 ADT/ACK - Update patient information A09 ADT/ACK - Patient departing A10 ADT/ACK - Patient arriving A11 ADT/ACK - Cancel admit A12 ADT/ACK - Cancel transfer A13 ADT/ACK - Cancel discharge A14 ADT/ACK - Pending admit A15 ADT/ACK - Pending transfer A16 ADT/ACK - Pending discharge A17 ADT/ACK - Swap patients A18 ADT/ACK - Merge patient information A19 QRY/ADR - Patient query A20 ADT/ACK - Nursing/Census application updates A21 ADT/ACK - Leave of absence - out (leaving) A22 ADT/ACK - Leave of absence - in (returning) A23 ADT/ACK - Delete a patient record 2009 Government of Alberta Page 70 of 97

HL70003 EVENT TYPE (HL7) Code Name Comments A24 A25 A26 A27 A28 A29 A30 A31 A32 A33 A34 A35 A36 A37 A38 A39 A40 A41 A42 A43 A44 A45 A46 A47 A48 A49 A50 A51 C01 C02 ADT/ACK - Link patient information ADT/ACK - Cancel pending discharge ADT/ACK - Cancel pending transfer ADT/ACK - Cancel pending admit ADT/ACK - Add person information ADT/ACK - Delete person information ADT/ACK - Merge person information ADT/ACK - Update person information ADT/ACK - Cancel patient arriving ADT/ACK - Cancel patient departing ADT/ACK - Merge patient information - patient ID only ADT/ACK - Merge patient information - account number only ADT/ACK - Merge patient information - patient ID and account number ADT/ACK - Unlink patient information ADT/ACK - Cancel pre-admit ADT/ACK - Merge person - external ID ADT/ACK - Merge person - internal ID ADT/ACK - Merge account - patient account number ADT/ACK - Merge visit - visit number ADT/ACK - Move patient information - internal ID ADT/ACK - Move account information -patient account number ADT/ACK - Move visit information - visit number ADT/ACK - Change external ID ADT/ACK - Change internal ID ADT/ACK - Change alternate patient ID ADT/ACK - Change patient account number ADT/ACK - Change visit number ADT/ACK - Change alternate visit ID CRM - Register a patient on a clinical trial CRM - Cancel a patient registration on clinical trial (for clerical mistakes only) 2009 Government of Alberta Page 71 of 97

HL70003 EVENT TYPE (HL7) Code Name Comments C02 C04 C05 C06 C07 C08 C09 C10 C11 C12 I01 I02 I03 I04 I05 I06 I07 I08 I09 I10 I11 I12 I13 I14 I15 M01 M02 CRM - Correct/update registration information CRM - Patient has gone off a clinical trial CRM - Patient enters phase of clinical trial CRM - Cancel patient entering a phase (clerical mistake) CRM - Correct/update phase information CRM - Patient has gone off phase of clinical trial CSU - Automated time intervals for reporting, like monthly CSU - Patient completes the clinical trial CSU - Patient completes a phase of the clinical trial CSU - Update/correction of patient order/result information CNQ QRY/EQQ/VQQ/RQQ - Cancel query RQI/RPI - Request for insurance information RQI/RPL - Request/receipt of patient selection display list RQI/RPR - Request/receipt of patient selection list RQD/RPI - Request for patient demographic data RQC/RCI - Request for patient clinical information RQC/RCL - Request/receipt of clinical data listing PIN/ACK - Unsolicited insurance information RQA/RPA - Request for treatment authorization information RQA/RPA - Request for modification to an authorization RQA/RPA - Request for resubmission of an authorization RQA/RPA - Request for cancellation of an authorization REF/RRI - Patient referral REF/RRI - Modify patient referral REF/RRI - Cancel patient referral REF/RRI - Request patient referral status MFN/MFK - Master file not otherwise specified (for backward compatibility only) MFN/MFK - Master file - Staff Practitioner 2009 Government of Alberta Page 72 of 97

HL70003 EVENT TYPE (HL7) Code Name Comments M03 M04 M05 M06 M07 M08 M09 M10 M11 R05 R06 RAR RDR RER RGR ROR P01 P02 P03 P04 P05 P06 Q01 Q02 Q03 Q05 MFN/MFK - Master file - Test/Observation varies MFQ/MFR - Master files query (use event same as asking for e.g., M05 - location) MFD/ACK - Master files delayed application acknowledgment MFN/MFK - Patient location master file MFN/MFK - Charge description master file MFN/MFK - Clinical study without phases but with schedules master file MFN/MFK - Test/Observation (Numeric) master file MFN/MFK - Test/Observation (Categorical) master file MFN/MFK - Test/Observation batteries master file MFN/MFK - Test/Calculated observations master file O01 ORM - Order message (also RDE, RDS, RGV, RAS,O02 ORR - Order response (also RRE, RRD, RRG, RRA, QRY/DSR - query for display results UDM - unsolicited update/display results RAR - Pharmacy administration information query response RDR - Pharmacy dispense information query response RER - Pharmacy encoded order information query response RGR - Pharmacy dose information query response ROR - Pharmacy prescription order query response BAR/ACK - Add and update patient account BAR/ACK - Purge patient account DFT/ACK - Post detail financial transaction QRY/DSP - Generate bill and A/R statements BAR/ACK - Update account BAR/ACK - End account QRY/DSR - Query sent for immediate response QRY/ACK - Query sent for deferred response DSR/ACK - Deferred response to a query UDM/ACK - Unsolicited display update 2009 Government of Alberta Page 73 of 97

HL70003 EVENT TYPE (HL7) Code Name Comments Q06 R01 R02 R03 R04 RAR RER R0R S01 S02 S03 S04 S05 S06 S07 S08 S09 S10 S11 S12 S13 S14 S15 S16 S17 S18 OSQ/OSR - Query for order status ORU/ACK - Unsolicited transmission of an observation QRY - Query for results of observation Display-oriented results, query/unsol. update (for backward compatibility only) ORF - Response to query; transmission of requested observation RAR - Pharmacy administration information query response RER-Pharmacy encoded order information query response R0R - Pharmacy prescription order query response SRM/SRR - Request new appointment booking SRM/SRR - Request appointment rescheduling SRM/SRR - Request appointment modification SRM/SRR - Request appointment cancellation SRM/SRR - Request appointment discontinuation SRM/SRR - Request appointment deletion SRM/SRR - Request addition of service/resource on appointment SRM/SRR - Request modification of service/resource on appointment SRM/SRR - Request cancellation of service/resource on appointment SRM/SRR - Request discontinuation of service/resource on appointment SRM/SRR - Request deletion of service/resource on appointment SIU/ACK - Notification of new appointment booking SIU/ACK - Notification of appointment rescheduling SIU/ACK - Notification of appointment modification SIU/ACK - Notification of appointment cancellation SIU/ACK - Notification of appointment discontinuation SIU/ACK - Notification of appointment deletion SIU/ACK - Notification of addition of service/resource on appointment 2009 Government of Alberta Page 74 of 97

HL70003 EVENT TYPE (HL7) Code Name Comments S19 S20 S21 S22 S23 S24 S25 S26 T01 T02 T03 T04 T05 T06 T07 T08 T09 V01 V02 V03 V04 W01 W02 SIU/ACK - Notification of modification of service/resource on appointment SIU/ACK - Notification of cancellation of service/resource on appointment SIU/ACK - Notification of discontinuation of service/resource on appointment SIU/ACK - Notification of deletion of service/resource on appointment SIU/ACK - Notification of blocked schedule time slot(s) SIU/ACK - Notification of open (#unblocked#) schedule time slot(s) SQM/SQR - Query schedule information Notification that patient did not show up for scheduled appointment MDM/ACK - Original document notification MDM/ACK - Original document notification and content MDM/ACK - Document status change notification MDM/ACK - Document status change notification and content MDM/ACK - Document addendum notification MDM/ACK - Document addendum notification and content MDM/ACK - Document replace notification MDM/ACK - Document replace notification and content MDM/ACK - Document cancel notification VXQ - Query for vaccination record VXX - Response to vaccination query returning multiple PID matches VXR- Vaccination record response VXU- Unsolicited vaccination record update ORU- Waveform result, unsolicited transmission of requested information QRF- Waveform result, response to query 2009 Government of Alberta Page 75 of 97

HL70004 PATIENT CLASS (USER) Code Name Comments E I O P R B Emergency Inpatient Outpatient Preadmit Recurring Patient Obstetrics A Ambulatory Outpatient Local code used by Calgary and Capital M Emergency Local code used by Calgary K 30-day Outpatient Visit Local code used by Calgary HL70062 EVENT REASON (USER) Code Name Comments 01 Patient Request 02 Physician Order 03 Census Management HL70076 MESSAGE TYPE (HL7) Code Name Comments ACK General acknowledgment message ADR ADT response ADT ADT message ARD Ancillary RPT (display) BAR Add/change billing account CNQ Cancel query CSU Unsolicited clinical study data DFT Detail financial transaction DSR Display response 2009 Government of Alberta Page 76 of 97

HL70076 MESSAGE TYPE (HL7) Code Name Comments EDR Enhanced display response ERP Event replay response ERQ Event replay query EQQ Embedded query language query MCF Delayed acknowledgment MDM Documentation message MFN Master files notification MFK Master files application acknowledgment MFD Master files delayed application acknowledgment MFQ Master files query MFR Master files query response ORF Observation result/record response ORM Order message ORR Order acknowledgment message ORU Observation result/unsolicited OSQ Order status query OSR Order status response QRY Query, original Mode PEX Product experience PGL Patient goal PGR Patient goal response PGQ Patient goal query PIN Patient Insurance Information PPP Patient pathway (problem-oriented) PPR Patient problem PPR Patient problem PPT Patient pathway (goal oriented) PGR Patient goal response PRQ Patient care problem query PRR Patient problem response PTQ Patient pathway (problem-oriented) query PTR Patient pathway (problem-oriented) response PTU Patient pathway (goal-oriented) query 2009 Government of Alberta Page 77 of 97

HL70076 MESSAGE TYPE (HL7) Code Name Comments PTV Patient pathway (goal-oriented) response PIN Patient information RCI Return clinical information RAR Pharmacy administration information RCL Return clinical list RAS Pharmacy administration message RDE Pharmacy encoded order message RDR Pharmacy dispense information RDS Pharmacy dispense message RGV Pharmacy give message RGR Pharmacy dose information REF Patient referral RER Pharmacy encoded order information ROC Request clinical information ROD Request patient demographics ROR Pharmacy prescription order response RPA Return patient authorization RPI Return patient information RPL Return patient display list RPR Return patient list RQA Request patient authorization RQI Request patient information RRA Pharmacy administration acknowledgment RRD Pharmacy dispense acknowledgment RRE Pharmacy encoded order acknowledgment RRG Pharmacy give acknowledgment RRI Return patient referral SIU Schedule information unsolicited SPQ Stored procedure request SQM Schedule query SQR Schedule query response SRM Study registration SRM Schedule request 2009 Government of Alberta Page 78 of 97

HL70076 MESSAGE TYPE (HL7) Code Name Comments SRR Scheduled request response TBR Tabular response UDM Unsolicited display message VQQ Virtual table query VXQ Query for vaccination record VXX Vaccination query response with multiple PID matches VXR Vaccination query record response VXU Unsolicited vaccination record update HL70103 PROCESSING ID (HL7) Code Name Comments D Debugging P Production T Training 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 2009 Government of Alberta Page 79 of 97

HL70123 RESULT STATUS (HL7) Code Name Comments P Preliminary A verified early result is available, final results not yet obtained C F Correction to results Final results; results stored and verified. Can only be changed with a corrected result. X Deleted/Cancelled Tests. Local Code used by Palliser I Pending/Incomplete but Specimen Received. Local Code used by Palliser HL70125 VALUE TYPE (HL7) Code Name Comments AD CE CF CK CN CP CX DT Address Coded Entry Coded Element With Formatted Values Composite ID With Check Digit Composite ID And Name Composite Price Extended Composite ID With Check Digit Date ED Encapsulated Data Used when sending PDF files. FT ID MO NM PN RP SN ST Formatted Text (Display) Coded Value Money Numeric Person Name Reference Pointer Structured Numeric String Data Used when sending formatted display text. 2009 Government of Alberta Page 80 of 97

HL70125 VALUE TYPE (HL7) Code Name Comments TM TN TS TX XAD XCN XON XPN XTN Time Telephone Number Time Stamp (Date & Time) Text Data (Display) Extended Address Extended Composite Name And Number For Persons Extended Composite Name And Number For Organizations Extended Person Number Extended Telecommunications Number Used when sending display text HL70136 YES/NO INDICATOR (HL7) Code Name Comments N No Y Yes HL70270 DOCUMENT TYPE (HL7) Code Name Comments AR Autopsy report Not Supported CD CN DI DS ED HP OP Cardiodiagnostics Consultation Diagnostic imaging Discharge summary Emergency department report History and physical examination Operative report 2009 Government of Alberta Page 81 of 97

HL70270 DOCUMENT TYPE (HL7) Code Name Comments PC Psychiatric consultation Not Supported PH PN PR SP Psychiatric history and physical examination Procedure note Progress note Surgical pathology Not Supported TS Transfer summary Not Supported LT Letter Local Addition HL70271 DOCUMENT COMPLETION STATUS (HL7) Code Name Comments AU Authenticated DI Dictated DO Documented IN Incomplete IP In Progress LA Legally authenticated Not Supported PA Pre-authenticated CA Cancelled Locally added code 2009 Government of Alberta Page 82 of 97

HL70396 CODING SYSTEM (HL7) Code Name Comments 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 GPN HISCAnnn HL7nnnn ISOnnnn LN NDC Drug Identification Number General Product Number Health Information Standards Committee for Alberta where nnn is the HISCA table number Health Level Seven where nnnn is the HL7 table number International Standards Organization where nnnn is the ISO table number Logical Observation Identifier Names and Codes (LOINC) National Drug Code 2009 Government of Alberta Page 83 of 97

99-0001 PROVINCIAL CODES (USER) Code Name Comments AB Alberta BC British Columbia MB Manitoba NB New Brunswick NL Newfoundland and Labrador X Nova Scotia NT Northwest Territories NU Nunavut ON Ontario PE Prince Edward Island QC Quebec SK Saskatchewan YT Yukon AB Alberta 2009 Government of Alberta Page 84 of 97

ERROR CONDITIONS This section intentionally left blank. 2009 Government of Alberta Page 85 of 97

HL7 DATA TYPES The data types in this section are listed in alphabetical order. Data Type Category/ Data type Alphanumeric Data Type Name ST String 2.8.38 HL7 V2.3 Section Reference Notes/Format Numerical TX Text data 2.8.43 FT Formatted text 2.8.17 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 Identifier SN Structured numeric 2.8.37 <comparator> ^ <num1 (NM)> ^ <separator/suffix> ^ <num2 (NM)> Date/Time ID IS HD Coded values for HL7 tables Coded value for user-defined tables Hierarchic designator 2.8.19 2.8.20 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)> 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)> 2009 Government of Alberta Page 86 of 97

Data Type Category/ Data type Generic CN CX XCN Data Type Name Composite ID number and name Extended composite ID with check digit Extended composite ID number and name HL7 V2.3 Section Reference 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)> 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 XON XTN Specialty/Chapter Specific Extended person name Extended composite name and ID number for organizations Extended telecommunications number 2.8.48 In Version 2.3, replaces the PN data type. <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 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)> 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)> 2009 Government of Alberta Page 87 of 97

Data Type Category/ Data type Waveform Data Type Name HL7 V2.3 Section Reference Notes/Format 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)> 2009 Government of Alberta Page 88 of 97

Data Type Category/ Data type Patient Administration/Financi al Information Data Type Name HL7 V2.3 Section Reference Notes/Format FC Financial class 2.8.16 <financial class (ID)> ^ <effective date (TS)> Extended Queries QSC Query selection criteria 2.8.31 <name of field (ST)> ^ <relational operator (ID)> ^ <value (ST)> ^ <relational conjunction (ID)> QIP RCD Query input parameter list: Row column definition: 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 number 2.8.11 <license number (ST)> ^ <issuing state, province, country (IS)> ^ <expiration date (DT) JCC Job code/class 2.8.21 <job code (IS)> ^ <job class (IS)> VH Visiting hours 2.8.44 <start day range (ID)> ^ <end day range (ID)> ^ <start hour range (TM)> ^ <end hour range (TM)> Medical Records/Information Management PPN Time Series: 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)> 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 (*)> 2009 Government of Alberta Page 89 of 97

GLOSSARY The following is a list of references used to construct this message specification: Laboratory Test Results Delivery Message Specifications HISCA Diagnostic Imaging Report Standard (Accepted for Information Purposes 2003-Jun) HISCA - HL7 Library 2009 Government of Alberta Page 90 of 97

APPENDIX A - 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 (External 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 2009 Government of Alberta Page 91 of 97

Report Data Element Seg. HL7 Data Element Seg. HL7 Data Element Unique report identifier. OBR.3 Filler Order Number TXA-12 Report Type OBR.4 Unique Document Number Universal Service 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 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 report OBR.32 Principal Result Interpreter TXA-22 Transcriptionist OBR.35 Transcriptionist TXA-11 Transcribed Date OBR.35.2 start date/time TXA-7 Primary Activity Provider Code/Name Document Completion Status Distributed Copies (Code and Name of Recipients) Parent Document Number Authentication Person, Time Stamp Transcriptionist Code/Name Transcription Date/Time 2009 Government of Alberta Page 92 of 97