Inbound Document Processing Interface Specification · 2021. 6. 4. · All information contained herein is confidential and proprietary to OTTR, Inc. Inbound Document Interface Specification

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




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.




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.




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.




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.




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.

http://www.hl7.org/




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ÂNY STREET^^BROKEN BOW^NE^68641||4028675309|||||||

OBR|1||651AV|IPDOCÛNKNOWN|||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 |




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Â||19570324|M||||||||||0000284xxxxx|046xxxxxx

PV1|||070||||08xxxx

TXA||TPL|FT|20120712103100||20120712091942|20120712102119|20120712|08xxxxÂllxxxx^Kxxx^M^^ÂPRN|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|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|10|TX|REPORT||CC: Mxxxx Bxxxxx, MD, Mxxxxxxx Rxxxxxxx, MD, Program Transplant ||||||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


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




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.




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:




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




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





patient population.

4 128 Alternate

Patient ID -

PID





patient population.

5 90 Patient

Name

OTTR: Processed.

5.1 30 Family

Name





patient population.

5.2 30 Given Name OTTR: Processed.

Value is not updated in




patient population.

5.3 30 Second or

Further

Given Name

OTTR: Processed.







2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field

Name


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





patient population.

8 1 Sex OTTR: Processed.

OTTR OTTRFEED Std: M-F-X



Document interface.

9 48 Patient

Aliases

OTTR: Ignored.

10 10 Race OTTR: Processed.



Document interface.

11 225 Patient

Address

OTTR: Processed.

11.1 60 Street Address OTTR: Processed.



Document interface.

11.2 60 Other

Designation

OTTR: Processed.



Document interface.

11.3 25 City OTTR: Processed.



Document interface.

11.4 30 State or

Province

OTTR: Processed.



Document interface.

11.5 20 Zip or Postal

Code



Document interface.

11.6 30 Country Code OTTR: Processed.

OTTR OTTRFEED STD: 2 char

code.



Document interface.




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field

Name


11.7-

11.9

0 OTTR: Ignored

12 30 County Code OTTR: Processed. Value is not updated in


Document interface.

13 21 Phone

Number –

Home

OTTR: Processed.



Document interface.

14 21 Phone

Number -

Business



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



Document interface.

17 3 Religion OTTR: Not Supported

18 25 Patient

Account

Number



Document interface.

19 128 SSN -

Patient

OTTR: Processed.

Value will be updated by

the interface if the exiting

OTTR field is blank. Field


the patient population.

20 128 Driver’s

License

Number –

Patient

OTTR: Ignored

OTTR OTTRFEED Std: Not

Supported

21 20 Patient

Mother’s

OTTR: Ignored




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field

Name


Identifier

22 1 Ethnic Group OTTR: Processed.

OTTR OTTRFEED Std:

- Unknown

- Hispanic Origin

- Not of Hispanic Origin



Document interface.

23-

28

0 OTTR: Not Used

29 12 Patient Death

Date

OTTR: Processed.



Document interface.

30 3 Patient Death

Indicator

OTTR: Processed.

OTTR OTTRFEED Std:

Y = Deceased, N – Not Deceased



Document interface.

36 512 Patient

Discharge

Disposition



Document interface.




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


Destination

3 Segment ID “NTE” NTE following OBR segment



3 32 K Comment OTTR: Processed. Shown as an Order comment within

the body of the report. Stored in

DOCUMENTS, DOCUMENT_BODY.


Document Documents-All

Documents. MDM message types

do not support NTE’s.

NTE – COMMENTS FOLLOWING OBX SEGMENT

Seq Dest

Data

Len

Data Field

Name


Destination

3 Segment ID “NTE” NTE following OBX segment





2017, OTTR, Inc.

NTE – COMMENTS FOLLOWING OBX SEGMENT

Seq Dest

Data

Len

Data Field

Name


Destination


3 32 K Comment OTTR: Processed. Shown as a Result comment within

the body of the report. Stored in

