Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Inbound Document Processing
Interface Specification
Last Revision Date: 2019/01/07
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 2
2017, OTTR, Inc.
Table of Contents TABLE OF CONTENTS ........................................................................................................................................................................ 2
INTRODUCTION ................................................................................................................................................................................... 3
GENERAL OVERVIEW ........................................................................................................................................................................ 4
GENERAL OVERVIEW ........................................................................................................................................................................ 4
OTTR INTERFACE ARCHITECTURE .............................................................................................................................................. 5
COMMUNICATIONS OVERVIEW ..................................................................................................................................................... 6
APPLICATION SYSTEM EVENTS AND SEGMENTS ..................................................................................................................... 8
SAMPLE TRANSACTIONS ......................................................................................................................................................................... 8
MESSAGE SEGMENTS ......................................................................................................................................................................... 9
MSH – MESSAGE HEADER ................................................................................................................................................................... 11 PID – PATIENT IDENTIFICATION SEGMENT ........................................................................................................................................... 13 NTE – COMMENT/NOTE SEGMENT ....................................................................................................................................................... 17 ORC – COMMON ORDER SEGMENT ...................................................................................................................................................... 19 OBR – OBSERVATION ORDER SEGMENT .............................................................................................................................................. 21 TXA – TRANSCRIPTION DOCUMENT HEADER SEGMENT ...................................................................................................................... 27 OBX – OBSERVATION RESULT SEGMENT ............................................................................................................................................. 30
APPENDICES ........................................................................................................................................................................................ 33
APPENDIX A: CONFIGURATION OPTIONS ........................................................................................................................................... 34 APPENDIX B: PROCESSING DOCUMENTS OR DOCUMENT IMAGES AS ED (ENCAPSULATED DATA). ................................................... 37 APPENDIX C: TYPICAL IMPLEMENTATION PLAN ............................................................................................................................... 38 APPENDIX D: PREVENTIVE MAINTENANCE ....................................................................................................................................... 40 APPENDIX E: GLOSSARY ................................................................................................................................................................... 41
DOCUMENT REVISION HISTORY .................................................................................................................................................. 43
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 3
2017, OTTR, Inc.
Introduction
Inbound Document Interface
OTTR’s inbound Document interface that accepts standard HL7 transactions in either an ORU or MDM
event type format from a hospital system, EMR, or other external transcription source. This interface
encompasses both clinical result reports such as Radiology and Pathology, as well as text based
documentation such as Transcription. This interface is used to store and update preliminary, final and
addendum reports in the OTTR database with specific document types. The list of possible document
types is not limited, as any type built in the application/database can be used in the interface.
Therefore, any report type (such as Radiology, PFT, Cardiology, Pathology, Physician Notes,
Admit/Discharge Records, Consultations, etc...) can be interfaced into OTTR.
Benefits Include:
Providing the ability to quickly view either logical groupings of documents together or all
documents.
Contributing to workflow by routing only specific document types to the appropriate
personnel.
Allowing for the storage of multiple versions of a particular report to provide the ability to
compare changes between different versions at any time.
Additional Features Include:
The ability to include a PDF, RTF, Word Document, or other document format as an attachment
to a report. When selected, the attachment will be opened on the user’s workstation.
The ability to include a “link” as an attachment to the report. When selected, the attachment
will trigger the action of accessing/opening that document from its source location.
The ability to include the physical location of a document with the intent of accessing that
location to retrieve and store the document in the OTTR database.
The ability to use discrete data from a Radiology or Imaging report transaction such as MRN,
Accession, Facility to dynamically build a link to the images in the PACS system that are
associated to that report. This “link” would also be an attachment to the report that when
selected would trigger the action of accessing/opening that image from its source location.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 4
2017, OTTR, Inc.
With each of these benefits and features, there are configuration options which allow OTTR to custom
tailor the interface based on the desired behavior. However, the document type mapping is the
central configuration component for this interface and determines how and where a document will be
accessed in the application. This mapping is determined by data/codes in the HL7 message and any
field or combination of fields can be used. In addition, any field can be used as the document
summary as well as the unique document identifier which will allow for matching and updating an
existing document.
General Overview
General Overview
The Document interface is inbound to OTTR (outbound from EMR/document 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 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.
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 at the
facility.
“Site”: Potential or Current customer of OTTR, Inc.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 5
2017, OTTR, Inc.
OTTR Interface Architecture
The typical OTTRFeed interface consists of multiple running copies of the ottrfeed.exe binary. The top tier
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 configuration file to it. The second tier
process is the control process. Its job is to monitor, send command, and restart 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 Diagram
The diagram about shows a simple view of the typical interaction between the OTTRFeed processes and
external entities. The HL7 Sending System is typically an interface engine that is duplicating the messages from another
outbound HL7 system. In this case, OTTRFeed monitors a TCPIP connection port feed for traffic for inbound
transactions. Upon receipt of a transaction OTTRFeed only responds with simple acknowledgements or errors.
Data comes in over a port determined by the configuration file to the input flow and a copy of the transaction is
stored on the interface server in a queue (Input Sink/Filter Source 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 all data 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 or discard the data. If the data
is not valid HL7 or produces an error for some other reason, the file is sent to the error sink. If the data did not
match the filtering criteria, then the file is sent to the discard sink. If it does match the criteria, the file moves to
the output sink (Filter Sink/Storage Source), which is the input for the storage flow.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 6
2017, OTTR, Inc.
The storage flow, like the filter flow, grabs similar matching criteria to identify the patient. The storage flow
then processes the transaction and stores the data in the OTTR database according to the business rules defined
in the interface configuration. If it fails, the file will be sent to the error sink. It if succeeds, the file will be
stored in duplicate sink.
The OTTRFeed Control process not only manages the individual flow processes but also provides a mechanism
for communicating the current interface status to OTTR Administrators. It contains a simple web server that
listens on a port defined in the configuration file. From a web browser the OTTR Administrator can monitor
and issue command to OTTRFeed. The control process is also responsible for writing to the log file as the flows
send it messages.
Communications Overview
As described, the OTTRFeed software is a store-parse-and-forward system. It receives HL7 transactions from
the sending system, stores the messages to a temporary directory on the server with a naming convention that
utilizes the date and time of when OTTRFeed received the transaction off the socket (2010-01-01-15-30-
12.345.hl7). OTTRFeed then parses the HL7 transactions based on rules setup in a configuration file then posts
the data into the OTTR database through a series of Sql 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, with physical 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 ACK message.
The expected sequence of events for sending an HL7 message from the Sending System to OTTRFeed is:
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. The
Sending 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 back to 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 initialization messages.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 7
2017, OTTR, Inc.
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 a web-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.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 8
2017, OTTR, Inc.
Application System Events and Segments
The following table associates the trigger events and segments generated from the Sending System HL7 standard to
OTTR. The tables are prepared from the perspective of the receiving system (OTTRFeed).
Table 2: Application System Interface Triggers and Segments Generated
OTTRFeed
Interface
Standard
OTTR HL7 Description OTTR
Processing
Notes
Special
Engine
Processing
Segments Generated
ORU Process Interpretive Result
Add/Update N/A MSH[PID[{NTE}]]{[ORC]OBR
{[NTE]}{[OBX]{[NTE]}}}
[DSC]
MDM Process Medical Document
Management
Add/Update N/A MSH[PID[{NTE}]]{TXA
{[NTE]}{[OBX]{[NTE]}}}
[DSC]
Sample Transactions
ORU:
MSH|^~\&|TRANS|AV|OTTR||201204231147||ORU^R03|MT2011112911471756|T|2.3|||AL|NE|||
PID|||1000000888||OTTR^SARAH^T||19931016|M|||999^ANY STREET^^BROKEN BOW^NE^68641||4028675309|||||||
OBR|1||651AV|IPDOC^UNKNOWN|||201008051513|201008051513||||||||||||DOCUMENT|IPDOC||||S|||||||123123^PLNAME^PFN
AME|||PIDENT|
OBX|1|TX|||PT: PWMTEST,INPATIENT THREE ACCOUNT #: AA0000150178 |
OBX|2|TX|||REPORT: 0805-0005 UNIT #: AM00007077 |
OBX|3|TX|||_________________________________________________________________________________ |
OBX|4|TX|||DICTATED BY: PLNAME,PFNAME D: 08/05/10 1513 |
OBX|5|TX|||T: 08/05/10 1513 TTG |
OBX|6|TX|||CO-SIGNER: DOC,Cosigner |
OBX|7|TX|||ELECTRONICALLY SIGNED BY: PLNAME,PFNAME S: 08/05/10 1516 |
OBX|7|TX|||ELECTRONICALLY SIGNED BY: DOC,Cosigner S: 11/29/11 1145 |
OBX|8|TX||| |
OBX|9|TX||| |
OBX|10|TX|||DISTRIBUTION LIST: |
OBX|11|TX||| yABOAAL - Alan P CopyTo MD |
OBX|12|TX||| yGRAVTO - PFNAME PFNAME MD |
OBX|13|TX||| yHUNTAM - Amy T CopyTo |
OBX|14|TX||| yMOBLAL - Doc, Cosigner |
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 9
2017, OTTR, Inc.
OBX|15|TX||| |
OBX|16|TX|||**END** |
MDM:
MSH|^~\&|TRANSCEND|1|JCAPS|1|20120712110402||MDM^T02|51511342|P|2.4|470128
EVN|T02
PID||284xxxxx|320xxxx|0284xxxxx|Wxxxxxx^Jxxxx^A||19570324|M||||||||||0000284xxxxx|046xxxxxx
PV1|||070||||08xxxx
TXA||TPL|FT|20120712103100||20120712091942|20120712102119|20120712|08xxxx^Allxxxx^Kxxx^M^^^APRN|08xxxx|850
21|51511342^51511342||51511342||51511342.DMT|PA||AV|1|||^Bxxxxx^Mxxxx^^^^MD~7xxxxx^Rxxxxxxx^Mxxxxxxx^^^
^MD~^Transplant^Program^^^^Transplant
OBX|1|TX|REPORT|| ||||||F
OBX|2|TX|REPORT||Transplant Program and Hepatology Clinic||||||F
OBX|3|TX|REPORT||85 Any Street||||||F
OBX|4|TX|REPORT|| ||||||F
OBX|5|TX|REPORT||Sample Transcription Report for Teting ||||||F
OBX|6|TX|REPORT||REVIEWED AND APPROVED BY: ___________________________________||||||F
OBX|7|TX|REPORT|| Kxxx M Allxxxx, APRN ||||||F
OBX|8|TX|REPORT|| ||||||F
OBX|9|TX|REPORT|| ||||||F
OBX|10|TX|REPORT||CC: Mxxxx Bxxxxx, MD, Mxxxxxxx Rxxxxxxx, MD, Program Transplant ||||||F
OBX|11|TX|REPORT|| ||||||F
OBX|12|TX|REPORT||85021 ||||||F
OBX|13|TX|REPORT||D :Thu Jul 12 09:19:42 2012 T :Thu Jul 12 10:21:15 2012 Doc #:51511342 ||||||F
OBX|14|TX|REPORT|| ||||||F
Message Segments
This section provides detailed description of segments that may be sent by the Sending System. Only those segments
included in the “Application System Interface Trigger Events and Segments Generated” table are described. The following
guidelines should be observed when interpreting these segment layouts:
Seq = Sequence No. Colum
The 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 is between the first and second
field separators for segments other than MSH.
Dest Data Len = Destination Data Length Column
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 10
2017, OTTR, Inc.
This 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 sending system should not forward on the
field unless noted in the column, “Special Processing for Destination”.
Data Field Name Column
This column contains the HL7 descriptive name for the data item. Site or vendor specific names may be noted in
parentheses. Any field name that is bolded is sent to the destination.
Comments Column
This column references nuances as related to the receiving application.
Special Processing for Destination Column
Data in this column represents processing that will be done by the Sending System. Any field that is not bold and is
shaded is not supported by OTTRFeed.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 11
2017, OTTR, Inc.
MSH – Message Header
The MSH segment describes the intent, source, destination and selected specifics of a message syntax.
MSH – MESSAGE HEADER
Seq Dest
Data
Len
Data Field Name Comments Special Processing for Destination
3 Segment ID “MSH”
1 1 Field Separator OTTR: Processed.
OTTR OTTRFEED Std: “|”
2 4 Encoding
Characters
OTTR: Processed.
OTTR OTTRFEED Std:
“^~\&”
3 180 Sending
Application
OTTR: Processed.
Populated by Sending
System.
4 180 Sending Facility OTTR: Processed.
Populated by Sending
System.
5 180 Receiving
Application
OTTR: Processed.
OTTR OTTRFEED Std: “OTTR”
6 180 Receiving Facility OTTR: Processed.
OTTR OTTRFEED Std: Null
7 26 Date/Time of
Message
OTTR: Processed.
OTTR OTTRFEED Std:
Date/Time message was
created from sending system.
YYYYMMDDHHMM[SS]
[SS] is optional.
8 40 Security OTTR: Processed.
9 7 Message Type OTTR: Processed.
Translate using
“Application System
Interface Trigger Events”
table.
9.1 Message Type OTTR: Processed.
ORU / MDM
9.2 Trigger Event OTTR: Processed.
10 20 Message Control ID OTTR: Processed. (Unique)
OTTR OTTRFEED Std:
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 12
2017, OTTR, Inc.
MSH – MESSAGE HEADER
Seq Dest
Data
Len
Data Field Name Comments Special Processing for Destination
Source’s Message Control ID
11 03 Processing ID OTTR: Processed.
OTTR OTTRFEED Std:
“P” Production,
“T” Testing
Flex per region.
12 08 Version ID OTTR: Processed.
OTTR OTTRFEED Std: 2.3
13 0 OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
14 08 Continuation
Pointer
OTTR: Processed. Used to link subsequent HL7 message
files due to OBX limit’s on sending
system.
15-
21
0 OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 13
2017, OTTR, Inc.
PID – Patient Identification Segment
The PID Patient Identification segment is used as the primary means of communicating patient identification and
demographic information. This segment contains permanent patient information that, for the most part, is not likely to
change.
PID – PATIENT IDENTIFICATION
Seq
Dest
Data
Len
Data Field
Name
Comments Processing into OTTR
3 Segment ID “PID”
1 0 Set ID – PID OTTR: Ignored
2 128 External
Patient ID -
PID
OTTR: Processed. Value is not updated in
database for a standard
Document interface. Field
can be used to filter against
patient population.
3 128 Internal
Patient ID -
PID
OTTR: Processed. Value is not updated in
database for a standard
Document interface. Field
can be used to filter against
patient population.
4 128 Alternate
Patient ID -
PID
OTTR: Processed. Value is not updated in
database for a standard
Document interface. Field
can be used to filter against
patient population.
5 90 Patient
Name
OTTR: Processed.
5.1 30 Family
Name
OTTR: Processed. Value is not updated in
database for a standard
Document interface. Field
can be used to filter against
patient population.
5.2 30 Given Name OTTR: Processed.
Value is not updated in
database for a standard
Document interface. Field
can be used to filter against
patient population.
5.3 30 Second or
Further
Given Name
OTTR: Processed.
Value is not updated in
database for a standard
Document interface. Field
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 14
2017, OTTR, Inc.
PID – PATIENT IDENTIFICATION
Seq
Dest
Data
Len
Data Field
Name
Comments Processing into OTTR
or Initials can be used to filter against
patient population.
6 30 Mother’s
Maiden
Name
OTTR OTTRFEED Std: Not
Supported
7 30 Date/Time
of Birth
OTTR: Processed.
OTTR OTTRFEED Std:
YYYYMMDD
Value is not updated in
database for a standard
Document interface. Field
can be used to filter against
patient population.
8 1 Sex OTTR: Processed.
OTTR OTTRFEED Std: M-F-X
Value is not updated in
database for a standard
Document interface.
9 48 Patient
Aliases
OTTR: Ignored.
10 10 Race OTTR: Processed.
Value is not updated in
database for a standard
Document interface.
11 225 Patient
Address
OTTR: Processed.
11.1 60 Street Address OTTR: Processed.
Value is not updated in
database for a standard
Document interface.
11.2 60 Other
Designation
OTTR: Processed.
Value is not updated in
database for a standard
Document interface.
11.3 25 City OTTR: Processed.
Value is not updated in
database for a standard
Document interface.
11.4 30 State or
Province
OTTR: Processed.
Value is not updated in
database for a standard
Document interface.
11.5 20 Zip or Postal
Code
OTTR: Processed. Value is not updated in
database for a standard
Document interface.
11.6 30 Country Code OTTR: Processed.
OTTR OTTRFEED STD: 2 char
code.
Value is not updated in
database for a standard
Document interface.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 15
2017, OTTR, Inc.
PID – PATIENT IDENTIFICATION
Seq
Dest
Data
Len
Data Field
Name
Comments Processing into OTTR
11.7-
11.9
0 OTTR: Ignored
12 30 County Code OTTR: Processed. Value is not updated in
database for a standard
Document interface.
13 21 Phone
Number –
Home
OTTR: Processed.
Value is not updated in
database for a standard
Document interface.
14 21 Phone
Number -
Business
OTTR: Processed. Value is not updated in
database for a standard
Document interface.
15 50 Primary
Language
OTTR: Not Supported via
interface.
16 1 Marital Status OTTR: Processed.
OTTR OTTRFEED Std:
Code Description
0 Null
1 SINGLE
2 MARRIED
3 DIVORCED
4 SEPARATED
5 WIDOWED
6 COHABITATING
Value is not updated in
database for a standard
Document interface.
17 3 Religion OTTR: Not Supported
18 25 Patient
Account
Number
OTTR: Processed. Value is not updated in
database for a standard
Document interface.
19 128 SSN -
Patient
OTTR: Processed.
Value will be updated by
the interface if the exiting
OTTR field is blank. Field
can be used to filter against
the patient population.
20 128 Driver’s
License
Number –
Patient
OTTR: Ignored
OTTR OTTRFEED Std: Not
Supported
21 20 Patient
Mother’s
OTTR: Ignored
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 16
2017, OTTR, Inc.
PID – PATIENT IDENTIFICATION
Seq
Dest
Data
Len
Data Field
Name
Comments Processing into OTTR
Identifier
22 1 Ethnic Group OTTR: Processed.
OTTR OTTRFEED Std:
- Unknown
- Hispanic Origin
- Not of Hispanic Origin
Value is not updated in
database for a standard
Document interface.
23-
28
0 OTTR: Not Used
29 12 Patient Death
Date
OTTR: Processed.
Value is not updated in
database for a standard
Document interface.
30 3 Patient Death
Indicator
OTTR: Processed.
OTTR OTTRFEED Std:
Y = Deceased, N – Not Deceased
Value is not updated in
database for a standard
Document interface.
36 512 Patient
Discharge
Disposition
OTTR: Processed. Value is not updated in
database for a standard
Document interface.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 17
2017, OTTR, Inc.
NTE – Comment/Note Segment
The NTE segment contains any notes on the patient that are relative to the segment they follow in the overall message,
they can be repeated multiple times. *When using the MDM message type, the only supported NTE is following the PID
segment, this note will be stored as a Progress Note in the Comments table.
NTE – COMMENTS FOLLOWING PID SEGMENT
Seq Dest
Data
Len
Data Field
Name
Comments Special Processing for
Destination
3 Segment ID “NTE” NTE following PID segment
1 4 Set ID Number OTTR: Ignored
2 8 Value Type OTTR: Processed. “FT” = formatted Document
3 32 K Comment OTTR: Processed. Shown as a Patient specific
comment.
Stored in COMMENTS,
COMMENTS_DOCUMENT.
Displayed in OTTR under Patient-
Chart-Progress Notes.
NTE – COMMENTS FOLLOWING OBR SEGMENT
Seq Dest
Data
Len
Data Field
Name
Comments Special Processing for
Destination
3 Segment ID “NTE” NTE following OBR segment
1 4 Set ID Number OTTR: Ignored
2 8 Value Type OTTR: Processed. “FT” = formatted Document
3 32 K Comment OTTR: Processed. Shown as an Order comment within
the body of the report. Stored in
DOCUMENTS, DOCUMENT_BODY.
Displayed in OTTR under Patient-
Document Documents-All
Documents. MDM message types
do not support NTE’s.
NTE – COMMENTS FOLLOWING OBX SEGMENT
Seq Dest
Data
Len
Data Field
Name
Comments Special Processing for
Destination
3 Segment ID “NTE” NTE following OBX segment
1 4 Set ID Number OTTR: Ignored
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 18
2017, OTTR, Inc.
NTE – COMMENTS FOLLOWING OBX SEGMENT
Seq Dest
Data
Len
Data Field
Name
Comments Special Processing for
Destination
2 8 Value Type OTTR: Processed. “FT” = formatted Document
3 32 K Comment OTTR: Processed. Shown as a Result comment within
the body of the report. Stored in
DOCUMENTS, DOCUMENT_BODY.
Displayed in OTTR under Patient-
Document Documents-All
Documents. MDM message types
do not support NTE’s.
Note: NTE segment may represent a General Comment, Order Comment, or Result Comment. General Comment (Not
following an OBR or OBX segment) will store as a Progress Note. OTTRFeed will accept multiple NTE segments in which
each NTE segment represents a hard carriage return or a new line. The UI will also accept comments as a single NTE
segment in which each instance of the Comment field (NTE.3) is separated by the repeat delimiter which represents a new
line. This interface will expect each NTE as a single line of Document. Each line represents a hard carriage return.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 19
2017, OTTR, Inc.
ORC – Common Order Segment
The ORC segment represents a common order that has been made or is being completed.
ORC – COMMON ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
3 Segment ID “ORC”
1 3 Order Control OTTR: Processed. Not stored anywhere in OTTR
2 16 Placer Control Order OTTR: Processed. Do not send from sending
system.
3 17 Filler Control Order OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
4 3 Order Status OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.0 200 Quantity/Timing OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.1 200 Quantity/Timing, Quantity OTTR: Processed. Do not send from sending
system.
7.2.0 200 Quantity/Timing, Interval OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.2.1 200 Quantity/Timing, Interval,
Desc
OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.2.2 200 Quantity/Timing, Interval,
Hours
OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.3 200 Quantity/Timing, Duration OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.4 200 Quantity/Timing, Start Date OTTR: Processed. Do not send from sending
system.
7.5 200 Quantity/Timing, End Date OTTR: Processed.
OTTR OTTRFEED Std:
Required to process.
Do not send from sending
system.
7.6 200 Quantity/Timing, Priority OTTR: Ignored
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 20
2017, OTTR, Inc.
ORC – COMMON ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
OTTR OTTRFEED Std:
Not Supported
7.7 200 Quantity/Timing, Condition OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.8 200 Quantity/Timing, Document OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.9 200 Quantity/Timing,
Conjunction
OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7.10 200 Quantity/Timing, Order
Seq.
OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
9 200 Date/Time of Transaction OTTR: Processed. Do not send from sending
system.
10 120 Entered By OTTR: Processed. Do not send from sending
system.
10.1 40 Entered By, Last Name OTTR: Processed. Do not send from sending
system.
10.2 40 Entered By, First Name OTTR: Processed. Do not send from sending
system.
10.3 40 Entered By, Middle Name OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
11 120 Verified By OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
12.0 90 Ordering Provider OTTR: Processed.
|LNCHAR^FNCHAR^C|
Do not send from sending
system.
12.1 30 Ordering Provider, Last
Name
OTTR: Processed. Do not send from sending
system.
12.2 30 Ordering Provider, First
Name
OTTR: Processed. Do not send from sending
system.
12.3 30 Ordering Provider, Middle
Name
OTTR: Processed. Do not send from sending
system.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 21
2017, OTTR, Inc.
OBR – Observation Order Segment
The OBR segment represents an observation order that has been made or is being completed.
OBR – OBSERVATION ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
3 Segment ID “OBR”
2 17 Placer Control Order OTTR: Processed. If field is valued it is used
instead of the Lab Order
Number.
Stored in ACTIONS,
PLACER_ORDER_NUMBER
and if field is used as the
Primary Document Identifier
for document revisions it is
also stored to
DOC_ATTRIBUTES,
DOC_ATTR_VALUE. Displayed
in OTTR as a discrete field
between the summary and
body of the Document
document.
3 17 Filler Control Order OTTR: Processed. Used as Lab Order Number if
Placer Control Order and Lab
Order Number fields are
blank.
Stored in ACTIONS,
FILLER_ORDER_NUMBER and
if field is used as the Primary
Document Identifier for
document revisions it is also
stored to DOC_ATTRIBUTES,
DOC_ATTR_VALUE. Displayed
in OTTR as a discrete field
between the summary and
body of the Document
document.
3.1 17 Lab Order Num OTTR: Processed. Used if both Placer Control
Order and Filler Control
Order are blank. Can be used
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 22
2017, OTTR, Inc.
OBR – OBSERVATION ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
as the Primary Document
Identifier for document
revisions. Stored in ACTIONS,
ORDER_NUMBER field and if
field is used as the Primary
Document Identifier for
document revisions it is also
stored to DOC_ATTRIBUTES,
DOC_ATTR_VALUE. Displayed
in OTTR as a discreet field
between the summary and
body of the Document
document.
4 38 Universal Service Id OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
4.1 16 Test ID OTTR: Processed. Stored in DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
4.2 31 Test Description OTTR: Processed. Stored in DOCUMENTS,
DOCUMENT_SUMMARY
field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Summary.
4.3 1 Test Coding Method OTTR: Processed. Lookup done on
MISC_LABS_CODES,
HL7_CODING_METHOD and
ACTIONS, CODE_AUTH.
Value is not displayed in
OTTR.
4.4 16 Alternate Test ID OTTR: Processed. Lookup done on ACTIONS,
CODE field. Stored in
DOCUMENTS,
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 23
2017, OTTR, Inc.
OBR – OBSERVATION ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
4.5 31 Alternate Test Description OTTR: Processed. Stored in DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
4.6 1 Alternate Test Coding
Method
OTTR: Processed. Lookup done on
MISC_LABS_CODES,
HL7_CODING_METHOD.
Value is not displayed in
OTTR.
5 3 Order Status OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7 15 Observation Date OTTR: Processed.
OTTR OTTRFEED Std:
YYYYMMDDMMSS
Stored in DOCUMENTS,
DATE_OF_REPORT. Displayed
in OTTR under Patient-
Document Documents-All
Documents-Date column.
8 15 Observation End Date OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
10 0 Collector OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
15.1.1 11 Specimen Source Code OTTR: Processed. If configuration flag
“Store_SpecimenSourceCode
” is enabled the value will be
stored in DOCUMENTS,
DATE_OF_REPORT. Displayed
in OTTR under Patient-
Document Documents-All
Documents-Body.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 24
2017, OTTR, Inc.
OBR – OBSERVATION ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
15.1.2 31 Specimen Source Desc OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
15.3 31 Specimen Desc OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
16 80 Ordering Provider OTTR: Processed. If configuration flag
“StoreOrderingProvider” is
enabled the Provider name
will be stored in
DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
20 60 Filler Field 1 OTTR: Processed When submitting documents
or document images to OTTR
by indicating a source
location to retrieve the file
this is fully qualified path and
filename.
*Reference Appendix B for
processing options for
embedded document content
(encapsulated data such as
PDF or document images).
21 12 Accession Number OTTR: Processed. If configuration flag
“StoreOrderingProvider” is
enabled the Provider name
will be stored in
DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 25
2017, OTTR, Inc.
OBR – OBSERVATION ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
22 15 Result Update Date OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
24.1 6 Diagnosis Service ID OTTR: Processed. Stored in DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
25 1 Result Status OTTR: Ignored.
OTTR OTTRFEED Std:
“P” – “Preliminary”
“F” – “Final”
“C” – “Corrected”
*Value is not stored to the
database on a Document
interface. Additional feature
can be added to append the
result status to the summary
of the report using Tcl.
26.1 16 Organism Code OTTR: Processed. Lookup done on
MISC_LABS_CODES,
MISC_LAB_CODE.
Value is not displayed in
OTTR.
26.2 31 Organism Desc OTTR: Processed. Lookup done on
MISC_LABS_CODES,
MISC_LAB_DESCRIPTION.
Value is not displayed in
OTTR.
27.4 15 Start Date OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
27.6 2 Priority OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
29 50 Parent Order Num OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
32 31 Principal Interpreter OTTR: Processed.
OTTR OTTRFEED Std:
#^LASTNAME^FIRSTNA
ME
If configuration flag
“StorePrincipalInterpreter” is
enabled, value is stored.
Stored in DOCUMENTS,
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 26
2017, OTTR, Inc.
OBR – OBSERVATION ORDER
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
*Note: The # will not be
displayed just First Last
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
33 31 Assistant Interpreter OTTR: Processed.
OTTR OTTRFEED Std:
#^LASTNAME^FIRSTNA
ME
*Note: The # will not be
displayed just First Last
If configuration flag
“StoreAssistantInterpreter” is
enabled, value is stored.
Stored in DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
34 31 Technician OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
35 31 Transcriptionist OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 27
2017, OTTR, Inc.
TXA – Transcription Document Header Segment
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 Change Status (See document change status descriptions list below.)
TXA – TRANSCRIPTION DOCUMENT
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
3 Segment ID “TXA”
1 4 Set ID OTTR: Ignored
2 30 Document Type
3 2 Document Content
Presentation
OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
Can be used to populate the
Document Summary in OTTR
to describe the type of report.
4 26 Activity Date/Time OTTR: Processed.
4.1 14 Activity Date/Time OTTR: Processed.
OTTR OTTRFEED Std:
YYYYMMDDHHMM
*Date/Time is required
to process transaction.
Stored in
DOC_ATTRIBUTES as
Document Activity Date’.
4.2 12 Activity Date/Time Precision OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
5 60 Primary Activity Provider
Code
OTTR: Processed If configuration flag
“StoreOrderingProvider” is
enabled the Provider name
will be stored in
DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under
Patient-Document
Documents-All Documents-
Body.
6 26 Origination Date/Time OTTR: Processed
OTTR OTTRFEED Std:
YYYYMMDDHHMM
Stored in DOCUMENTS,
DATE_OF_REPORT. Displayed
in OTTR under Patient-
Document Documents-All
Documents-Date column.
7 26 Transcription Date/Time OTTR: Processed
OTTR OTTRFEED Std:
Stored in DOC_ATTRIBUTES as
Document Transcription Date.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 28
2017, OTTR, Inc.
TXA – TRANSCRIPTION DOCUMENT
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
YYYYMMDDHHMM
8 26 Edit Date/Time OTTR: Processed
OTTR OTTRFEED Std:
YYYYMMDDHHMM
Stored in DOC_ATTRIBUTES as
Document Transcription
Update Date
9 60 Originator Code/Name OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Originator.
10 60 Assigned Document
Authenticator
OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Authenticator.
Use this or TXA-22.
11 48 Transcriptionist
Code/Name
OTTR: Processed
Stored in DOC_ATTRIBUTES as
Transcriptionist
12 30 Unique Document Number OTTR: Processed
Stored in DOCUMENTS,
SOURCE_DOCUMENT_ID.
Also stored in
DOC_ATTRIBUTES as Unique
Document Identifier
Document may be matched
on this + patient if flag,
MatchDocumentOnId, is on.
13 30 Parent Document Number OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Parent ID
14 22 Placer Order Number OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
15 22 Filler Order Number OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
16 30 Unique Document File
Name
OTTR: Processed
When submitting documents
or document images to OTTR
by indicating a source location
to retrieve the file this is fully
qualified path and filename.
*Reference Appendix B for
processing options for
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 29
2017, OTTR, Inc.
TXA – TRANSCRIPTION DOCUMENT
Seq
Dest
Data
Len
Data Field Name
Comments Special Processing for
Destination
embedded document content
(encapsulated data such as
PDF or document images).
17 2 Document Completion
Status
OTTR: Processed
OTTR OTTRFEED Std:
“T” – Transcribed
“F” – Final OR
See Document
Completion Status
Descriptions below.
Stored in DOC_ATTRIBUTES as
Document Completion Status.
18 2 Document Confidentiality
Status
OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Confidentiality
Status.
19 2 Document Availability
Status
OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Availability Status.
20 2 Document Storage Status OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
21 30 Document Change Reason OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Change Reason.
22 60 Authentication Person,
Time Stamp
OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Authenticator.
Use this or TXA-10.
23 60 Distributed Copies OTTR: Processed
Stored in DOC_ATTRIBUTES as
Document Copies To.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 30
2017, OTTR, Inc.
OBX – Observation Result Segment
The OBX segment represents an observation result that has been made for the patient.
OBX – OBSERVATION RESULT
Seq
Dest Data
Len
Data Field Name
Comments Special Processing for Destination
3 Segment ID “OBX”
1 1 OBX Part ID OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
2 3 Value Type OTTR: Ignored
OTTR OTTRFEED Std:
“ED” – Embedded Data
“TX” – Document
Send “ED” if submitting an embedded
image file. OBX-5 will be assumed to have
five sub-fields with OBX-5.5 containing
the Base64-encoded document.
All other values will be treated as if
sending ASCII Document. OBX-5 will be
stored as-is.
*Reference Appendix B for processing
options for embedded document content
(encapsulated data such as PDF, RTF or
document images).
3.1.1 16 Service ID OTTR: Processed. Lookup done on MISC_LABS_CODES,
MISC_LAB_CODE.
Value is not displayed in OTTR.
3.1.2 4 Service ID Source OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
3.2 31 Description OTTR: Processed. If configuration flag
“PrefixDocBodyLineWithDesc” is enabled
the description from this field will
prepend the actual result. Stored in
DOCUMENTS, DOCUMENT_BODY field.
Displayed in OTTR under Patient-
Document Documents-All Documents-
Body.
3.3 1 Coding OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
4 6 Observation Sub-ID OTTR: Ignored
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 31
2017, OTTR, Inc.
OBX – OBSERVATION RESULT
Seq
Dest Data
Len
Data Field Name
Comments Special Processing for Destination
OTTR OTTRFEED Std:
Not Supported
5 Documen
t (blob
field)
Result OTTR: Processed. For TX Type - ASCII Text - Data from this
field will be stored in DOCUMENTS,
DOCUMENT_BODY field.
Displayed in OTTR under Patient-
Document Documents-All Documents-
Body.
For ED Type – Encapsulated Data – The
contents of this field will further define
how the data is decoded and stored in
the database.
*Reference Appendix B for processing
options for embedded document content
(encapsulated data such as PDF, RTF or
document images).
5.1 Source Application OTTR: Ignored
OTTR OTTRFeed Std:
Processed
The source application that created the file (e.g. Acrobat, Word).
5.2 Data Type OTTR: Ignored
OTTR OTTRFeed Std:
Processed
“DOCUMENT” = Embedded file is
composed of Document.
5.3 Data Subtype OTTR: Ignored
OTTR OTTRFeed Std:
Processed
The type of file being embedded (PDF,
RTF, etc.).
5.4 Encoding OTTR: Ignored
OTTR OTTRFeed Std:
Processed
“Base64” = All embedded files must be
encoded using Base64.
5.5 Data OTTR: Processed
OTTR OTTRFeed Std:
Processed
Stored in DOCUMENT_FULL_IMAGES,
FULL_IMAGE field.
Thumbnail of image type stored in
DOCUMENT_IMAGES,
IMAGE_THUMBNAIL; “image/jpeg”
stored in THUMBNAIL_MIME_TYPE.
*Reference Appendix B for processing
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 32
2017, OTTR, Inc.
OBX – OBSERVATION RESULT
Seq
Dest Data
Len
Data Field Name
Comments Special Processing for Destination
options for embedded document content
(encapsulated data such as PDF, RTF or
document images).
6 16 Units OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
7 21 Reference OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
8 3 Abnormal OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
8.1 3 Abnormal, 1 OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
8.2 3 Abnormal, 2 OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
11 3 Status OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
12 26 Date Last Observation
Normal Value
OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
13 20 Access Check OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
14 26 Observation Date/Time OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
15 250 Producer ID OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
16 250 Responsible Observer OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
17 250 Observation Method OTTR: Ignored
OTTR OTTRFEED Std:
Not Supported
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 33
2017, OTTR, Inc.
APPENDICES
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 34
2017 OTTR, Inc.
APPENDIX A: Configuration Options
Patient Filtering Options
The following list of fields from the HL7 PID segment can be used to filter against patients stored in the OTTR database.
- MRN (PID.2, 3 or 4)
- Patient Last Name (PID.5.1)
- Patient First Name (PID.5.2)
- Date of Birth (PID.7)
- Social Security Number (PID.19)
These fields can be used in any combination in an attempt to make a positive match on an existing patient in the OTTR
database. The interface can be configured to use one set of elements or a series of sets commonly called tiers.
For example, a first tier can include MRN + Last Name
Then a second tier can include SSN + DOB.
If a match is found on either level, the patient has positively been identified and the transaction will be posted to that
patient in the database.
Note all fields in a given tier must match in order for the transaction to be processed into the database. If any one
of them does not match the transaction will be directed to the next tier or will be discarded.
Document Type Identification
The Document interface has the capability to store groups of document types under a generic type, also known as
document breakouts or doc kinds. Using this feature, all Lab Microbiology Reports can be stored and displayed as a
“Microbiology” reports. Typical document breakouts include, Microbiology, Pathology, Transcription, but further breakouts
within those can also be identified. For example instead of “Transcription”, documents can be identified as “History and
Physical”, “Clinic Office Note”, “Op Report”, and so on.
To properly map document’s to a document type in the OTTR application, a field must exist a field within the HL7 message
that identifies each type of message. (I.e. OBR.24.1 = MB for Microbiology). The field can be any data element described in
this spec as “processed”.
Document Matching Options
If document revisions will be sent, the interface uses a specific set of criteria to match a given transaction with one that
might already exist in the database. The default matching criteria for documents is as follows:
Patient ID (PID-2, 3 or 4)
Document Date of Report (TXA-6 for MDM and OBR-7 for ORU)
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 35
2017 OTTR, Inc.
Document Type (config file default or if document breakouts are used TXA-2 for MDM or OBR 4.1 for ORU)
An alternate set of matching criteria can be used if the each document has a unique identifier that will be static through
the life of that document by setting the MatchDocumentOnId flag to 1 (available for MDM Message Types Only). The
matching criteria are:
PatientID (PID-2, 3, 4)
Unique Document Number (TXA-12) if message type is MDM. If ORU, either OBR-2 or OBR-3 can be used
(configurable).
Document Attachment Options
When interfacing documents/reports inbound from Radiology systems the option exists to generate an attachment to the
report which includes a link to an external PACS system for viewing the image that is associated with the report.
If desired, this option can be turned on and requires the following data identified in source transactions:
Patient ID/MRN (dynamic per transaction) for use in the build of the url/link to the PACS system.
Study Accession Number (dynamic per transaction) for use in the build of the url/link to the PACS system.
A static IP address and root url for building the url/link to the PACS system.
A static Facility ID for use in the build of the url/link to the PACS system.
This feature also includes additional security considerations to allow/disallow a given user the ability to select the image
link. This is done by defining per document type (i.e. PACS Radiology) a role that is allowed to select the attachment. That
role would then need to be assigned to the users who should be allowed to view the attachment.
For example, the role could be “View PACS Image Link” which would be added to the document kind of PACS Radiology,
which could then be added to any user. Without this required setup a user double-clicking an attachment link will
generate a pop-up window that they are not authorized.
When on, this feature builds a URL attachment at the time a transaction is received. If at a future date the images are
moved to a different location which renders the URL invalid, additional work would be required to “rebuild” the existing
URL links stored in the database in addition to updating the static portion of the URL in the interface config itself.
For the link to a PACS system to work properly, another pre-requisite will be that the machine being used has the
appropriate PACS system software installed as well as security/authorization to sign-on to that system.
Other Processing Options
Should updates append to the Original versions or overwrite the original (all versions are retained in the database)?
Should the Ordering Provider within the body of the result?
Do you want to be notified when a patient has a new document posted?
For Micro only - When a microorganism is isolated from a patient, the microbiology lab will often perform susceptibility
testing .Will you be sending the micro results susceptibilities in one message with the original tests or separately?
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 36
2017 OTTR, Inc.
Will your sending system be using Continuation Pointers? (DSC segments).
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 37
2017 OTTR, Inc.
APPENDIX B: Processing Documents or Document Images as ED (Encapsulated
Data).
Customers can make documents and document images available through OTTR either by sending the file directly to
OTTRFeed or by telling OTTRFeed where to find it. Customers may only select one of these methods per interface by
which to send documents.
Direct Submission Description: The sending system submits the image directly in the HL7 file, OBX segment. The file must be encoded using
Base64.
To submit the file directly, you must:
Include an OBX segment where:
o OBX-2 contains “ED” for encapsulated data.
NOTE: if OBX-2 does not contain “ED”, the content in OBX-5 will be processed as ASCII
Document.
o OBX-5.1 contains the Source Application (e.g. Acrobat, Word, etc.).
o OBX-5.2 contains “DOCUMENT” for PDF files or “RTF” for rich text format files.
o OBX-5.3 contains the subtype, which is typically the file extension (e.g., pdf or doc).
o OBX-5.4 contains “Base64”.
o OBX-5.5 contains the Base64 encoded file.
File Location Description: In the HL7 message, the sending system provides a file location where OTTRFeed can access and process it
as if the sending system had submitted it directly. If the file is not present in the location, OTTRFeed will attempt to
retrieve it from the indicated location multiple times until a maximum retry limit has been reached. By default, it will
retry up to 30 times before failing. A different maximum can be set by modifying the MaxRetryCount flag in the
configuration file. The maximum file size that can be processed by this interface is 64 MB. Files larger than this threshold
will error.
To submit a file location:
If Transaction Type is MDM - The TXA-16 should contain the fully qualified path and filename of the file to be
submitted.
If Transaction Type is ORU - The OBR-20 should contain the fully qualified path and filename of the file to be
submitted.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 38
2017 OTTR, Inc.
If the path and name will be sent in a different location, that location will need to be identified during the
implementation process.
Drop and Discover Description: The sending system copies a document or image file to a pre-configured directory where OTTRFeed will
read in the file and submit it automatically. Once processed, the file will be moved to another directory.
File names must conform to the following format: LastName_FirstName_MRN_DOB_Serial.Type
LastName – the patient’s last name.
FirstName – the patient’s first name.
MRN – the patient’s medical record number.
DOB – the patient’s date of birth in YYYYMMDD format.
Serial – a number that makes each document unique for the patient.
Type – the file extension (e.g. pdf, rtf, doc).
APPENDIX C: Typical Implementation Plan
Planning: Get a sample HL7 file.
Exchange the document interface specs.
This specification was created based on what we have accomplished for our different customers. An unsupported field in
this document does not mean that we can never support them. If you need to send us a field that is marked as
unsupported, as long as we have a field in the database to store the data, we can make it supportable.
Obtain testing and production server information (IP addresses and login info).
Obtain testing and production database instances.
Create testing and production connection ports.
Design testing and production lab interface environments.
Connection testing.
Units testing of results in misc labs.
Document kinds.
Unit testing by OTTR.
Unit testing by site (optional but recommended).
Signoff form.
Go-Live.
Design: Install the OTTRFeed application, which creates the interface environment.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 39
2017 OTTR, Inc.
Implementation: Create the DOCUMENT interface service.
Create the different documents kinds in the database. Make sure to put the document kind in the Medical
Specialty program and assign a document version ID.
Configure the config files.
Testing: Connection testing: Make sure the connection ports are working properly.
Unit testing by the site: (Optional but recommended) Site has the opportunity to test and double-check if their
requests have been met.
Go-Live: Mirror the testing environment with appropriate changes (database, ports, and directories) to build the production
environment.
Stop all production services.
Signoff form.
Go-Live: Turn on production environment by turning on the service.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 40
2017 OTTR, Inc.
APPENDIX D: Preventive Maintenance
This section lists steps recommended by OTTR to maintain and monitor OTTRFeed and anticipate potential issues.
DAILY: - Pull up the OTTRFeed System Dashboard and check the overall status of the interface and flows.
- Check transactions are flowing properly and review peak load spool backlog (ideal is less than
10 transactions).
- Check for errors in the log.
WEEKLY: - Review the errors folders.
MONTHLY: - Reboot the interface server.
ANYTIME: - Notify OTTR before implementing any upstream interface modifications (system and
hl7).
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 41
2017 OTTR, Inc.
APPENDIX E: Glossary
Configuration file: Commonly refer to as "Config File", this file is compilation of flags that drives the interface behaviors.
The configuration file is a *.config extension file.
Connection Ports: TCP/IP Ports that allow OTTRFeed and the Sending System or Interface Engine to exchange HL7 files.
Discard Sink: This is the part of the config which controls where copies of transactions that did not pass the filtering
criteria are stored. It is required on data filter flows.
Duplicate Sink: Commonly referred to as “Dups”. This is the part of the config which controls where copies of transactions
that have been received from the source and also posted to the database are stored. It is required on input/tcpip flows
and store flows.
Error Sink: This is the part of the config which controls where copies of transactions that have failed processing are stored.
If a transaction encounters an error at any step of processing, then that transaction along with a file indicating the error
message are stored in the referenced location.
Flags: Commands or switches in the configuration file that control the interface behaviors with a given parameter.
Flow: The common name for an OTTRFeed process that handles HL7 data, either a simple data input, data filter, or data
storage flow.
HL7: Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization
dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and
retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of
health services.
Message: Another name for the Hl7 files used by the hl7 interfaces to exchange patient health data. A message is a *.hl7
extension file.
OTTRFeed: The HL7 interface to OTTR, typically deployed as a number of separate processes, all from the same binary,
configured to handle different aspects of the collective interface.
Production Environment: Production Interface environment connected to the production database using production
connecting ports
Service: A service is background process that runs an executable/program in a Microsoft Windows Environment. Services
are created for each interface on a server.
Sink: One of the data outputs for a flow, typically the database, directory location, or outbound socket. Typical directory
locations include, error, discard, and dups.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 42
2017 OTTR, Inc.
Source: The method of data input for a flow, typically a directory location or inbound socket
Spool: A directory and file based data storage system.
Store: To post data to the database.
TCL File: A file written in TCL programming language used by OTTR to control the interface behavior. This file can be seen
as a supplement to the configuration file.
Testing Environment: Interface environment dedicated to testing and connected to test database using test connecting
ports.
To Bounce: This term has the same meaning as "To restart". If connectivity is not established or there is a problem with the
interface, both the sending system and receiving system may need to bounce their interface process.
To Spool: This term refers to the act of manually dropping HL7 files into the “In” Spool directory.
To Re-Spool: Repeated HL7 files spooling.
All information contained herein is confidential and
proprietary to OTTR, Inc.
Inbound Document Interface Specification 43
2017 OTTR, Inc.
Document Revision History
Revision
Number
Modification Description Responsible Person Date
1.0 Added the following sections:
- OTTR Interface Architecture
- New appendices
Koffi Konvi 2011/11/22
1.1 Updated document content and added new document
processing options and features for MDM transaction
types, document images, and dynamic file retrieval.
Ryan Hill 2012/11/12
1.2 Updated appendix A with details about the feature to
dynamically build an attachment which is a link to an
external location (primarily for Radiology Documents and
PACS Images).
Shyla Punteney 2013/01/14
1.3 Revise OTTR Interface Architecture section and updated
appendix D with new terminology.
Shyla Punteney 2016/10/27
1.4 Updated to new logo and reference terms Steve Williams 2017/05/18
1.5 Fixed typo regarding RTF base64 encoded documents. Ryan Hill 2019/01/07