Scribd Logo
Upload

Welcome to Scribd!

  • HL7 Gateway, User Manual, English

    Uploaded by

    Randall Bardwell
    107 views40 pages
    HL7 Manual Mortara Cardiology Systems

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    HL7 Manual Mortara Cardiology Systems

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    107 views40 pages

    HL7 Gateway, User Manual, English

    Uploaded by

    Randall Bardwell
    HL7 Manual Mortara Cardiology Systems

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 40
    MDI HL7 EHR Implementation Guide REF 9506-166-50-ENG Rev B1 Manufactured by Mortara Instrument, Ine, Milwauke: ZN consin U.S.A, CAUTION: Federal law resiriets this device 1a sale by or on the order ofa physician. C7 Mortara Copyright © 2016, All rights reserved. By Mortara Instrument, Ine. 7865 N. 86" Street Milwaukee, WI 53224 U.S.A, Tel: 1.800.231.7137 Fax: 1414354.4760, \wwomortara.com Service: 1.888.667.8272 E-mail: lelsupporv@mortara.com Information inthis document is subject to change without notice. ELL Is a trademarks or registered trademark of Mortara Instrument, \demarks or registered trademarks oftheir respective companies. Inc, All other product and company names are Scope ‘This document defines the Mortara Device Interface (MDI) HL7 device interface specifications for an EHR oF PACS system. This document includes the EI.I™™ ECG deviee HILT interface to Health Information Technology (HIT) systems that utilize these technologies. Ityou have any questions regarding execution ofthis guide, contact technical support at 1.888.667.8272 # techsupport@mortara.com ECG Overview Mortara manufactures and sels diagnostic ECG (electrocardiogram) equipment that monitors and analyzes the electrical activity ofthe heart with subsequent diagnoses. Mortara makes three different modalities of ECG. equipment: 1, Resting ECG (referred to as ECG or EKG) ~ this modality acquires 10-seconds of ECG data withthe patient at rest. This isa very common sereening test for heart disease and heart-related incidents such as Theat attacks. 2, Stes test BCG ~ this modality acquires ECG data as a stressor is applied co the patient, The stressor is typically a treadmill or bicycle. Pharmacological agents can also be applied that stress the patient's heart. ‘The purpose ofthe test is to determine if sessing the heart elieits abnormal heart conditions. A stress exam js offen done in conjunction with an echocardiogram (ultrasound of the heart) or nuclear imaging (picture ‘of blood flow) procedure. The length ofthe procedure is typically 5 ~ 15 minutes. 3. Holter monitoring ECG ~ this modality acquires ECG data ofthe patient during normal activity. Data is 'ypicaly collected for 24-48 hours. The purpose ofthe tests to capture transient events ofthe heart that do ‘not occur a rest or during stress conditions. A Holter exam can be used to sereen for heart disease. tis also used for post heart-procedlure monitoring, eg, pacemaker implant ECG Workflow Most healthcare providers have adopted an EC modalities (resting ECG, stress and Holter) ‘workflow with the following steps. This workflow applies to all 1. Order Placed 1. Optionally ~ patient identifieation (demographics) obtained via a patient registration event, 2, Patient Information (including order and accounts) entered onto the device. 3. Testis taken on the devie. 4. Testis printed, 5. Testis scanned and attached to patient record in the EHR char. 6. Physician overreads and signs the report 18. Optionally - physieian adds note to procedure, but does not sign report 7. Patient (insurance) is billed for the procedure The intended use of the MDI HL7 interface is to automate the process described in the ECG workllow above. ‘Benefits fo the customer ofthe electronic workflow are: Redes or remove paper. 1 2. Eliminate or reduce typing and typing errors 3. Improved patient identification with an exam. 4, Automated attachment of exam to patient recard inthe EHR. 5, Easy access to electronic patient record via EHR application. 6. EMR capabilities: a. Security b. Audit logs . Electronic signature of report 7. Improved revenue eyele management; billing and re-imbursement ‘The following diagram depicts fully electronic ECG procedure workflow. I ulilizes an orders-based procedure, although it could support an encounter-based workflow as well if supported by the EHR. R ff R & aiee = reson 2a eee ‘The MDL-supported devices support HLT interface technologies: 1. Inbound Patient demographics a, Orders ~ HL ORM and OMG. b.Encounter~HL7 ADT 2. Outbound Test Exam a. HLT (text only) b. HLT with PDF (referenced or encapsulated) © PDF Expott (COLD Feed) ‘This interface isolates the EHR system Irom any knowledge ofthe # and types of devices. MDI HL interfaces ean bbe customized on a per EHR basis such that every installation for all customers follows the same configuration and methodology, 2. a reproducible process. HL7 Interface Overview The diagram below depicts the operation ofthe MDI H1L7 Interface with supported ELI ECG devices. The di depicts the clinical workflow of information from the point of providing patient demographic information (via HLT ADT or HL? ORM message) to sending the ECG report back to the EHR application. ‘The HLT ADT, Orders and Results interface can support multiple EL] ECG devices. Each of the ELI ECG devices is configured to communicate with the MDI application pera variety of protocols: wireless network, wired network, setial communications, and file shares. The MDI HL7 interface performs the following funetions ‘+ hosts the patient demographic information received from the ADT messages. ‘+ hosts the orders received from the order messages. ‘+ provides the single point of H1.7 interface connectivity between the ELI ECG devices and the EHR. ¢ So eusmoeco > — cisinat ik ~ var HL7 Interface Operating Environments ‘The MDI HILT interface is commonly deployed in ovo types of operating environments when interfacing to an EHR application; 1. LAN 2. Hosted Biceectons——*| Mot HUF irtertace ELK ECS ion NUP Itarace “on Premigelnetaitort” EHR EHR ‘ent Appleton Server depletion LAN Scenario In this scenario the MDI HILT Interface communicates on the same local area network (domain) as the EHR application server, The MDI interlace would be installed on an “on premise” system that is located on the same ‘nefwork (LAN) as the BHR application, ELI ECG devices connect to the MDI using the provider local area network, aR Win caer pteaion En Ctent- Sener Connect, EHR Hosting Sto Provider Intranet HTTP, wba, VN MOI Hosting Site fe a ‘MOL=HLT wtemsce Hosted Scenario In this scenario the MDI HL7 Interface resides in a hosted environment in the cloud. The EHR Server application ‘can be installed inthe cloud as wel, or be installed on premise atthe customer site The hosted MDI application can ‘be connected to the FHR application by one of the following secure connections based on the capabilites ofthe EHR application; © HTTPS © WebDay * Secure VPN ELI ECG devices connect to the MDI application using a secure wireless (802.11) communications to the MDI hosting site Operating System Environments ‘The MDI HLT Interface can run on the following operating systems: Windows 7 Professional, 64 bit Windows 8.1, 64 bit Windows 2008 Server, 64 bit Windows 2012 Server, 64 bit Phe MDI HLT Interaee ean be run in a virtual environment HL7 Interface Setup Implementation goals for the HL interface are Simplicity of implementation, process, and personnel Highly reproducible proces ‘Non-lisruptive o customer [Nonclisruptive to BHR vendor In order to obtain these goals Mortara shall engage with an EHR vendor fo design and test the interface prior to deployment to any mutual customer. This design and test phase yields ‘© Interface template: © used for deployment forall mutual customers ‘9 reduces the labor effort associated with interface customization ‘Implementation process: well defined roles and activities © reproducible Interface Technology Overview The MDI HL7 Interface supports both TCP/IP (sockets based) and file share-based communications. TCPAP is the preferred method of communications for 11.7 interfaces as it eliminates te risks associated with File share security and setup. ‘When using HL7 over TCPAP, the need arises for managing the discrete HLL7 messages, i.e message demarcation, ‘The lower-layer protocol of the MDI HIL7 Interface refers to the software which is responsible for, atthe very least maintaining the message boundaries implied by’ the application layer protocol, The MDI HIL7 Interface supports the fallowing lower-layer protocols: + Minimal Lower Layer Protocol (MLLP); default © None; raw message without a LLP wrapper Separate TCPAP ports would be established for each of ADT interface; persistent connection, listener mode Orders interface; persistent connection, listener mode ‘= Result interface; transient connection, send mode fan extemal PDF document is included as part ofthe test report, a share location shall be established in which the ‘MDI HLT Interface will create the document and the EHR shall process this document, In the deployment environment where the MDI application is not on the same network as the EHR Server application a secure share location (WebDav) will be established in which to shave the external PDF document. NOTE: The MDI HL7 imerface can support the transfer of PDF (Image-based report) 1 an EER via: + External cocument - where location of the document is included in the HL? result message * Encapsulation - PDF document encoded and included in the HL.7 result message. In the encapsulated ‘methodology, a network share is not required. Interface Configuration Checklist ‘The following chart outlines the configuration checklist necessary fo establish a bidirectional HL7 interface between an EHR/PACS application and the MDI HI.7 Interface. ‘ADT Source ~IP Address and Por | EHR. Only required if ADT feed is par of the HL? Number Interface and using TGPIIP communications. ‘Orders Source —1P Address ana | EHR. Only requires if Orders feed is part ofthe HLT Port Number Interface and using TCPYIP communications, ‘ADT Source — Network Fle Share | EHR (Only required ifADT feed is part ofthe HLT. interface and using File Share communications, ‘Orders Source ~ Network File Share | EHR Only required if Orders feed is par of the HLT interface and uisng File Share communications. Results Endpoint —1P Address and | EHR. Only eequlred fusing TCPAP communications. Port Number Results Endpoint Network File | EHR. Only required ifusing File Shere Share communications, Results POF Document Network | EHR. Only required if the POF document wil be sent as File Share a “referenced” document from the HL7 ORU massage. ‘ADT Configuration Template Mortara ‘Only required if ADT feed fe part of the HLT interface. (Orders Configuration Template Mortara ‘Only required if Orders feed is part of the HLT interface. Results Configuration Template | Mortara HL7 Interface Deployment ‘This scetion describes the high-level activities with deploying the MDI HLT interice D1 Installation — applies only to “on premise” installation ofthe MDI application ‘¢ Identify computer or virtual machine to host the MDI application ‘© Install MDI software. Interface setup: ‘© Configure the interface based on settings described in the HLL7 Interfuce Setup section. See Interfuce Setup Checklist. ‘+ Install the interface engine template configuration files as applicable to the EHR vendor, modalities and required HLT operations. 1, Copy adi.config fle (Drive:/Mortara Instrument Ine’Mdifbin; applicable, b. Copy orders.config file (Drive:/Mortara Instrument Inc/Malbin if applicable. & Copy interface engine configuration files tothe staging location; DriveyProgram Files (x86)/MirthConnect/channels. i. EHR,ADTChannel.xml ji, EHR-Orders.Channel.xml iii, EHR’ResultsChannei.xml ‘Setup IP addresses in interface engine; reference Interface Setup Checklist. Setup file shares in interface engine; reference Interface Setup Checklist; If applicable, Import and deploy the interface engine configuration files using the Mieth Connect Administration tool Deploy channels in interface engine. Start the ADT service if applicable, art the Orders service if applicable. ji _ Start the Results service Apply facility, service location, and modality filters in the interface engine for HL? ADT and Orders as specific tothe customer requirements. 8 h Verification: ‘= Test the interface using the test setup configuration. Validate the following as applicable: 8. Patient Roster - based on required facilities; if applicable b. Test Orders based on required modalities and facilities; if applicable. c. Test Results» based on required modalities and PDF reporting type. ‘The MDI HL interface is now running live in produetion mode tothe EHR system, Scheduled Workflow Considerations ‘This scion highlights some common customer expectations in regards to resting FCG and siress procedure scheduled workflow. This section explores the capabilities ofthe EHR application in regards fo these requirements, 1. Procedure Status ~ applicable to orders based interfaces ‘a, When a testis sent from the MDI HL7 Interlace without physician overread, the test procedure status will be “preliminary.” This is reflected in the HL? ORU message. b. Ifthe test has been overread by the physician on an ELI ECG device, the test procedure status will be sotto “final,” also reflected in the HLT ORU message Requirement — does the EHR update the order status ofthe procedure based on the tes status found inthe HL? ORU message? Physician Worklist Assignment — applicable to orders based interfaces, ‘a. Ifthe ordering physician is placed in the HI.7 ORM message, the MDI HI.7 Interface will retain this information, The ordering physician will be sent back in the HL.7 ORU message. Requirement — does the EHR assign the test to the physician worklist pon receipt of the test from the MDI HL? Inverface? 3. Fleetronie Signature ~ signed reports ‘4. Some customers want the electronic signature of the physician (along with date-time) affixed to the ECG report once it has been finalized in the EHR, Requirement — does the EHR have the ability to electronically sign a reviewed ECG report?” 4. Affixing a note tothe procedure 4. Itis common practice to add a “note” to a procedure. In this case it might be the physician adding a “conclusions” note in liew of electronically signing a report. The EHR then logs the name of the provider and date-time with the procedure note Requirement — does the EHR have the ability to adel a note to an ECG test? 5. Reviewing prior resting ECGs ‘4. Inthe process of « physician overreading a resting ECG, itis helpful ifthe physician can be provided access to prior ECG exams. This helps the physician determine ifthere have been changes in the ECG. Requirement does the EHR have the ability ro retrieve and visually display prior reporis? 6. ECG ~ reporting requirements Requirement does the EHR have the ability 0 send reports using the following methods = print = fae 7. BCG — procedure billing requirements 1, Itisoften necessary to have the provider bill the patient (or insurance company) for ECG procedures that have been performed, These procedures typically are composed of two ‘components: 1. technical — billing code for performing the procedure ji, professional — billing code for physician overread ofthe procedure 2 is commen for both components to be combined into a single billing code The MDI HL7 Interface reporting interface will provide information on the patient identity, modality ofthe procedure and the status of the report fora given procedure. This provides sufficient information to the EHR application to generate downstream billing. Requirement ~ does the EHR have the ability o provide a bill charging for ECG procedures? Unscheduled Workflow Considerations This section highlights workflow situations where atest i performed without scheduled order and patient demographic information. This situation can oceur for a couple of common reasons: + Emergency situation; test must be performed prior to order being available. Order was not uploaded tothe device prior to performing the procedure. Key challenges to the EHR application for unscheduled tests are how does it 4, reconcile the text to the correct patient?” assign the encounter #2 ©. assign the order #2 EHR applications will behave differently when receiving atest result without an assoctated patient (MRN), Encounter # or Order#. The purpose of this section is to identify how the EHR will respond to an unscheduled test and what workflow provisions must be put into place to overcome the limitations of the unscheduled tests Possible behavior ofthe EHR to receipt ofan unscheduled tes: © EHR will reject the test (© This requires the device o the interface to reconcile atest with an order which in turn requires a re-send of the test to the EHR application © BHR will ereatea unique “unsolicited test” order asa placcholder for the test to be matched to (©. This requires a user of the EHR to manually associate the test withthe correct patienV/encounter. © EHR will “receive and hold” the test. Is not associated with any order (© This requires a user of the EHR to manually associate the test with a newly ereated order that species the patienVencounter. Once the test information has been reconciled to the correet patient, encounter and order number; the unscheduled ‘workflow resembles the scheduled workflow. Resting ECG Modality Clinical Parameters of Interest A testing ECG report consists ofthe Following categories of information: |. Patient identification and recording information 2. Measurements 3. Interpretation 4. ECG Waveforms. isplayable Reports {A displayable report represented by @ PDF document contains all of the information outlined above. Being a PDE ‘document it has limited editing capabilities for clinician annotation. The diagram below depicts atypical resting, ECG report in PDF format M Wo pp LL Fe Lh ft Ld PULA ee ee ee ECG Reporting Template Many clinicians find it useful to display an! elt the discrete data fom a resting ECG report. This ean be done by extracting information in eategories 1-8 from Clinical Parameters of hnerest into what is called an ECG reporting template, The diagram below provides a graphical presentation of an ECG reporting template. This template provides the ability to view and optionally edit ECG report parameters. The “Interpretation” eld contains the diagnostic findings ofthe ECG exam, The original findings are generated by the ELI ECG deviees. The physieian then reviews the evidence of the ECG report (.e., ECG waveforms from the PDF document) and enters their ‘conclusions inthis interpretation field HL7 Definitions This section defines the Mortara Devi (MDI) HL? interface specifications. Specifications will be resricted tothe following HIL7 message types: Apr ‘ORM OMG ORU - modality specific MDM - modality specie Common HL7 Message Segments ADT, onders (ORM or OMG) and results (ORU or MDM) messages contain common HLT message segments. This section will define those message segments, definition and database mappings. Common message segments defined in this setion includes MSH EVN PID pvi PDI Required fields are shown as bold REQUIRED FIELD. Optional fields are shown as OPTIONAL FIELD within the field description MSH ~ Message Header Segment MSH Segment Example MSH] *~\8[EHR| MyHospitall|}20120223123704] | ORMA0O | AG* wGWs1xUyYnGCstzS*[P|2.5||ALINE|USA, MSH Segment Definitions and Mapping Field Separator 1 . Message Encoding arate: 7) ae ¥ Component Separator * “Repettion Separator \. “Escape charactor __Subcomnponent separator Sending appitin afew Sening fact 1 Name) a] mnsaar 1] racy sonetmes rmisonarom te ADT tmessoge The channel have default acy nok _ present ening appiatin [= = = ecg fat Name] é Dstetine message was crested 7 anomToE mia espe type 33 ont 7 ‘Message ever ype (ede) 32 [oot 1 eta rT Ta T ven toes Use ea ifthe event type odes nt supported the ‘Unga message ending application) 7 eemaaea HL mesage status (P production, Tas) |r| THU message version [as ‘Aecept Acknowedgenont pe AL ‘Appietion Acknowiedgement WBS ae Ne ‘Country Code a [se EVN - Event Type Segment EVN Sogmont Notos "The EVN segment is only required ifthe HIL7 message event type code is not specified in MSH 9.2, In that ease, the “only field required from the E'VN segment is the event type code. All other fields are ignored. EVN Segment Definitions and Mapping Message event type [eode) Reference HL Table 002“ Event ype Use Eva the event ype codes not supported nthe MSH segment, PID - Patient Identification Segment PID Segment Notes Following PID segment fields are not processed: ‘Alternate Patient 1D ‘Adress Contact information Mother's information Language Marital status Religion Alias Any fields after PID-18 1D Segment Exampl 1D 1|30000K| 6842-458} |Buckmaster™istofer| 19790918 1M] [B|1012 MCLAUGHLIN ROAD®*BRIDGEVILLE*PA*15017| |(412)221-8056] || ||187148304 D Segment Definitions and Mapping Patient Last hae Si —[buckmaster Patient Fst Nome 52 [esol Patient idle Na 5a Patient ate of ith 7a aaa Patient Gender ab Supports 7S Take ODOT Patient Race we W: Whe B-aice A-Asan H= Hispanic e-Esmo, P—Pobeson | o-other Patan Recount abe 7a sara Thane | Pio present, 10-18 wit ae peacedence overev129 8 PV1 - Patient Visit Segment PV1 Segment Notes (Only the fields defined below are processed by the interface. PV segiment fields of note that are not processed are * Admit Doctor * Financial Class ‘Sevondary Visit Number ~ some EHR applications send a “secondary visit number” in PV1-19. This visit number is distinct fiom the Encounter (visit) Number found in PID-I8. In such cases, the Secondary Visit Number will be sored as a user defined field in the associated order. PV1 Segment Exampl V1]41]R]ED43]R} | |]ODR, ATTENDING] ||| ||] 11110000} PV1 Segment Definitions and Mapping Patient Case eae Supports HL 25 Table 000825 folows undefined ‘e -emergeny ‘o~eupatient prea ‘nr=rmcaring Copiers 1 daypatent ‘esgred Patent aeation at Department Patent Room ada ‘Attending Doctor Name 72-78 | ORANGE Tame Format Pret (75), rst (7.3), ile 74), ‘ast rame(72), suff 5) ateing oto a Referring Doctor Hama 2-85 Tae Forma Pret (85} Fret (63), Mia (8.0, Last rome 6.2), sute8 Consuting Doar ar Consulting Doctor Name 32-95 Tame Fara Pete (9}, Fist (2.3), Mii (9.4, Lastname (92, ste.) Palen Azaunt Namba a % Encounter, Vit Numbers ising ov present, Pb-28 wilt precedence over PY 1-9 NOTE: sccondoey wit mbar spectieg a 91-19; thisvalue s mapped to 3 user hind eld inthe seco PD1 - Patient Additional Demographic Segment PD1 Segment Notes ‘The PDI segment is only required ifthe “Family Physician” information i required as part ofthe report sent from the interface tothe EIIR application, This segment is typically included in the order message (ORM oF OMG). Only the PD1-4 field is supported. ll other fields are ignored PD1 Segment Definitions and Mapping Primry Cate Doctor Name Tama Format Prati (46), rst (43), Mie (88) Lastname 2), sue 5). ADT (Admit, Discharge, Transfer) Messages ‘The MDI HL7 interface is able to receiving ADT messages (HLL? ADT). These messages contain patient demographic information that are then stored by the MDI application; which is then used for patient selection fora resulting ECG exam. This patient demographic information can be used inthe following ways: ‘© Used for patient selection by participating Mortara diagnostic deviees. This would be the method of choice {or identifying a patient if]an orders based methodology is not available, ‘+ Updating patient demographics for associated orders; via patient MRN and account number. ‘The MDI HL7 interface supports HL? ADT Messages AO] ~ A62, These event code types can be configured (Ont) based on customer/EHR requirements. NOTE: A19 (Patient Query) is not supported. Messages that cam configured but not enabled (by defautt): AIS Als A Azo A24 25 A26 az 37 Aas ASI 36 37 38 A539) A60 20 ADT Message Segments ADT messages shall consist ofthe following message segments. Some ofthese sezments are optional based on imertce requirements discussed prior in this document MSH EVN PID Ppl vi MG (only required for merge message type transactions; see below, MRG - Patient Merge Request Segment ‘The following are the field definitions of a patient merge request - MRG segment ‘win | 453434] || 50000 MRG Segment Definitions and Mapping rior Patent eter tt 1 [asiese ra rio Patent Account Numbar 5 sooon | encoun Wa Nomar Order Messages ORM - General Order Message OMG ~ General Clinical Order Message The MDI HLT interface is able to reecive onder messages (ORM or OMG). Itis preferable if the EHR application sending the order request can filter orders based on the modalities of interest. I iltering cannot be provided by the EHR application, the MDI HL7 interface ean filter the order requests by modality. The MDI HL7 interface supports the following types of HLT ORM or OMG messages control types (see ORC): New (NW) Cancel (CA; OC, OD) Update (XX, XO) HoldRelease (HD, RL}; not supported ‘The ORM or OMG order messazes consist ofthe following message segments, Some ofthese segments are optional based on interface requirements discussed prior inthis document. MSH PID PDI Pv orc OBR ‘The following is a sample HIL7 ORM message request for a resting ECG procedure. The MDI HL interface ean be customized to receive HI? ORM messages with varying formats. This sample message will be used in the specification ofthe supporting order message segments. MsH|*-\&|NyHospital ||| 20120223123704] |ORM*O0A | AG* wGWz1xUyYnGCsteS*|P [2.51 | |ALINE|USA PID| 1 [20000] 6842-458] | Buckmaster Kristofer] |19780818] Ml [8] 2011 MCLAUGHLIN, ROAD**BRIDGEVILLE*PA"15017} |(412)221-8056| ||| [187148304 P1|1]R]€D°3] || |]OAOR. ATTENDING] [111/111 ]120000] {1111 LI /IITITIEIIEI111120121035082800] (ORC|NW |ORM1234EHR| Sq}OOgSGOG2NBXqCIBRCg| ||| | |20121015082500] ID*Dr. | |ID*NAME| R| | ORM123| 9qitOOgSGOG2NBXACIBRZG| 930059ECG TestL.| | {2011032475631 | 20110114181056] || 111111 [1 }20120223123544 |||] |***20120901080000%R| || WALK|Chest Pain| || ||20110114175631 || |111 22 ORC ~ Common Order Segment ORC Segment Notes Only the felds defined below are processed by the interface. ORC segment fields of note that are not processed are: © Allficlds after ORC-10 SSC (status change) order control types are not supported. Parent orders with quantity-timing is not supported. The rationale behind this is based on reporting requirements of the EHR, For example let's assume thatthe MDI-HL7 interface generated a unique order number based on quantity timming. When the report is submitted by the MDI-HL7 interface to the EHR application, the unique order number associated with that report will not match any placed orders in the EHR. As a result, the report will be rejected ‘Therefore itis incumbent that the EHR issue orders with placed order numbers that it generates such that reports ‘based on those order numbers can be sent hack tothe EHR and resulted appropriately ‘ORC Segment Example ‘ORC| NW JORMI23°EHR|9q}tOOgSG062NBXqCI8RZ| || || |4%*20121015082500|ID"br. Al |]DANAME| ORC Segment Definitions and Mapping ‘Order Control T Supports folowing conta types + N= new acer + 99,10" update onder 1 HO—hottonder Does ot separ llontoltypasin H7 25 table 10119; most natably SC acer Order Harber ey ORME present, OBR-2 aks precedence ove RC” 2a acer Appiaion az am Nari of raquestingapaheton ‘Order Number ‘rer number deed fom Placards Number ‘Order status 5 Supports mort orde eats types defined nL? 25 abl 0038 ‘Order Star Tine (Quanty Fino) 7a est scheduled pavonn tine present, 08827. aes precedence over ORC ont date pesent lin tne based on coment Emered by FTE 1D of peron entering the oder Entered By Name To2= 106 Teme of pets entering the ore Pref (106), Fis 103), ie (204, Last ame (102), ute (205) OBR - Observation Request Segment OBR Segment Notes Only the fields defined below are processed by the interface. OBR segment fields of note tht are not processed are ‘© Fields of the OBR segment that are related to “result message = Allields after OBR-31 "only Parent orders with quantity-timing is not supported, See notes regarding this in ORC section, ORC Segment Example (088 | |ORM123|9qhtOogscoG2nBxqCIsRZe|93005°ECG ‘Test*L| | |20110114175631 | 201201141810561 || || |||] ||[201202231235.4a] | [R| |***20120901080000%"R| || \Watxi Chest aia ||| |20110118175631] (1111111 OBR Segment Definitions and Mapping Pacer Order Numbee 2a | ORME Ipesent, 82.1 tales precedence ver O8C2 Pacer Appaton Pan Tame of requesting applestion| ‘Order Number ‘Ojder number derived from Pacer Oder rivera Service Tenor a) an | Procedure moday. lies CP Coses red 93005 (reminary wth waveformsand interpretation), 8300, $3010, Suess 92015, 53036, 93017, 93016, 95320, 93325, 93350, e452 Note 93224, 95225, 03226, 93227 ‘order FOG, STRESS, HOLTER, Tranated from the Universal Serie 1, 0884 “Gra Sar Te (Guan Ting) ra | oR Test scheduled perform tne 000 present, 08827 takes precedence over ORC TA ony date provided ‘Order Prot aunty Tina) oa U= undefred {ow peony ANASAP eaion For Study a ear vain = 24 Result (ORU) Messages ‘The ORU result message can consist ofthe following message segments, = MH = PID - om = onc = 0B The definitions for these seaments apply tothe resting ECG, stress testing and Holter monitoring modalities Fields shown are configured by default for ECG modality. HL? Configuration ean be changed to support additional fields or modification of default fields (MSH) Message Header MSH Segment Example IMSH|*-\&EL1*93005} |EMR*93005| MyHospitall20130102160413] |ORU*RO1 |FA7IUqBHEU=xMSY7587i112.51 | IALINE| eng, MSH Segment Definitions and M Feld Separator 1 v Message Encoding Gharocors 2 ae ¥ ‘Component Separator = Repetition Separator \ “tseape character &_-Subeomponent Separator Sending appaton Sif Terra Code for Observation Tanke 32] S005 | Configurable est ype ee nk} 53005 Resting 12 lead ECS Code the ame fragrant ems MSH-3-2, MSHS-2, and Receiving applation eae m Code or Observation Tasks 52) 93005 | Cenfigraie es ype ee or 93005 Resting 12 ead 6 Code he ame for sgmant aa ceiving feityb Nama) | aigtspaat Datetie message was created 7 | aoraai0nsco0r3 v unica Message type 31 Pomu ¥ ‘Message event ype fade) 2 | ROH ¥—[ Reernce AO Table Even ype ‘Uigue nssage ID ending apical 3 Fara HUY message status (Production, tes] | P eceptAcaowedgement ype | Ropéetion Acknowledgement type (PID) Patient Identification PID Segment Example PID|200X% | 6842-458| | Buckmasterristofer| |19790918]M]| [B|1011 MCLAUGHLIN, ROAD**BRIDGEVILLE*PA15017| |(412}221-8056 | | ||]187148304 PID Segment Definitions and Mapping Patient enter exter) 2 [oxen Patient denier ist 3 [eas — Patient Fist Name 32 7 — Patient ie Name sa Patient Dat of Birth 7 rae wanes — Patient Gender 2 tw Suppor HU? Patient Race we Wie whte 8-8 A-Asin = Hspane Camera non etek P-Pobynesan NMawasen O-ather U= Unknown oes not use HL? 25 Teble 0005. Favent acount mbar ie [armas Tene | Encounter, vei Numbers over Pv 139 (PV1) Patient Visit V1 Sogmont Example PVLIR|ED*3|R| | IDADR. ATTENDING II*67146904) Patan lee 2 /R Supports HLT 25 120/004 35 folows undefined “ecamergeney “outpatient ‘wopresdmt ie arering “probeetnes ‘enconmercal “vy dayeatent signed Patent weston ae Department ation Room a2 [3 ‘Atending Docor 10 7a [6 ‘Attending Doctor Name 72-76 | ORATTENDINS Pret (7.0, Fest (73), Male (7, Lascname [2 suf (7.5) efering Dacor a Referting Doctor Name 32-88 Pret (66, Fest), Mite 8, Lastname 2, suo (5) ‘ongoling boceriD a ‘Consulting Doctor Name 32-98 Pref (96), Fist(33), Mile (3.4, Last ne (8.2, su (25 Patent Account Number a aaa 7 using ov present, PO-18 wil ake precedence over PV 118 NOTE secondary wisi ruber specie in PV1-20; ‘efine lain the aesoratd rer. (ORC) Common Order ORC Segment Example ORC| [ORM123*EHR | 9qitOOgSGOGZhBXqC| | | |2013010215594AR| | |DADr.A] ‘ORC Segment Definitions and Mapping Placer Orde umber zi] Oia Ye | present OBR. lakes precedence over ORC 2a cer Appeaion 22 ene Nani oregon ashen, ler Order Number 3 | sqtoogscoaaner Filer order number derved fron fer merace se ‘Grav Sar Tame (Quant Tina) Ta | 2eisBIaSSS ‘Teak cedaled poor tine present 088-274 ake precedence over font date present in time based on Teron 7s Te Test rorty “ur -vdeined “VU —tom pronty "e—Rowtine ASAP SiaT Entered 1) iar 10 of pesan enteing the order Entered y ame 02 | bea "Name of person entering theo 106 Name Format Pree (106), Fst (103), ile (20.2, {st nome (10.2), Sufi (205). 28 (OBR) Observation Request OBR Sogment Example (0BR| |ORM123°EHR|9qhtOOgSGOGZh—XaC |930059CS Test||HIIIIIIIII1 1] 1201301031000} ||P|***201301021559"R | | ||Chest Pain] ID¢NAME| ‘OBR Sogmont Definitions and Mapping Pacer Order Ruber 2a [oni [pero 0382.1 ates precedence over ORCL hae Aplstion aa [ene Name of equsting appiton| Filer Order Numba 3 | sa0nseo Fie order aber ceed rom ar RaTSSe seananae Tavera Seize enter asics 7 racer madaiy- Utes Codes ees ‘3000, 93005 93010 sess 59015, 83016 98017, 9308, 9320, 93325, 93350, Holter $3224, 92225 93226 93227 "veal evi Genie Nnemonie a [eer Confmed Date Tene B Resa Raper Sates Cranas Oe Tas Te te time when cncanoveread the repr. wyhiaainmss “Tener at =F Result Status Suppor HUT ZS Table O13 fotows: ina | -pretminany ‘ide iar ne (Guay Tne) wa | wT Tei sched peor te so presen, 088274 takes pracodenes over ORC74 Honk dte provided, add arent tine, ‘rer Py evaniy Ting) we Te U= enletned tL -low prity RoRoutne AnASAP S-STAat Tesion Fors Conve By pal Ras erate Name Format Pref (326), Frst32, ae 324 {ast rame (22), Sue (32.8) rent, 08f32 thes precndence over OFC-32 29 Resting ECG Example Message ORU Messag sh *~\etrsa005| e305) MyHosptal}2012010216043|jORUMROL[Fa7IUGBHEL AMSYTSS}25] ALINE eng 10 oon 6822-453) Buckmaster 19790818 [6011 MCLAUGHLIN ROAD>*BRIDGEVILES?APISO17) [412}21- 056 ||187248308 vs ]R}e0°3)R| | }O8DRATTENCING| |||] 1387288308) ‘oRc| jonw2a-Ev|oqnoogscosehsxqC]]201302021859"R||]DAI ‘ont jonvn.23eHk|sqit00gs

    You might also like