DOCUMENTS, DOCUMENT_BODY.



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.




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


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




2017, OTTR, Inc.

ORC – COMMON ORDER

Seq

Dest

Data

Len

Data Field Name


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


system.

12.3 30 Ordering Provider, Middle

Name


system.




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


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,


in OTTR as a discrete field



document.

3.1 17 Lab Order Num OTTR: Processed. Used if both Placer Control

Order and Filler Control

Order are blank. Can be used




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field Name


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,


in OTTR as a discreet field



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.


Patient-Document


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,




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field Name


Destination



Patient-Document


Body.

4.5 31 Alternate Test Description OTTR: Processed. Stored in DOCUMENTS,



Patient-Document


Body.

4.6 1 Alternate Test Coding

Method

OTTR: Processed. Lookup done on

MISC_LABS_CODES,

HL7_CODING_METHOD.


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-


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,




Documents-Body.




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field Name


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,



Patient-Document


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



will be stored in

DOCUMENTS,



Patient-Document


Body.




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field Name


Destination

22 15 Result Update Date OTTR: Ignored

OTTR OTTRFEED Std:

Not Supported

24.1 6 Diagnosis Service ID OTTR: Processed. Stored in DOCUMENTS,



Patient-Document


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.


OTTR.

26.2 31 Organism Desc OTTR: Processed. Lookup done on

MISC_LABS_CODES,

MISC_LAB_DESCRIPTION.


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.





2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field Name


Destination

*Note: The # will not be

displayed just First Last



Patient-Document


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.




Patient-Document


Body.

34 31 Technician OTTR: Ignored

OTTR OTTRFEED Std:

Not Supported

35 31 Transcriptionist OTTR: Ignored

OTTR OTTRFEED Std:

Not Supported




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


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



will be stored in

DOCUMENTS,



Patient-Document


Body.

6 26 Origination Date/Time OTTR: Processed

OTTR OTTRFEED Std:

YYYYMMDDHHMM





Documents-Date column.

7 26 Transcription Date/Time OTTR: Processed

OTTR OTTRFEED Std:

Stored in DOC_ATTRIBUTES as

Document Transcription Date.




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field Name


Destination

YYYYMMDDHHMM

8 26 Edit Date/Time OTTR: Processed

OTTR OTTRFEED Std:

YYYYMMDDHHMM


Document Transcription

Update Date

9 60 Originator Code/Name OTTR: Processed


Document Originator.

10 60 Assigned Document

Authenticator

OTTR: Processed


Document Authenticator.

Use this or TXA-22.

11 48 Transcriptionist

Code/Name

OTTR: Processed


Transcriptionist

12 30 Unique Document Number OTTR: Processed


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


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




2017, OTTR, Inc.


Seq

Dest

Data

Len

Data Field Name


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.


Document Completion Status.

18 2 Document Confidentiality

Status

OTTR: Processed


Document Confidentiality

Status.

19 2 Document Availability

Status

OTTR: Processed


Document Availability Status.

20 2 Document Storage Status OTTR: Ignored

OTTR OTTRFEED Std:

Not Supported

21 30 Document Change Reason OTTR: Processed


Document Change Reason.

22 60 Authentication Person,

Time Stamp

OTTR: Processed


Document Authenticator.

Use this or TXA-10.

23 60 Distributed Copies OTTR: Processed


Document Copies To.




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.


Document Documents-All Documents-

Body.

3.3 1 Coding OTTR: Ignored

OTTR OTTRFEED Std:

Not Supported

4 6 Observation Sub-ID OTTR: Ignored




2017, OTTR, Inc.


Seq

Dest Data

Len

Data Field Name


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 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.




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.





2017, OTTR, Inc.


Seq

Dest Data

Len

Data Field Name




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




2017, OTTR, Inc.

APPENDICES




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)




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?




2017 OTTR, Inc.

Will your sending system be using Continuation Pointers? (DSC segments).




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.




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.




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.




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).




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.




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.




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