Transcription
Lab Interface SpecificationLast Revision Date: 2017/05/18
All information contained herein is confidential andproprietary to OTTR, Inc.Table of ContentsTABLE OF CONTENTS . 2INTRODUCTION . 3GENERAL OVERVIEW . 4OTTR INTERFACE ARCHITECTURE . 5COMMUNICATIONS OVERVIEW . 6APPLICATION SYSTEM TRIGGER EVENTS AND SEGMENTS . 7MESSAGE SEGMENTS . 8MSH – MESSAGE HEADER . 9PID – PATIENT IDENTIFICATION SEGMENT . 12NTE – COMMENT/NOTE SEGMENT . 15ORC – COMMON ORDER SEGMENT . 16OBR – OBSERVATION ORDER SEGMENT . 18OBX – OBSERVATION RESULT SEGMENT . 22APPENDICES . 26APPENDIX A: FILTERING OPTIONS . 27APPENDIX B: OTTRFEED LAB TRANSLATION TABLES . 28APPENDIX C: OTTRFEED LAB REPORT PROCESSING . 28APPENDIX D: OTTR LAB ARCHITECTURE . 28APPENDIX E: GLOSSARY . 29DOCUMENT REVISION HISTORY . 31OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.2
All information contained herein is confidential andproprietary to OTTR, Inc.IntroductionThe OTTR inbound lab interface accepts standard HL7 transactions in an ORU event type format froma hospital lab system, EMR, or other external lab source. This interface is used to store both discretelab results as well as textual lab report results. All of the lab data that is included in the HL7 iscaptured in the database as sent so as to meet CAP regulatory compliance, however, additionalconfiguration allows for displaying only clinically relevant labs based on the transplant program andtreatment phase of a given patient. There are configuration options for special handling of pendinglabs, corrected labs, lab results with comments as well as different options for processing textual labreport results depending on how the source system is generating those transactions.Benefits Include: Providing a view of a patient’s clinically relevant labs in a concise format based on individualcustomers’ needs.Contributing to workflow by routing results to the appropriate personnel.Providing the ability to view and trend labs side by side with medications and medicationdosage in both discrete value comparison as well as through graphing.Allowing for in-application retrieval of all lab data on a given patient from multiple sourceswhich may include multiple interfaces and manually entered labs.Providing the ability to configure lab rules to flag a particular lab for review. This is in additionto the display of normal reference ranges and abnormal flags. These rules can be set up at theindividual lab level to evaluate of a set of labs for a given patient over time to alert increases ordecreases outside of an acceptable threshold.Providing visual cues which indicate un-reviewed labs, corrections, additional comments beingpresent, or a lab requiring attention due to breaking a particular lab rule.Storage of multiple versions of a lab report, such as Microbiology or Pathology with the abilityto compare changes between different versions at any time.Providing the ability to handle both discrete and report results from a single interfaceconnection provided identifiers exist to differentiate discrete results from report results.Providing the ability to post results as both discrete and as text. This allows for storage of anHLA report as well as the different components into individual locations.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.3
All information contained herein is confidential andproprietary to OTTR, Inc.The lab interface can be configured based on how the source system is sending the data and how theclinicians would like to see that data. The interface has also been designed to handle anyadditions/changes to the compendium of tests performed by the source system by dynamicallyadding new codes to the OTTR database so new/modified tests will not result in errors.General OverviewThe Lab interface is inbound to OTTR (outbound from EMR/registration system to OTTR).Below are general assumptions, limitations and restrictions about the interface. This specification describes a real-time interface between a current or potential customer ofOTTR, Inc.All interface messages are expected in an HL7 format, up to version 2.3.All data can come directly from the source system, or flow through an HL7 Interface Engine toOTTR.Unless otherwise indicated, the following terms have the specified meaning in this document: “OTTR”: OTTR, Inc., OTTR application – Organ Transplant Tracking Record.“OTTRFeed”: OTTR, Inc., HL7 Transaction Parser.“Sending System”: Refers to the A.D.T. admissions system, or the HL7 Interface Engine used atthe facility.“Site”: Potential or Current customer of OTTR, Inc.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.4
All information contained herein is confidential andproprietary to OTTR, Inc.OTTR Interface ArchitectureThe typical OTTRFeed interface consists of multiple running copies of the ottrfeed.exe binary. The toptier process is a Windows service, and its sole responsibility is to keep the control (a.k.a. monitor)process running. It will restart the control process should it stop and pass the correct configurationfile to it. The second tier process is the control process. Its job is to monitor, send command, andrestart the third tier processes as needed. The third tier processes are the flows themselves: Input,filter, and storage.Figure 1 - OTTRFeed Interface Top Level Data Flow DiagramThe diagram about shows a simple view of the typical interaction between the OTTRFeed processesand external entities.The HL7 Sending System is typically an interface engine that is duplicating the messages from anotheroutbound HL7 system. In this case, OTTRFeed monitors a TCPIP connection port feed for traffic forinbound transactions. Upon receipt of a transaction OTTRFeed only responds with simpleacknowledgements or errors. Data comes in over a port determined by the configuration file to theinput flow and a copy of the transaction is stored on the interface server in a queue (Input Sink/FilterSource or “Spool”) for further processing.The input flow’s output sink serves as the source for the filter flow. The filter flow’s job is to discard alldata we do not care about (non-OTTR data) and then pass the remaining data to the storage flow.The filter flow receives filtering criteria from the OTTR database to determine whether to keep orOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.5
All information contained herein is confidential andproprietary to OTTR, Inc.discard the data. If the data is not valid HL7 or produces an error for some other reason, the file issent to the error sink. If the data did not match the filtering criteria, then the file is sent to the discardsink. If it does match the criteria, the file moves to the output sink (Filter Sink/Storage Source), whichis the input for the storage flow.The storage flow, like the filter flow, grabs similar matching criteria to identify the patient. The storageflow then processes the transaction and stores the data in the OTTR database according to thebusiness rules defined in the interface configuration. If it fails, the file will be sent to the error sink. It ifsucceeds, the file will be stored in duplicate sink.The OTTRFeed Control process not only manages the individual flow processes but also provides amechanism for communicating the current interface status to OTTR Administrators. It contains asimple web server that listens on a port defined in the configuration file. From a web browser theOTTR Administrator can monitor and issue command to OTTRFeed. The control process is alsoresponsible for writing to the log file as the flows send it messages.Communications OverviewAs described, the OTTRFeed software is a store-parse-and-forward system. It receives HL7transactions from the sending system, stores the messages to a temporary directory on the serverwith a naming convention that utilizes the date and time of when OTTRFeed received the transactionoff the socket (CCYY-MM-DD-HH-MM-SS.nnn.hl7). OTTRFeed then parses the HL7 transactions basedon rules setup in a configuration file then posts the data into the OTTR database through a series ofSql statements as per OTTR Standard.Communication between the sending system and OTTRFeed/OTTR software utilizes TCP/IP protocols.A typical installation utilizes HL7 version 2.3 encoding, with the “HL7 minimal lower-level protocol”and the TCP/IP protocol suite. Message transport is handled by the TCP/IP protocol suite, withphysical connection via twisted pair (100 or 10 Mbps).The data flowing to OTTRFeed is formatted according to the HL7 version 2.3 standard, using the HL7“minimal lower layer protocol” and will be either positively or negatively acknowledged with an ACKmessage.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.6
All information contained herein is confidential andproprietary to OTTR, Inc.The expected sequence of events for sending an HL7 message from the Sending System to OTTRFeedis:1. The Sending System opens a TCP connection (stream) to OTTRFeed.2. The Sending System sends an HL7 message, according to the minimal lower layer protocol. TheSending System keeps the TCP connection open after sending the HL7 message.3. OTTRFeed takes and stores the message to the hard-drive and returns a normal (not enhanced)acknowledgment message back to the Sending System.If the Sending System wishes to do so, it may leave the TCP connection open, going from step 3 backto step 2 for the next message. Only one HL7 conversation (data stream) may occur on each TCP port.HL7 messages include only normal data messages. OTTRFeed does not expect any initializationmessages.OTTRFeed can recover from temporary (within configured timeout) TCP outages without intervention.OTTRFeed does not currently have an automated notification method of a problem but include aweb-browser feature which can be used to monitor the status of the interface and the interface flows.For full details of the HL7 protocol, refer to http://www.hl7.org.Application System Trigger Events and SegmentsThe following table associates the trigger events and segments generated from the Sending SystemHL7 standard to OTTR. The tables are prepared from the perspective of the receiving system(OTTRFeed).Table 2: Application System Interface Triggers and Segments GeneratedOTTRFeedOTTRHL7 ndardNotesProcessingORU R01Process Observation Result Add/UpdateN/AOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.Segments ]{[NTE]}}}[DSC]7
All information contained herein is confidential andproprietary to OTTR, Inc.Message SegmentsThis section provides detailed description of segments that may be sent by the Sending System. Onlythose segments included in the “Application System Interface Trigger Events and SegmentsGenerated” table are described. The following guidelines should be observed when interpreting thesesegment layouts: Seq Sequence No. ColumnThe sequence number of the field or component indicates its ordinal position within the segment.Note that characters preceding the first field separator do not have a field number; the first field isbetween the first and second field separators for segments other than MSH. Dest Data Len Destination Data Length ColumnThis column is the destination application maximum data length of the field or component.A value of “0” indicates that the field or component is not present, and that the sendingsystem should not forward on the field unless noted in the column, “Special Processing forDestination”. Data Field Name ColumnThis column contains the HL7 descriptive name for the data item. Site or vendor specific namesmay be noted in parentheses. Any field name that is bolded is sent to the destination. Comments ColumnThis column references nuances as related to the receiving application. Special Processing for Destination ColumnData in this column represents processing that will be done by the Sending System. Any field thatis not bold and is shaded is not supported by OTTRFeed.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.8
All information contained herein is confidential andproprietary to OTTR, Inc.MSH – Message HeaderThe MSH segment describes the intent, source, destination and selected specifics of a messagesyntax.SeqData Field NameMSH – MESSAGE HEADERComments1DestDataLen31Segment IDField Separator24Encoding Characters2.11Component Separator2.21Repetition Separator2.31Escape Character2.41Subcomponent SeparatorOTTR: Processed.OTTR OTTRFEEDStd: “ & ”3180Sending Application4180Sending FacilityOTTR: Processed.Populated bySending System.OTTR: Processed.Populated byOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.“MSH”OTTR: Processed.OTTR OTTRFEEDStd: “ ”OTTR: Processed.OTTR OTTRFEEDStd: “ \&”OTTR: Processed.OTTR OTTRFEEDStd: “ ”OTTR: Processed.OTTR OTTRFEEDStd: “ ”OTTR: Processed.OTTR OTTRFEEDStd: “ \ ”Special Processing for DestinationSeparates adjacent components of datafields where allowed.Separates multiple occurrences of a fieldwhere allowed.Escape character for use with any fieldrepresented by an ST, TX or FT data type, orfor use with the data (fourth) component ofthe ED data type If no escape characters areused in a message, this character may beomitted. However, it must be present ifsubcomponents are used in the message.Separates adjacent subcomponents of datafields where allowed. If there are nosubcomponents, this character may beomitted.9
All information contained herein is confidential andproprietary to OTTR, Inc.SeqDestDataLenData Field Name5180Receiving Application6180Receiving Facility726Date/Time of Message89407SecurityMessage Type9.1Message Type9.2Trigger Event1020Message Control ID1103Processing IDOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.MSH – MESSAGE HEADERCommentsSpecial Processing for DestinationSending System.OTTR: Processed.OTTR OTTRFEEDStd: “OTTR”OTTR: Processed.OTTR OTTRFEEDStd: NullOTTR: Processed.OTTR OTTRFEEDStd: Date/Timemessage was createdfrom sending system.YYYYMMDDHHMM[SS][SS] is optional.OTTR: Processed.OTTR: Processed.Translate using“Application SystemInterface TriggerEvents” table.OTTR: Processed.ORUOTTR: Processed.R01 / R03OTTR: Processed.(Unique)OTTR OTTRFEEDStd:Source’s MessageControl IDOTTR: Processed.OTTR OTTRFEEDStd:“P” Production,“T” Testing10
All information contained herein is confidential andproprietary to OTTR, Inc.SeqDestDataLen1208130140815-210Data Field NameVersion IDContinuation PointerOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.MSH – MESSAGE HEADERCommentsFlex per region.OTTR: Processed.OTTR OTTRFEEDStd: 2.3OTTR: IgnoredOTTROTTRFEED Std:Not SupportedOTTR: Processed.Special Processing for DestinationUsed to link subsequent HL7 message filesdue to OBX limit’s on sending system.OTTR: IgnoredOTTR OTTRFEED Std:Not Supported11
All information contained herein is confidential andproprietary to OTTR, Inc.PID – Patient Identification SegmentThe PID Patient Identification segment is used as the primary means of communicating patientidentification and demographic information. This segment contains permanent patient informationthat is used to identify the patient in the database for which the result should be stored.SeqPID – PATIENT IDENTIFICATIONData Field NameComments12DestDataLen30128Segment IDSet ID – PIDExternal Patient ID - PID“PID”OTTR: IgnoredOTTR: Processed.3128Internal Patient ID - PIDOTTR: Processed.4128Alternate Patient ID - PIDOTTR: Processed.55.19030Patient NameFamily NameOTTR: Processed.OTTR: Processed.5.230Given NameOTTR: Processed.5.330Second or Further GivenName or InitialsOTTR: Processed.630Mother’s Maiden Name730Date/Time of Birth81Sex9104810Patient AliasesRaceOTTR OTTRFEED Std:Not SupportedOTTR: Processed.OTTR OTTRFEEDStd: YYYYMMDDOTTR: Processed.OTTR OTTRFEED Std:M-F-XOTTR: Ignored.OTTR: Processed.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.Processing into OTTRValue is not updated in database for astandard laboratory interface. Field can beused to filter against patient population.Value is not updated in database for astandard laboratory interface. Field can beused to filter against patient population.Value is not updated in database for astandard laboratory interface. Field can beused to filter against patient population.Value is not updated in database for astandard laboratory interface. Field can beused to filter against patient population.Value is not updated in database for astandard laboratory interface. Field can beused to filter against patient population.Value is not updated in database for astandard laboratory interface. Field can beused to filter against patient population.Value is not updated in database for astandard laboratory interface. Field can beused to filter against patient population.Value is not updated in database for astandard laboratory interface.Value is not updated in database for a12
All information contained herein is confidential andproprietary to OTTR, Inc.SeqDestDataLenData Field NamePID – PATIENT IDENTIFICATIONCommentsProcessing into OTTRstandard laboratory interface.11225Patient AddressOTTR: Processed.11.160Street AddressOTTR: Processed.11.260Other DesignationOTTR: Processed.11.325CityOTTR: Processed.11.430State or ProvinceOTTR: Processed.11.520Zip or Postal CodeOTTR: Processed.11.630Country Code11.711.9120OTTR: Processed.OTTR OTTRFEED STD:2 char code.OTTR: Ignored30County CodeOTTR: Processed.1321Phone Number – HomeOTTR: Processed.1421Phone Number - BusinessOTTR: Processed.1550Primary Language161Marital Status1718325ReligionPatient Account NumberOTTR: Not Supportedvia interface.OTTR: Processed.Value is not updated in database for aOTTR OTTRFEED Std:standard laboratory RCED4SEPARATED5WIDOWED6COHABITATINGOTTR: Not SupportedOTTR: Processed.Value is not updated in database for aOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.13
All information contained herein is confidential andproprietary to OTTR, Inc.SeqDestDataLenData Field NamePID – PATIENT IDENTIFICATIONComments19128SSN - PatientOTTR: Processed.20128Driver’s License Number –Patient2122201Patient Mother’s IdentifierEthnic Group23-2829012Patient Death DateOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: IgnoredOTTR: Processed.OTTR OTTRFEED Std:- Unknown- Hispanic Origin- Not of HispanicOriginOTTR: Not UsedOTTR: Processed.303Patient Death Indicator36512Patient DischargeDispositionOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.OTTR: Processed.OTTR OTTRFEED Std:Y Deceased, N –Not DeceasedOTTR: Processed.Processing into OTTRstandard laboratory interface.Value will be updated by the interface if theexiting OTTR field is blank. Field can be usedto filter against the patient population.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.Value is not updated in database for astandard laboratory interface.14
All information contained herein is confidential andproprietary to OTTR, Inc.NTE – Comment/Note SegmentThe NTE segment contains any notes on the patient that are relative to the segment they follow in theoverall message; they can be repeated multiple times. NTE segments appearing after the PID segmentbefore the ORC segment will be stored as a Progress Note in the Comments table. Any NTE segmentafter the ORC will be stored as an order comment. Any NTE segment after the OBR will be stored as aresult comment.Seq123Seq123Seq123DestDataLen34832 KDestDataLen34832 KDestDataLen34832 KNTE – COMMENTS FOLLOWING PID SEGMENTData Field NameCommentsSpecial Processing for DestinationSegment IDSet ID NumberValue TypeCommentNTE following PID segment“FT” formatted textShown as a Patient specific comment.Stored in COMMENTS, COMMENTS TEXT.Displayed in OTTR under Patient-ChartProgress Notes.NTE – COMMENTS FOLLOWING OBR SEGMENTData Field NameCommentsSpecial Processing for DestinationSegment IDSet ID NumberValue TypeComment“NTE”OTTR: IgnoredOTTR: Processed.OTTR: Processed.NTE following OBR segment“FT” formatted textShown as an Order comment within the bodyof the report. Stored in MISC LABS,MISC LABS COMMENT field. Displayed inOTTR under Patient-Chart-Misc Labs.NTE – COMMENTS FOLLOWING OBX SEGMENTData Field NameCommentsSpecial Processing for DestinationSegment IDSet ID NumberValue TypeCommentOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.“NTE”OTTR: IgnoredOTTR: Processed.OTTR: Processed.“NTE”OTTR: IgnoredOTTR: Processed.OTTR: Processed.NTE following OBX segment“FT” formatted textShown as a Result comment within the body15
All information contained herein is confidential andproprietary to OTTR, Inc.SeqDestDataLenNTE – COMMENTS FOLLOWING OBX SEGMENTData Field NameCommentsSpecial Processing for Destinationof the report. Stored in MISC LABS,MISC LABS COMMENT field. Displayed inOTTR under Patient-Chart-Misc Labs.ORC – Common Order SegmentThe ORC segment represents a common order that has been made or is being completed. Data fromthe ORC segment is not being stored in the database. Order information is being pulled from the OBRsegment.Seq123DestDataLen331617Data Field NameSegment IDOrder ControlPlacer Control OrderFiller Control Order43Order Timing, QuantityQuantity/Timing, Interval7.2.1200Quantity/Timing, Interval,Desc7.2.2200Quantity/Timing, Interval,Hours7.3200Quantity/Timing, DurationOTTR Inbound Lab Interface Specification 2017 OTTR, Inc.ORC – COMMON ORDERComments“ORC”OTTR: Processed.OTTR: Processed.OTTR: IgnoredOTTROTTRFEED Std:Not SupportedOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: Processed.OTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: IgnoredSpecial Processing for DestinationNot stored anywhere in OTTRDo not send from sending system.Do not send from sending system.16
All information contained herein is confidential andproprietary to OTTR, Inc.SeqDestDataLenData Field NameORC – COMMON ORDERCommentsOTTR OTTRFEED Std:Not SupportedQuantity/Timing, Start Date OTTR: Processed.Quantity/Timing, End Date OTTR: Processed.OTTR OTTRFEED Std:Required to process.Quantity/Timing, PriorityOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedQuantity/Timing, Condition OTTR: IgnoredOTTR OTTRFEED Std:Not SupportedQuantity/Timing, TextOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedQuantity/Timing,OTTR: IgnoredConjunctionOTTR OTTRFEED Std:Not SupportedQuantity/Timing, OrderOTTR: IgnoredSeq.OTTR OTTRFEED Std:Not SupportedDate/Time of TransactionOTTR: Processed.Entered ByOTTR: Processed.Entered By, Last NameOTTR: Processed.Entered By, First NameOTTR: Processed.Entered By, Middle NameOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedVerified ByOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOrdering ProviderOTTR: Processed. LNCHAR FNCHAR C 10.210.32001204040401112012.09012.130Ordering Provider, IDOTTR: Processed.12.230Ordering Provider, LastNameOTTR: Processed.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.Special Processing for DestinationDo not send from sending system.Do not send from sending system.Do not send from sending system.Do not send from sending system.Do not send from sending system.Do not send from sending system.Set by an OTTRFeed flag “EnteredBy” for aspecific OTTR pers id that must exist topopulate.Stored in DATAFEED PERSON table,PERSON NUMBER ColumnLookup done on PERSON table by PERSON ID,populates Patient-Chart-Medication window17
All information contained herein is confidential andproprietary to OTTR, Inc.Seq12.3DestDataLen30Data Field NameOrdering Provider, FirstNameORC – COMMON ORDERCommentsOTTR: Processed.Special Processing for DestinationEntered By Firstname LastnameLookup done on PERSON table by PERSON ID,populates Patient-Chart-Medication windowEntered By Firstname Lastname.OBR – Observation Order SegmentThe OBR segment represents an observation order that has been made or is being completed.SeqDestDataLenData Field NameOBR – OBSERVATION ORDERComments2317Segment IDPlacer Control Order“OBR”OTTR: Processed.317Filler Control OrderOTTR: Processed.3.117Lab Order NumOTTR: Processed.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.Special Processing for DestinationIf field is valued it is used instead of the LabOrder Number.Stored in ACTIONS, PLACER ORDER NUMBERand if field is used as the Primary DocumentIdentifier for document revisions it is alsostored to DOC ATTRIBUTES,DOC ATTR VALUE. Only displayed in OTTR fordocuments as a discreet field between thesummary and body of the text document.Used as Lab Order Number if Placer ControlOrder and Lab Order Number fields are blank.Stored in ACTIONS, FILLER ORDER NUMBERand if field is used as the Primary DocumentIdentifier for document revisions it is alsostored to DOC ATTRIBUTES,DOC ATTR VALUE. Only displayed in OTTR fordocuments as a discreet field between thesummary and body of the text document.Used if both Placer Control Order and FillerControl Order are blank. Can be used as thePrimary Document Identifier for documentrevisions. Stored in ACTIONS, ORDER NUMBER18
All information contained herein is confidential andproprietary to OTTR, Inc.SeqDestDataLenData Field NameOBR – OBSERVATION ORDERCommentsSpecial Processing for Destinationfield and if field is used as the PrimaryDocument Identifier for document revisions itis also stored to DOC ATTRIBUTES,DOC ATTR VALUE. Only displayed in OTTR fordocuments as a discreet field between thesummary and body of the text document.438Universal Service Id4.131Test IdOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: Processed.4.231Test DescriptionOTTR: Processed.4.31Test Coding MethodOTTR: Processed.4.416Alternate Test IDOTTR: Processed.4.531Alternate Test Description OTTR: Processed.4.61Alternate Test CodingMethodOTTR: Processed.53Order Status715Observation DateOTTR: IgnoredOTTR OTTRFEED Std:Not SupportedOTTR: Processed.OTTR Inbound Lab Interface Specification 2017 OTTR, Inc.Stored in MISC LABS CODES, MISC LAB CODEfield. Also in LAB DETAIL,LAB DETAIL DISPLAY NAME field.Displayed in OTTR under Patient-Chart-MiscLabs-Code column, also Patient-Chart-Labs (Ifmapped or added to a flowsheet as a column).Stored in MISC LABS CODES,MISC LAB DESCRIPTION, and LAB DETAIL,LAB DETAIL LONG NAME field.Displayed in OTTR under Patient-Chart-MiscLabs-Description column.Lookup done on MI
This specification describes a real-time interface between a current or potential customer of OTTR, Inc. All interface messages are expected in an HL7 format, up to version 2.3. All data can come directly from the source system, or flow through an HL7 Interface Engine to OTTR.
