10-04-093 - OBIX 7.x - 8.x Epic Interface Configuration Guide

OBIX® 7.x - 8.
x Epic
Interface Configuration
Guide
For use with OBIX Software version 7.x - 8.x
Approved for distribution to CCSI customers
10-04-093
August 2018
OBIX 7.x - 8.x Epic Interface Configuration Guide
Table of Contents
1. OBIX Inbound HL7 Interfaces.................................................................................................................................... 3
OBIX System HL7 Inbound Interfaces............................................................................................................... 3
OBIX System HL7 Registration Only Interface .................................................................................................. 4
1.2.1. Registration Message: Type(s) A04 and those not used by the OBIX System ................................................ 4
1.2.2. Update Message: Type(s) A08, A31 ............................................................................................................. 5
1.2.3. Merge Message: Type(s) A40, A18 .............................................................................................................. 6
1.2.4. OBIX Registration Interface HL7 message segment requirements................................................................ 7
OBIX System HL7 Full ADT Interface ...............................................................................................................10
1.3.1. Admit Message: Type(s) A01 ......................................................................................................................10
1.3.2. Transfer Message: Type(s) A02, A06, A07, A10, A12 ...................................................................................11
1.3.3. Discharge Message: Type(s) A03 and A11...................................................................................................12
1.3.4. Registration Message: Type(s) A04 and those not used by the OBIX System ...............................................13
1.3.1. Update Message: Type(s) A08, A31 ............................................................................................................14
1.3.2. Pending Discharge: Message Type(s) A16...................................................................................................15
1.3.3. Merge Message: Type(s) A40, A18 .............................................................................................................16
1.3.4. HL7 message segment requirements..........................................................................................................17
OBIX System HL7 Inbound Entry Notes to EFM Strip Chart Interface...............................................................20
1.4.1. Observation/Note: Message Type(s) R01....................................................................................................20
OBIX System HL7 Medication Administration Interface...................................................................................23
1.5.1. Medication Administration.........................................................................................................................24
OBIX Outbound HL7 Interfaces ................................................................................................................................31
OBIX System HL7 Outbound EFM Data Interface.............................................................................................31
2.1.1. ACK Message Requirements.......................................................................................................................32
OBIX System HL7 Outbound Discrete Data Interface.......................................................................................33
OBIX System HL7 Annotation Sync Interface (ASI)....................................................................................................35
OBIX Inbound HL7 Annotation Sync Interface .................................................................................................35
3.1.1. Observation/Note: Message Type(s) R01....................................................................................................36
OBIX Outbound Annotation Sync Interface .....................................................................................................40
Web Interface Outbound for Versions 7.1 and 7.2 ...................................................................................................42
10-04-093 Page 1
Best Practice for getting Data from the OBIX System ......................................................................................42
4.1.1. User Authentication ...................................................................................................................................42
4.1.2. System Authentication ...............................................................................................................................43
4.1.3. Example .....................................................................................................................................................44
4.1.4. Get In Unit Patients....................................................................................................................................44
4.1.5. Get Encounter Information ........................................................................................................................45
4.1.6. 4.3 Get Strip Header Information ...............................................................................................................46
4.1.7. Get Strip Records .......................................................................................................................................47
4.1.8. Get Strip Notes ..........................................................................................................................................48
Web Interface Outbound for Versions 7.3 and 8.0 ...................................................................................................49
Best Practice for getting Data from the OBIX System ......................................................................................49
5.1.1. Session Authentication...............................................................................................................................49
Web Commands.............................................................................................................................................51
5.2.1. Get Patients ...............................................................................................................................................51
5.2.2. GetActiveAndHeldPatients.php ..................................................................................................................52
5.2.3. GetEncounterInformation.php ...................................................................................................................53
5.2.4. GetEncounterInformationByPatientNumber.php .......................................................................................54
5.2.5. GetStripHeaderInformation.php.................................................................................................................55
5.2.6. GetStripRecords.php ..................................................................................................................................56
5.2.7. GetNotes.php ............................................................................................................................................57
5.2.8. GetAuditLogs.php ......................................................................................................................................58
WebServices Schema Definition .....................................................................................................................59
OBIX Document Imaging - COLD Feed......................................................................................................................64
File Drop with Metadata in File name.............................................................................................................64
File Drop with HL7 Message Pointer & Metadata............................................................................................64
File Drop with Metadata in text file ................................................................................................................65
HL7 Message with Embedded documents ......................................................................................................65
SSOPC for Single or Multiple Facilities .....................................................................................................................66
OBIX Command Line Syntax............................................................................................................................66
7.1.1. Encoding Rules for url-encoded-data..........................................................................................................66
7.1.2. Parameter Field Definitions for url-encoded-data.......................................................................................67
7.1.3. Data Authentication ...................................................................................................................................68
Page 2 10-04-093
1. OBIX Inbound HL7 Interfaces

This section describes all Inbound HL7 Interface requirements for OBIX System versions 7.x and
8.x and applies to HL7 versions 2.3.1 and higher.
OBIX System HL7 Inbound Interfaces

The OBIX system inbound interface accepts HL7 messages from the hospital information system (HIS). The OBIX
interface engine processes all HL7 messages sent to it. Messages sent to the OBIX system should be filtered by
patient sex and age to avoid unwanted patients from being registered/admitted into OBIX. When an unsupported
message is received, OBIX attempts to process it as an A04 (registration) message. OBIX will send an ACK message to
the sending system to acknowledge that the message was accepted or rejected (an error occurred).
OBIX Definitions:
Enterprise Number: Unique number that identifies the patient at an enterprise level.
Enterprise Code: Code that defines the enterprise. Example: HIS, EPIC, MEDITECH, Etc.
Facility Number: Unique number that identifies the patient at a facility level.
Facility Code: Code that defines the facility. Example: NORTH HOSPITAL, MAIN, MMC.
Encounter ID: Unique per visit number assigned to the patient for the duration of their stay.
OBIX versions 7.x and 8.x requires that all patients have an Enterprise and Facility number. These numbers must
correspond to the Enterprise and Facility Codes provided by the customer to the OBIX implementation team. Every
HL7 message sent to the OBIX Inbound Interface must contain the Facility Code in MSH-4. The PID-3 field must
contain an Enterprise Number/Code pair in PID-3[1].1 and PID-3[1].6 and a Facility Number/Code pair in PID-3[2].1
and PID-3[2].6.
Example
MSH|^~\&||EAST|OBIX|EAST|20110725102142|OBIPRN|ADTÂ04|1972|P|2.3|||
EVN|A04|200007250712
PID|||1156550^^^^^HIS~R7150511629^^^^ÊAST||MOORE^MANDY^S^^^||19730729|F ||||||||||124110555
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
Note: The Enterprise Number and the Facility Number are not required to be independent. If the Sending
Application does not have an Enterprise number, the Facility Number may be duplicated and sent to OBIX
if the Facility Number is a globally unique identifier for the patient.
Example
MSH|^~\&||NORTH|OBIX|NORTH|20130701102142|OBIPRN|ADTÂ04|1972|P|2.3|||
EVN|A04|200007250712
PID|||78946578946^^^^^HIS~78946578946^^^^^NORTH||SIMPSON^SAMI^S^^^||19900429|F ||||||||||854234856
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
10-04-093 Page 3
OBIX System HL7 Registration Only Interface

The OBIX Registration Interface supports the following functions: Registration, Update, and Merge. Messages sent to
OBIX for all other functions are accepted and treated as registration messages unless otherwise specified.
The OBIX system HL7 interface supports ASCII encoding only; non-ASCII characters stop the inbound interface from
receiving data.
1.2.1. Registration Message: Type(s) A04 and those not used by the OBIX System
When the OBIX system receives a registration message it registers the patient in the system. An OBIX user can
search for the patient, select her, and assign her to a bed.
Registration Message segment requirements:

Segment Segment name Required
MSH Message Header R
EVN Event Type R
PID Patient Identification R
PD1 Additional Demographics
ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
DB1 Disability Information
Example
EVN|A04|200007250712
PID|||1156550^^^^^HIS~R7150511629^^^^ÊAST||MOORE^MANDY^S^^^||19730729|F||||||||||1
24110555
PV1|1||||||||||||||||0148ÂDDISON^JAMES| |123790
Page 4 10-04-093
1.2.2. Update Message: Type(s) A08, A31

The OBIX system accepts updates to basic patient information: Name, Medical Record Number, Date of Birth,
and Sex. OBIX does not update the patient’s unique Enterprise Number. If OBIX receives a new Encounter
number, the current Encounter number will be discharged, and the new Encounter will be opened. If a patient is
currently in an OBIX bed without an Encounter number assigned and OBIX receives an Encounter number, the
number will be added to the current open Encounter.
Update Message segment requirements:

EVN Event Type R
ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
Example
EVN|A08|200007250712
24110555
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
10-04-093 Page 5
1.2.3. Merge Message: Type(s) A40, A18

The OBIX system merge function works at the patient Enterprise level, merging both Enterprise numbers into
one patient record. When a merge message is received the MRG segment contains the “incorrect” patient and
the PID segment contains the “surviving” patient.
Note: Both patients must be registered in OBIX to perform a merge.
Merge Message segment requirements:

EVN Event Type R
MRG Merge Information R
PV1 Patient Visit
Example
EVN|A40|200007250712
24110555
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
MRG|56015^^^^^HIS
Page 6 10-04-093
1.2.4. OBIX Registration Interface HL7 message segment requirements
MSH Segment Required column; R = Required, O = Optional

Field Description Required Example/Comment
1 Field Separator R The separator between the segment fields. Required
value: |
2 Encoding Characters R Field contains four characters in the following order.
Component separator, repetition separator, escape
character, and subcomponent separator. Required
value: ^~\&
3 Sending Application
4 Sending Facility R Unique identifier for the sending facility. Example:
EAST HOSPITAL
5 Receiving Application
6 Receiving facility
7 Date/Time of message R Format: YYYYMMDDhhmmss
Note: If the system is in more than one time zone, a

time offset should be included.
Format: YYYYMMDDhhmmss(+/-)hhmm
8 Security
9 Message Type R Format: Message Code ^ Trigger Event
Example: ADTÂ04
10 Message Control ID
11 Processing ID
12 Version ID R Example: 2.5
EVN Segment Required column; R = Required, O = Optional

1 Event Type Code R This field must correspond to the Trigger Event in
MSH-9.2
Example: A04
10-04-093 Page 7
PID Segment Required column; R = Required, O = Optional

1 Set ID
2 Patient ID
3 Patient ID List R Field Must contain the Enterprise and Facility
numbers.
Example:
1156550^^^^^HIS~R7150511629^^^^ÊAST
4 Alternative Patient ID
5 Name R Required format:
Last^First^Middle^Suffix^^^^
6 Mother’s Maiden Name
7 Date of Birth R Format: YYYYMMDD
8 Sex R Contains the Patient’s Sex.
Example: F
9 Alias
10 Race
11 Address
12 Country Code
13 Phone Number
14 Business Phone Number
15 Primary Language
16 Marital Status
17 Religion
18 Account Number R Field contains the account number.
Example: Epic HAR number
Page 8 10-04-093
PV1 Segment Required column; R = Required, O = Optional

1 Set ID
2 Patient Class
3 Assigned Patient Location R Required by OBIX to perform Admit, Transfer, and
Discharge functions.
Expected format: Unit^Room^Bed
Example: FLOOR3^LDR2^01
4 Admission Type
5 Preadmit Number
6 Prior Patient Location O Expected format: Unit^Room^Bed
7 Attending Doctor O Required format: ID^Last^First^Middle^Suffix
8 Referring Doctor
9 Consulting Doctor
10 Hospital Service
11 Temporary Location
12 Preadmit Test Indicator
13 Re-admission Indicator
14 Admit Source
15 Ambulatory Status
16 VIP Indicator
17 Admitting Doctor
18 Patient Type
19 Visit Number R Field contains the Unique number assigned to each
patient visit.
Example: Epic CSN number used as the OBIX

Encounter ID
MRG Segment Required column; R = Required, O = Optional

1 Prior Patient Identifier List R Field must contain the prior patients Enterprise
number.
Example: 1158950^^^^^HIS
10-04-093 Page 9
OBIX System HL7 Full ADT Interface

The OBIX ADT supports the following functions: Admit, Transfer, Discharge, Cancel Discharge, Registration, Update,
and Merge. Messages sent to OBIX for all other functions are accepted and treated as registration messages unless
otherwise specified.
The OBIX system HL7 interface supports ASCII encoding only; non-ASCII characters can stop the inbound interface
from receiving data.
1.3.1. Admit Message: Type(s) A01

When the OBIX system receives an admit message for a valid patient to an unoccupied bed, OBIX assigns the
patient to that bed. When a patient admit message is for a bed outside of the OBIX system, the patient’s state is
changed to assessment. When a patient admit message is for an already-occupied OBIX bed. The patient
currently occupying the bed is moved to assessment, and the new patient’s encounter is placed into the bed.
Example
EVN|A01|200007250712
24110555
PV1|1||TRIAGE^8101Â||||||||||||||0148ÂDDISON^JAMES||123790
Admit message segment requirements:

EVN Event Type R

ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
Page 10 10-04-093
1.3.2. Transfer Message: Type(s) A02, A06, A07, A10, A12

When a patient’s transfer message is for a destination bed outside of the OBIX system, the patient’s state is
changed to assessment. When a patient’s transfer message is for an already-occupied OBIX bed, the patient
currently occupying the Bed will be moved into assessment and the transferred patient will be admitted to the
bed.
Example
MSH|^~\&|| EAST|OBIX| EAST|20110411095542|OBIPRN|ADTÂ02|1972|P|2.3|||
EVN|A02|200007250712
24110555
PV1||101|TRIAGE^8101Â|EL||LDRP^8302Â^^ÊAST^^^^^||||Obstet||||NORMAL |||||123790
Transfer message segment requirements:

EVN Event Type R

ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
10-04-093 Page 11
1.3.3. Discharge Message: Type(s) A03 and A11

When the OBIX system receives a valid discharge message, the patient is discharged from their OBIX bed or from
assessment.
Note: The OBIX system will reject patient id updates from all discharge messages. Therefor a discharge
message will not register a patient in the OBIX system if it is the first message received for the patient.
Example
EVN|A01|200007250712
24110555
PV1|1||LDRP^8302Â||||||||||||||0148ÂDDISON^JAMES||123790
Discharge message segment requirements:

EVN Event Type R

ROL Role
NK1 Next of Kin
PV1 Patient Visit R

ROL Role
Page 12 10-04-093
1.3.4. Registration Message: Type(s) A04 and those not used by the OBIX System
When the OBIX system receives a registration message, it registers the patient in the system. An OBIX user can
search for the patient, select her, and assign her to a bed. Any message type that is not configured for use by
OBIX will be processed as a registration message if possible.
Example
MSH|^~\&|HIS|EAST|OBIX|EAST|20110725102142|OBIPRN|ADTÂ04|1972|P|2.3|||
EVN|A04|200007250712
24110555
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
Registration message segment requirements:

EVN Event Type R
ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
10-04-093 Page 13
1.3.1. Update Message: Type(s) A08, A31

The OBIX system accepts updates to basic patient information: Name, Medical Record Number, Date of Birth,
and Sex. OBIX does not update the patient’s unique Enterprise Number. If OBIX receives a new Encounter
number, the current Encounter number will be discharged, and the new Encounter will be opened. If a patient is
currently in an OBIX bed without an Encounter number assigned and OBIX receives an Encounter number, the
number will be added to the current open Encounter.
Example
EVN|A08|200007250712
24110555
Update message segment requirements:

EVN Event Type R
ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
Page 14 10-04-093
1.3.2. Pending Discharge: Message Type(s) A16
Note: This function is disabled by default.
When the OBIX system receives an A16 message, it moves the patient from a bed into Pending Discharge. An
OBIX user can search for the patient under the pending discharge list.
Example
MSH|^~\&|HIS|EAST|OBIX|EAST|20110725102142|OBIPRN|ADTÂ16|1972|P|2.3|||
EVN|A16|200007250712
24110555
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
Pending Discharge message segment requirements:
Cancel Discharge/Cancel Pending Discharge message segment requirements:

EVN Event Type R
ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
10-04-093 Page 15
1.3.3. Merge Message: Type(s) A40, A18

The OBIX system merge function works at the patient Enterprise level, merging both Enterprise numbers into
one patient record. When a merge message is received the MRG segment contains the “incorrect” patient and
the PID segment contains the “surviving” patient.
Note: Both patients must be registered in OBIX to perform a merge.
Example
EVN|A40|200007250712
24110555
MRG|56015^^^^^HIS
Merge message segment requirements:

EVN Event Type R
MRG Merge Information R
PV1 Patient Visit
Page 16 10-04-093
1.3.4. HL7 message segment requirements

1 Field Separator R The separator between the segment fields.
Required value: |
2 Encoding Characters R Field contains four characters in the following order:
component separator, repetition separator, escape
character, and subcomponent separator.
Required value: ^~\&
4 Sending Facility R Unique identifier for the sending facility.

Example: EAST HOSPITAL

8 Security
Example: ADTÂ04
11 Processing ID

1 Event Type Code R This field corresponds to the Trigger Event in MSH-
9.2
Example: A04
10-04-093 Page 17

1 Set ID
2 Patient ID
numbers.
Example:
1156550^^^^^HIS~R7150511629^^^^ÊAST
Example: F
9 Alias
10 Race
11 Address
12 Country Code
13 Phone Number
15 Primary Language
16 Marital Status
17 Religion
Page 18 10-04-093

1 Set ID
2 Patient Class
3 Assigned Patient Location R Required by OBIX to perform Admit, Transfer, and
4 Admission Type
5 Preadmit Number
8 Referring Doctor
9 Consulting Doctor
10 Hospital Service
14 Admit Source
16 VIP Indicator
17 Admitting Doctor
18 Patient Type
19 Visit Number R Field contains the Unique number assigned to
each patient visit. Example: Epic CSN number
used as the OBIX Encounter ID
MRG Segment Required column; R = Required, O = Optional

1 Prior Patient Identifier List R Field must contain the prior patients Enterprise
number.
Example: 1158950^^^^^HIS
10-04-093 Page 19
OBIX System HL7 Inbound Entry Notes to EFM Strip Chart Interface
The OBIX Inbound Entry Notes to EFM Strip Chart Interface is used in conjunction with either the OBIX Registration
or OBIX Remote Control interface to receive and display clinical data charted within the HIS. The following functions
are supported by the interface; final, change, and delete. Once OBIX has received valid data, it will be attached to
the patient’s encounter. This data can then be viewed on the patient’s trace or in notes review.
1.4.1. Observation/Note: Message Type(s) R01

The OBIX system uses observation/note messages to receive flowsheet/notes data from the HIS.
Example
MSH|^~\&|HIS|EAST|OBIX|EAST|20110725102142|OBIPRN|ORU^R01|1972|P|2.3|||
EVN|A01|200007250712
PID|||E432454^^^^^HIS~R7150511629^^^^ÊAST||MOORE^MANDY^S^^^||19730729|F||||||||||124110555
OBR|1||||||200907201900
OBX|1|NM|TEMP^Temp^FLOOBIX||98.6||||||F|||20110630190000.0000-0500||^GOLDENÂSHLEY

Required value: |
2 Encoding Characters R Field contains four characters in the following
order. Component separator, repetition
separator, escape character, and
subcomponent separator. Required value:
^~\&

Or
YYYMMDDhhmmss(+/-)time offset
8 Security
Example: ADTÂ04
11 Processing ID
Page 20 10-04-093

1 Event Type Code R This field must correspond to the Trigger
Event in MSH-9.2
Example: A04

1 Set ID
2 Patient ID
numbers.
Example:
1156550^^^^^HIS~R7150511629^^^^ÊAST
Example: F
9 Alias
10 Race
11 Address
12 Country Code
13 Phone Number
15 Primary Language
16 Marital Status
17 Religion
10-04-093 Page 21

1 Set ID
2 Patient Class
3 Assigned Patient O Required by OBIX to perform Admit, Transfer, and
Location Discharge functions.
4 Admission Type
5 Preadmit Number
8 Referring Doctor
9 Consulting Doctor
10 Hospital Service
14 Admit Source
16 VIP Indicator
17 Admitting Doctor
18 Patient Type
each patient visit.
Encounter ID
Page 22 10-04-093
OBX Segment Required column; R = Required, O = Optional

1 Set ID
2 Value Type R Field contains the format of the observation
value.
Example: ST
3 Observation Identifier R Field contains the Unique identifier for the
observation.
Expected format: Identifier Name^Display
Name^System Name
Example: PULSE^PulseÔBIX
4 Observation Sub-ID
5 Observation Value R Field contains the value observed.
6 Units O Field contains the unit of the observed value.
7 References Range
8 Abnormal Flags
9 Probability
10 Nature of Abnormal Test
11 Observation Results Status R Field Contains the Observation Identifier
result status code.
F=Final
C=Change
D=Delete
Example: F
12 Effective Date of Reference
Range
13 User Defined Access Checks
14 Date/Time of the Observation R Field contains the date and time the
observation was reported.
15 Producer’s ID
16 Responsible Observer R Field contains the individual directly
responsible for the observation.
Format: UserID^LastName^FirstName^
OBIX System HL7 Medication Administration Interface

The OBIX inbound medication administration Interface is used in conjunction with either the OBIX Registration or
OBIX ADT Interface to receive and display clinical data charted within the HIS. The following functions are supported
by the interface; final, change, and delete. Once OBIX has received valid data, it will be attached to the patient’s
encounter. This data can then be viewed within OBIX.
10-04-093 Page 23
1.5.1. Medication Administration

The OBIX system medication administration function receives patient medication data from the HIS. The data is
attached to the patient’s encounter as an OBIX note, which can be reviewed in Patient Manager.
Segment requirements.
EVN Event Type
ROL Role
NK1 Next of Kin
PV1 Patient Visit R
ROL Role
ORC R
RXE Pharmacy/Treatment Encoded Order
RXA Pharmacy/Treatment Administration R
RXR Pharmacy/Treatment Route R
Example
MSH|^~\&||NORTH|OBIX|OBIX|201510081058||RASÔ17|RAS000014499_1058|D|2.3|||AL|NE
PID|||78946^^^^^HIS~789453^^^^^NORTH||SUZY^SUMMER||19920301|F||BL|||||S||786453
PV1|1|A|LDR^R10^01|U||||||MBC||||HOM||||IN|7894537864
ORC|NW|000014499|000014499|||||||||
RXE|^PRN^^20150917|^TYLENOL TAB|1000||^MG||||||^^^^1||||||||||||||||Mild P/F^Mild
Pain or Fever >= 100.5
RXA|0000|1|201510081057|201510081057|ACET-1167ÂCETAMINOPHEN TAB^
|1000|MG|||12332^SMITH^SAM||1000 MG|325|MG||||||Y|G|20151008
RXR|^PO^FDB||
Page 24 10-04-093

value: |


8 Security
Example: ADTÂ04
11 Processing ID
12 Version ID R 2.5

1 Event Type Code R This field must correspond to the
Trigger Event in MSH-9.2
Example: A04
10-04-093 Page 25

1 Set ID
2 Patient ID
3 Patient ID List R Field Must contain the Enterprise and
Facility numbers.
Example:
1156550^^^^^HIS~R7150511629^^^^ÊAST
Example: F
9 Alias
10 Race
11 Address
12 Country Code
13 Phone Number
14 Business Phone
Number
15 Primary Language
16 Marital Status
17 Religion
Page 26 10-04-093

1 Set ID
2 Patient Class
3 Assigned Patient Location R Required by OBIX to preform Admit, Transfer, and
4 Admission Type
5 Preadmit Number
8 Referring Doctor
9 Consulting Doctor
10 Hospital Service
14 Admit Source
16 VIP Indicator
17 Admitting Doctor
18 Patient Type
each patient visit.
Encounter ID
ORC Segment Required column; R = Required, O = Optional

1 Order Control
2 Placer Order Number R Field is use as the placer applications order number
Example: 123456
10-04-093 Page 27
RXE Segment Required column; R = Required, O = Optional

1 Quantity/Timing
2 Give Code O Field contains the medical substance identifier.
Example: 4512^TYLENOL TAB

3 Give Amount - Minimum
4 Give Amount - Maximum

5 Give Units
6 Give Dosage Form
7 Provider's Administration
Instructions
8 Deliver-to Location
9 Substitution Status
10 Hospital Service
Page 28 10-04-093
RXA Segment Required column; R = Required, O = Optional

1 Give Sub-ID Counter
2 Administration Sub-ID Counter
3 Date/Time Start of Administration R Timestamp of when the medication was
given or started.
Format YYYMMDDhhmm
If multiple time zones are used the time

offset should be included.
Format: YYYMMDDhhmmss(+/-)hhmm
4 Date/Time End of Administration
5 Administered Code R Field contains the medication or treatment
administered.
Example: ACET-1167ÂCETAMINOPHEN
TAB^
6 Administered Amount R Field contains the amount given
Example: 500
7 Administered units R Field contains the manner in when the
medication was dispensed.
Examples: Tablet, ml, grams.

8 Administered Dosage Form
9 Administration Notes
10 Administering Provider R Field Contains the id of the person
administering the treatment/medication.
11 Administered-at Location
12 Administered Per R Field Contains the rate at which the
medication was administered.
13 Administered Strength
14 Administered Strength Units
15 Substance Lot Number
16 Substance Expiration Date
17 Substance Manufacturer Name
18 Substance/Treatment Refusal
Reason
19 Indication
20 Completion Status O Field contains the completion status of the
administration event.
Example: Complete
21 Action Code R Field contains the status of the record; Add,
Delete, Update.
Example: A
10-04-093 Page 29
RXR Segment Required column; R = Required, O = Optional

1 Route R Field contains mediation administered route
Example: IV
2 Administration Site R Field contains the site to where the medication was
routed
Example: Left Arm

3 Administration Device
4 Administration Method
5 Routing Instruction
Page 30 10-04-093
OBIX Outbound HL7 Interfaces

This section describes all Outbound HL7 Interface requirements for OBIX System versions 7.x
and 8.x and applies to HL7 versions 2.3.1 and higher.
OBIX System HL7 Outbound EFM Data Interface

The OBIX system outbound interface sends data collected from the fetal monitor to the HIS via HL7 messages. The
HL7 messages generated are ORU^R01 messages that consist of the following segments: MSH, PID, PV1, ORC, OBR,
and OBX. OBIX automatically sends the HL7 messages to the HIS when data is received from the Electronic Fetal
Monitor (EFM).
Note: If for any reason the interface between OBIX and the hospital is down, OBIX will queue the data until
the connection is reestablished.
Example
MSH|^~\&|||||20130603131946||ORU^R01|5||2.3
PID|||56138^^^^^HIS~R1100511217^^^^ÊAST||BLAIR^BRIDGET^||19750628|||||||||||89734872
PV1|||LDR^R6^01^ÊAST^^^^^^||||^^^^^^^^^^^^^^~|^^^^^^^^^^^^^^~
|||||||~||^^^^^^^^^^^^^^~||123434|||||||||||||||||||||||||20130603131800
ORC||||||
OBR|||||||20130603131946
OBX|1|NM|1.0^NIBP Sys||120|mmHg|||||F|||20130603131800
OBX|2|NM|1.1^NIBP Dias||70|mmHg|||||F|||20130603131800
Note: The OBIX system outbound interface sends the Assigned Patient Location in PV1-3 with a format
of: Unit^Room^Bed^^FacilityName
Below is a list of the default outbound OBX segments for Vitals being sent outbound from OBIX. Please note, OBIX
sends out the data received from the EFM. If a function is not supported by the EFM, it will not be collected and sent
outbound by OBIX.
Example:
OBX|1|NM|1.0^NIBP Sys||120|mmHg|||||F|||20150213074502-0600||TESTUSER^TESTÛSER
OBX|2|NM|1.1^NIBP Dias||80|mmHg|||||F|||20150213074502-0600||TESTUSER^TESTÛSER
OBX|1|NM|1.2^NIBP Pulse Rate||75|bpm|||||F|||20150113112800-0600||TESTUSER^TESTÛSER
OBX|1|NM|1.3^SpO2||90|%|||||F|||20150113112800-0600||TESTUSER^TESTÛSER
OBX|1|NM|1.6^Temperature||98.8|F|||||F|||20150113112800-0600||TESTUSER^TESTÛSER
OBX|1|NM|1.7^NIBP PulseOx Rate||76|bpm|||||F|||20150113112800-0600||TESTUSER^TESTÛSER
For OBIX Versions 7.2 and above OBIX will also send the Map value collected from the fetal monitor.
OBX|1|NM|1.8^MAP||93||||||F|||20160926155300||TESTUSER^TESTÛSER
10-04-093 Page 31
2.1.1. ACK Message Requirements

OBIX requires a valid ACK message before sending the next HL7 message. If an invalid ACK is received, the
current message will be resent.
Example
MSH|^~\&|||||20150717121416||ACK^R01ÂCK|225||2.5
MSA|AA|225

value: |
4 Sending Facility

8 Security
Example: ADTÂ04
10 Message Control ID O Field contains the Message Control ID from the
corresponding HL7 message
11 Processing ID
12 Version ID
MSA Segment Required column; R = Required, O = Optional

1 acknowledgment code R The separator between the segment fields.
Required value: |
2 Message Control ID R Field contains the Message Control ID from the
corresponding HL7 message.
Page 32 10-04-093
OBIX System HL7 Outbound Discrete Data Interface

The OBIX Discrete data interface generates an ORU^R01 HL7 message. Any data collected in the OBIX forms is
eligible to be sent outbound EXCEPT for calculated fields and group box elements. OBIX personnel will work with
customers on an individual basis to determine what data elements from the OBIX Forms will be sent to the HIS. OBIX
triggers an HL7 message containing the Form’s data when the recorded is saved. If a previous record is edited, OBIX
will send the complete record at save (not just the edited data).
Example
MSH|^~\&|||||20150501083550-0500||ORU^R01|3||2.3
PID|||789746546^^^^^HIS~7894645^^^^^ÊAST HOSPITAL | |TEST^HL7NOTES^||19431127|||||||||||78976464
PV1|||^W17^^WHITE-
7101^^^^^^||||^^^^^^^^^^^^^^~|^^^^^^^^^^^^^^~|||||||~||^^^^^^^^^^^^^^~||47456497|||||||||||||||||||||||||201
50501083546
ORC||||||
OBR|||||||20150501083550-0500
OBX|1|ST|300001^PLMP||2015-05-01||||||F|||20150501083546
OBX|2|ST|300002ÛLSEDC||2015-05-01||||||F|||20150501083546
OBX|3|ST|300003^FinalEDC||2015-05-01||||||F|||20150501083546
OBX|4|ST|300004^NumFetuses||1||||||F|||20150501083546
OBX|11|ST|300011^FeedingPlan||Breast||||||F|||20150501083546
OBX|12|ST|300012^CircumcisionPlan||Yes||||||F|||20150501083546
OBX|13|ST|300013^HepBVaccinePlan||Yes||||||F|||20150501083546
OBX|14|ST|300014^ChildClasses||Attended||||||F|||20150501083546
OBX|15|ST|300015^BirthPlan||add||||||F|||20150501083546
OBX|44|ST|300104^CompletedBy||LastName, User ||||||F|||20150501083546
of: Unit^Room^Bed^^FacilityName.
10-04-093 Page 33

OBIX requires a valid ACK message before sending the next HL7 message. If an invalid ACK is received, the
Example
MSH|^~\&|||||20150717121416||ACK^R01ÂCK|225||2.5
MSA|AA|225

Required value: |
4 Sending Facility
Or
8 Security
Example: ADTÂ04
corresponding HL7 message
11 Processing ID
12 Version ID

1 Acknowledgment code R The separator between the segment fields.
Required value: |
Page 34 10-04-093
OBIX System HL7 Annotation Sync Interface (ASI)

This interface consists of two parts. First, an Inbound HL7 feed to OBIX where the house system
will send flowsheet data to be stored in OBIX and displayed on the OBIX Trace. Second, an
Outbound HL7 feed from OBIX to the house system in which OBIX will send flowsheet data back
to the house system.
OBIX Inbound HL7 Annotation Sync Interface

The OBIX system inbound interface accepts HL7 messages from the hospital information system (HIS). The OBIX
interface engine processes all HL7 messages sent to it. Messages sent to the OBIX system should be filtered by
patient sex and age to avoid unwanted patients from being registered/admitted into OBIX. When an unsupported
message is received, OBIX attempts to process it as an A04 (registration) message. OBIX will send an ACK message to
the sending system to acknowledge that the message was accepted or rejected (an error occurred).
OBIX Definitions.
Enterprise Number: Unique number that identifies the patient at an enterprise level.
Enterprise Code: Code that defines the enterprise. Example: HIS, EPIC, MEDITECH, Etc.
Facility Number: Unique number that identifies the patient at a facility level.
Facility Code: Code that defines the facility. Example: NORTH HOSPITAL, MAIN, MMC.
Encounter ID: Unique per visit number assigned to the patient for the duration of their stay.
OBIX versions 7.x and 8.x requires that all patients have an Enterprise and Facility number. These numbers must
correspond to the Enterprise and Facility Codes provided by the customer to the OBIX implementation team. Every
HL7 message sent to the OBIX Inbound Interface must contain the Facility Code in MSH-4. The PID-3 field must
contain an Enterprise Number/Code pair in PID-3[1].1 and PID-3[1].6 and a Facility Number/Code pair in PID-3[2].1
and PID-3[2].6.
Example
EVN|A04|200007250712
PID|||1156550^^^^^HIS~R7150511629^^^^ÊAST||MOORE^MADELINE^S^^^||19730729|F ||||||||||124110555
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
Note: The Enterprise number and the Facility Number are not required to be independent. If the Sending
Application does not have an Enterprise number, the Facility Number may be duplicated and sent to OBIX
as long as the Facility Number is a unique identifier for the patient.
Example
MSH|^~\&||NORTH|OBIX|NORTH|20130701102142|OBIPRN|ADTÂ04|1972|P|2.3|||
EVN|A04|200007250712
PID|||78946578946^^^^^HIS~78946578946^^^^^NORTH||SIMPSON^SAMI^S^^^||19900429|F ||||||||||854234856
PV1|1||||||||||||||||0148ÂDDISON^JAMES||123790
10-04-093 Page 35
3.1.1. Observation/Note: Message Type(s) R01

The OBIX system uses observation/note messages to receive flowsheet/notes data from the HIS. The following
functions are supported by the interface; final, change, and delete. Once OBIX has received valid data, it will be
attached to the patient’s encounter. This data can then be viewed on the patient’s trace, or in notes review.
Example
MSH|^~\&|HIS|EAST HOSPITAL|OBIX|EAST
HOSPITAL|20110725102142|OBIPRN|ORU^R01|1972|P|2.3|||
EVN|A01|200007250712
PID|||E7846452^^^^^HIS~R7150511629^^^^ÊAST HOSPITAL||MOORE^MADELINE^S^^^||19730729
|F||||||||||124110555
PV1|1||R-LDR2||||||||||||||0148ÂDDISON^JAMES||123790
OBR|1||||||200907201900
OBX|1|NM|TEMP^Temp^FLOOBIX||98.6||||||F|||20110630190000.0000-0500||^GOLDENÂSHLEY

Required value: |

Or
8 Security
Example: ADTÂ04
11 Processing ID
Page 36 10-04-093

1 Event Type Code R This field must correspond to the Trigger Event in MSH-
9.2
Example: A04

1 Set ID
2 Patient ID
3 Patient ID List R Field Must contain the Enterprise and Facility numbers.
Example:
1156550^^^^^HIS~R7150511629^^^^ÊAST
Example: F
9 Alias
10 Race
11 Address
12 Country Code
13 Phone Number
14 Business Phone
Number
15 Primary Language
16 Marital Status
17 Religion
10-04-093 Page 37

1 Set ID
2 Patient Class
3 Assigned Patient Location O Required by OBIX to perform Admit, Transfer, and
4 Admission Type
5 Preadmit Number

8 Referring Doctor
9 Consulting Doctor
10 Hospital Service
14 Admit Source
16 VIP Indicator
17 Admitting Doctor
18 Patient Type
19 Visit Number R Field contains the Unique number assigned to each
patient visit.
Encounter ID
Page 38 10-04-093
OBX Segment Required column; R = Required, O = Optional

1 Set ID
2 Value Type R Field contains the format of the observation value.
Example: ST
3 Observation Identifier R Field contains the Unique identifier for the observation.
Expected format:
Identifier Name^Display Name^System Name
Example: PULSE^PulseÔBIX
4 Observation Sub-ID
5 Observation Value R Field contains the value observed.
6 Units O Field contains the unit of the observed value.
7 References Range
8 Abnormal Flags
9 Probability
10 Nature of Abnormal Test
11 Observation Results R Field Contains the Observation Identifier result status
Status code.
F=Final
C=Change
D=Delete
Example: F
12 Effective Date of
Reference Range
13 User Defined Access
Checks
14 Date/Time of the R Field contains the date and time the observation was
Observation reported.
15 Producer’s ID
16 Responsible Observer R Field contains the individual directly responsible for the
observation.
Format: UserID^LastName^FirstName^
10-04-093 Page 39
OBIX Outbound Annotation Sync Interface

Data is sent outbound from OBIX when a user adds new documentation or deletes existing. OBIX generates an
ORU^R01 HL7 messages that consist of the following segments: MSH, PID, PV1, ORC, OBR, and OBX.
Note: If for any reason the interface between OBIX and the hospital is down, OBIX will queue the data until
the connection is reestablished.
Example
MSH|^~\&|||||20130603131946||ORU^R01|5||2.3
PID|||56138^^^^^HIS~R1100511217^^^^ÊAST HOSPITAL||BLAIR^BRIDGET^||19750628|||||||||||89734872
PV1|||LDR^R6^01^ÊAST HOSPITAL^^^^^^||||^^^^^^^^^^^^^^~|^^^^^^^^^^^^^^~
|||||||~||^^^^^^^^^^^^^^~||123434|||||||||||||||||||||||||20130603131800
ORC||||||
OBR|||||||20130603131946
OBX|1|ST|Position||Left Side||||||F|||20130603131800
of: Unit^Room^Bed^^FacilityName
Note: OBIX will provide a list of OBX-3 identifiers to the hospital for use in mapping data elements. These
identifiers are configured on a site by site basis.

OBIX requires a valid ACK message before sending the next HL7 message. If an invalid ACK is received the
Example
MSH|^~\&|||||20150717121416||ACK^R01ÂCK|225||2.5
MSA|AA|225
Page 40 10-04-093

value: |
4 Sending Facility
Note: If the system is in more than one time zone, a time

offset should be included.
8 Security
Example: ADTÂ04
11 Processing ID

1 acknowledgment code R The separator between the segment fields.
Required value: |
10-04-093 Page 41
Web Interface Outbound for Versions 7.1 and 7.2

Disclaimer
All descriptions of partner systems in this specification are hypothetical. Clinical Computer
Systems, Incorporated has no specific knowledge of proprietary information for any partner
system. The concepts, designs, and technologies described are common knowledge among
computer engineering professionals and can easily be created by any such practitioners.
Similarities between what is described in this document and any partner system are purely
coincidental. None of the information presented here shall be considered proprietary.
Best Practice for getting Data from the OBIX System

This specification describes the best practice for a cache-based partner system, or a system with its own permanent
data storage, to interface with the OBIX system. It is desirable for the partner system to know that new data is
available in the OBIX system and to get only the new data.
The partner system periodically calls https://www.obix.net:8007/GetActiveAndHeldPatients.php to get up-to-date
information on the active and held patients. Active and held patients occupy beds in the hospital; active patients are
on fetal monitors and held patients are not. Therefore, the maximum number of active and held patients is limited
by the number of available beds in the hospital. The partner system creates a bed table to store the result of
https://www.obix.net:8007/GetActiveAndHeldPatients.php. On the subsequent calls to
https://www.obix.net:8007/GetActiveAndHeldPatients.php, the partner system compares the result against what is
stored in the bed table to determine if any patients have been admitted, transferred, or discharged.
The partner system can call https://www.obix.net:8007/GetActiveAndHeldPatients.php once per minute without
any adverse impact on the OBIX system. If more frequent polling is required, another function can be used.
This function has not been implemented yet. Tentatively, the structure of the function is:
4.1.1. User Authentication

Users shall be authenticated in the partner system. When the partner system accesses the OBIX system, it
passes the user ID to the OBIX system with this parameter: UserID={user ID}
For example, if a user with ID MaryJ wants to access the OBIX system through the partner system, the URL is:
https://www.obix.net:7107/GetActiveAndHeldPatients.php?UserID=MaryJ
The OBIX system does not perform additional authentication, therefore no user password is required. However,
the OBIX system verifies that the user ID exists in its database. If the user ID does not exist in the database, the
function fails.
Page 42 10-04-093
If the partner system caches data, there are two ways to perform user authentication:
 For every user who logs in to the partner system, the partner system calls the OBIX system with the user
ID at least once so the OBIX system knows that the user has accessed the system. The OBIX system logs
such access for auditing.
 The partner system uses a dedicated proxy user ID to access the OBIX system. In other words, all calls to
the OBIX system use the same user ID. The partner system is responsible for facilitating HIPAA
compliance for the customer.
4.1.2. System Authentication

The proposed authentication uses a shared secret for system-to-system authentication. The trust relationship
between the OBIX system and the partner system is established based on the shared secret. The secret is an
ASCII string of any length. Ideally, the secret is quietly coded into the software and is known by as few people as
possible. There is no need for field technicians to know it.
System authentication requires these parameters:
 PSys={partner system name}
 Time={date time in YYYYMMDDhhmm format}
 Auth={random number} − {hash result}
In the examples that follow, the name of the partner system is PartnerSystem.
The Time parameter is the current date and time. The OBIX system does not accept a time that differs from its
current time by more than a certain configurable limit, typically 2 minutes. This means that the clock in the
partner system and that of the OBIX system must be within 2 minutes of each other. This is not difficult to do
since most hospital systems are synchronized to a common time source.
The Auth parameter is computed as follows:

 Generate a new random number for each request. Print the random number into a decimal string.
 Run MD5 hash on all data elements in the following order:
{secret} {random number} {current date time} {user ID} {parameter 1} ... {parameter N}
 The result of MD5 hash is 16 bytes of data. Fold the 16-byte hash result into 4 bytes using XOR:
{1st 4 bytes} XOR {2nd 4 bytes} XOR {3rd 4 bytes} XOR {4th 4 bytes}
 Print the resulting 4 bytes in hexadecimal form, which is an 8-character string.
 Combine the random number and the 8-character string to form the Auth value:
{random number} − {8-character string}
10-04-093 Page 43
4.1.3. Example
If the shared secret is “PartnerSystem and OBIX is a dynamic duo”, the random number is 732615, current date
and time are 200901231853 (1/23/2009 at 18:53), the user ID is MaryJ, the function is Get Encounter
Information and the encounter is 241, the string to run the hash on is:
 PartnerSystem and OBIX is a dynamic duo732615200901231853MaryJ241
 Running MD5 hash on this string produces:
E8E123AF964B40EFBBF8BD7208211F7B
 Folding this hash result gives:
0328C3B7
The final URL is:
https://www.obix.net:8007/GetEncounterInformation.php?UserID=MaryJ&PSys=PartnerSystem&
Time=200901231853&Auth=732615-0328C3B7&Encounter=241
For multi-parameter commands, the parameters can be in any order in the URL as long as the hash is run on the
command parameters in the same order.
Other than authentication issues, everything else works as described in the sections that follow.
4.1.4. Get In Unit Patients

When a user connects to the OBIX system through the partner system, the first thing the user must do is request
a list of active and held patients. Note that patient names are stored in Last^First^Middle format. The partner
system sends this command to the OBIX system:
URL: https://www.obix.net:8007/GetActiveAndHeldPatients.php
Response:
<?xml version="1.0" encoding="utf-8" ?>
<PATIENTS>
<NUMBER_OF_RECORDS>3</NUMBER_OF_RECORDS>
<PATIENT>
<ID>
<NAME>ANNOTATIONSÂNNIE^</NAME>
<NUMBER>MR1234567</NUMBER>
<DOB></DOB>
</ID>
<ENCOUNTER>241</ENCOUNTER>
<ENCOUNTER_STATE>Held</ENCOUNTER_STATE>
<BEDNAME>TBED^1^</BEDNAME>
</PATIENT>
<PATIENT>
<ID>
<NAME>ARLINGTONÂBBY^</NAME>
<NUMBER>93043039</NUMBER>
<DOB>01-12-1980</DOB>
Page 44 10-04-093
</ID>
<ENCOUNTER_STATE>Active</ENCOUNTER_STATE>
<BEDNAME>LDR^2^</BEDNAME>
</PATIENT>
<PATIENT>
<ID>
<NAME>ALLSAINTSÂLICE^</NAME>
<NUMBER>454848</NUMBER>
<DOB></DOB>
</ID>
<BEDNAME>LDR^3^</BEDNAME>
</PATIENT>
</PATIENTS>
4.1.5. Get Encounter Information

If the user selects patient Annie Annotations from the active and held patients list and wants to see more
information about her, the partner system sends this command to the OBIX system to get a list of strips
available for Annie Annotations:
URL: https://www.obix.net:8007/GetEncounterInformation.php?Encounter=241
Response:
<ENCOUNTER_INFO>
<NUMBER_OF_STRIPS>6</NUMBER_OF_STRIPS>
<STRIP>
<STRIP_ID>241</STRIP_ID>
<STRIP_START_TIME>2008-10-23 12:58:20</STRIP_START_TIME>
<STRIP_DURATION_IN_SECS>29</STRIP_DURATION_IN_SECS>
</STRIP>
<STRIP>
</STRIP>
<STRIP>
</STRIP>
<STRIP>
10-04-093 Page 45
</STRIP>
<STRIP>
</STRIP>
<STRIP>
</STRIP>
</ENCOUNTER_INFO>
4.1.6. 4.3 Get Strip Header Information

If the user wants to see the second strip in the list (the one with an ID of 393), the partner system must first get
the strip header information with the command:
URL: https://www.obix.net:8007/GetStripHeaderInformation.php?StripID=393
Response:
<STRIP_HEADER>
<NUMBER_OF_RECORDS>908</NUMBER_OF_RECORDS>
<SAMPLE_PERIOD_IN_SECS>1</SAMPLE_PERIOD_IN_SECS>
<SAMPLES_IN_PERIOD>4</SAMPLES_IN_PERIOD>
<NUMBER_OF_SIGNALS>2</NUMBER_OF_SIGNALS>
<SIGNALS>
<NAME>FHR</NAME>
<NAME>UA</NAME>
</SIGNALS>
</STRIP_HEADER>
This result tells you that:
 The sample rate is 4 per second (current sample rate for all fetal monitors).
 The data stream has two signals, FHR and UA. So, each record consists of one FHR sample and one UA
sample.
 The strip has 908 records (strip length is 227 seconds; sample rate is 4 per second: 227 x 4 = 908
records).
 The partner system can access the records randomly.
Page 46 10-04-093
4.1.7. Get Strip Records

For example, if the partner system wants to get 5 records starting at offset 732 (which is 732 ÷ 4 = 183 seconds
into the strip), it sends this command to the OBIX system:
URL:
https://www.obix.net:8007/GetStripRecords.php?StripID=393&NumberOfRecords=5&StartRecordNumber=7
32
Response:
<STRIP>
<HEADER>
<START_RECORD>732</START_RECORD>
<RECORDS_REQUESTED>5</RECORDS_REQUESTED>
<RECORD_COUNT>5</RECORD_COUNT>
</HEADER>
<RECORD>
<FHR>134</FHR>
<UA>57</UA>
</RECORD>
<RECORD>
<FHR>142</FHR>
<UA>62</UA>
</RECORD>
<RECORD>
<FHR>136</FHR>
<UA>64</UA>
</RECORD>
<RECORD>
<FHR>138</FHR>
<UA>62</UA>
</RECORD>
<RECORD>
<FHR>149</FHR>
<UA>60</UA>
</RECORD>
</STRIP>
<RECORD_COUNT> is the actual number of records returned, which can be less than the number requested.
The OBIX system always returns the number of records requested by the partner system unless they go
beyond the end of the strip or exceed the XML message size limit, which is 1000 records. If fewer records than
requested are returned, the partner system can make additional requests with the proper values in the
StartRecordNumber argument to get the rest of the records.
10-04-093 Page 47
4.1.8. Get Strip Notes

Finally, the partner system gets strip notes with this command:
URL: https://www.obix.net:8007/GetNotes.php?Encounter=241&StartTime=2008-10-
29%2013:22:00&Duration=3600
Response:
<NOTES>
<START_TIME>2008-10-29 13:22:00</START_TIME>
<DURATION_IN_SECS>3600</DURATION_IN_SECS>
<NOTE>
<NOTE_TIME>2008-10-29 13:21:02</NOTE_TIME>
<NOTE_DATA>153/83 mmHg</NOTE_DATA>
</NOTE>
<NOTE>
<NOTE_DATA>37.9 C</NOTE_DATA>
</NOTE>
<NOTE>
<NOTE_DATA>113 bpm</NOTE_DATA>
</NOTE>
<NOTE>
<NOTE_DATA>39/min</NOTE_DATA>
</NOTE>
<NOTE>
<NOTE_DATA>96%</NOTE_DATA>
</NOTE>
<NOTES_FOUND>16</NOTES_FOUND>
<NOTE_COUNT>5</NOTE_COUNT>
</NOTES>
Note that the StartTime argument in the URL is URL encoded, so the space between the date 2008-10-29 and
time 13:22:00 is replaced by %20. <NOTE_COUNT> is the number of notes returned in this result set.
<NOTES_FOUND> shows the total number of notes found in the requested time period. The reason
<NOTE_COUNT> is less than <NOTES_FOUND> is that most notes in the OBIX system are not strip annotations.
The OBIX system has the ability to pass along note information not generated in the OBIX system through this
interface. However, the OBIX system will only pass the raw note received from other systems and will not
perform formatting of the note. Formatting shall be done within the partner system.
OBIX Web Service (OBIXRESTWS) allows you to search for patients, get strip data, and get associated strip
annotations. OBIXRESTWS is not a heavy Web service with a SOAP layer and WSDL. All service requests are
represented as URLs, and all responses are returned directly as XML messages over HTTP. Basically, OBIXRESTWS
follows the REST Web service architecture principles as summarized in
http://en.wikipedia.org/wiki/Representational_State_Transfer
Page 48 10-04-093
Web Interface Outbound for Versions 7.3 and 8.0

Disclaimer
All descriptions of partner systems in this specification are hypothetical. Clinical Computer
Systems, Incorporated has no specific knowledge of proprietary information for any partner
system. The concepts, designs, and technologies described are common knowledge among
computer engineering professionals and can easily be created by any such practitioners.
Similarities between what is described in this document and any partner system are purely
coincidental. None of the information presented here shall be considered proprietary.
Best Practice for getting Data from the OBIX System

This specification describes the best practice for a cache-based partner system, or a system with its own permanent
data storage, to interface with the OBIX system. It is desirable for the partner system to know that new data is
available in the OBIX system and to get only the new data.
The partner system periodically calls https:/ WebServerAddress:Port/GetActiveAndHeldPatients.php to get up-to-
date information on the assigned OBIX patients. Assigned patients have been assigned to beds in the hospital;
whether the patients are on fetal monitors or not. Therefore, the maximum number of assigned patients is limited
by the number of OBIX beds available in the hospital. The partner system creates a bed table to store the result of
https:// WebServerAddress:PortGetActiveAndHeldPatients.php. On the subsequent calls to
https:/ WebServerAddress:PortGetActiveAndHeldPatients.php , the partner system compares the result against
information stored in the bed table to determine if any patients have been admitted, transferred, or discharged.
The partner system can call https:// WebServerAddress:Port/GetActiveAndHeldPatients.php once per minute with
no adverse impact on the OBIX system. If more frequent polling is required, another function can be used.
5.1.1. Session Authentication

The authentication is session-based and requires the client to respond to the server-provided challenge for each
request.
Additionally, a trust relationship between OBIX and the partner system is established based on a shared secret.
This shared secret must be used by the client for all PATDATA (Patient Data) webservice requests. PATDATA
requests include all services except GetAuditLogs.php.
The secret is an ASCII string that should satisfy the following requirements”
 Minimum of 10 characters
 Must contain 1 uppercase character
 Must contain 1 lowercase character
 Must contain 1 number
 Can only contain letters (upper/lower case) and numbers
 Can contain a maximum of 100 characters
10-04-093 Page 49
A session between a client and the OBIX webservice is set up with the client issuing a SessionStart request:
https:// WebServerAddress:Port/SessionStart.php
?Time=<str>
&Type=<string>
&Auth=<string>
&UserID=<UserID in UserInfo table>
Parameters:
 Time: Mandatory. Current ClientTime in ISO Format
Ex: 2016-05-02T07:50:00-0700
 Type: Mandatory. Should be either PATDATA or AUDITLOG
 Auth: Mandatory.
sha256 (SessionTypeSecret + values of all params in the order specified in the request except Auth)
 UserID: Mandatory for PATDATA request.
The OBIX webservice returns a SessionID and a challenge for the next request from the client in the SESSION_ID
and REQUEST_KEY tags.
<RESULT>
<RETURN_CODE>0</RETURN_CODE>
<SESSION_ID>integer</SESSION_ID>
<REQUEST_KEY>integer</REQUEST_KEY>
</RESULT>
On Failure:
<RESULT>
<RETURN_CODE>negative integer</RETURN_CODE>
<RETURN_INFO>string</RETURN_INFO>
</RESULT>
Every subsequent request to the server should contain the following parameters in addition to the service
specific parameters:
https:// WebServerAddress:Port /<ServiceName>.php?Time=<>&SessionID=<>&ReqKey=<>&Param1=<>&Param2=<>&Auth=<>
 Time: Mandatory. Current Client Time in ISO Format
Ex: 2016-05-02T07:50:00-0700
 SessionID: mandatory, the current session
 ReqKey: mandatory, the last request sent to the client.
 Auth: mandatory
sha256(SessionTypeSecret + values of all params in the order specified in the request except Auth)
The time check is always performed before the Auth check. If the client time is invalid, a negative error code is
sent by the server and the previous challenge issued by the server remains valid.
<RESULT>
<RETURN_CODE>-1</RETURN_CODE>
<RETURN_INFO>Invalid Time</RETURN_INFO>
</RESULT>
Page 50 10-04-093
Web Commands
5.2.1. Get Patients

When a user connects to the OBIX system through the partner system, the first thing the user must do is request
a list of active and held patients. Patient names are stored in Last^First^Middle format. The partner system sends
this command to the OBIX system:
GetPatients.php
The command returns all patients with encounters that fall within a specified time range. The time offset
includes minutes to account for time zones that have non-hourly time offsets, such as Newfoundland time zone
in Canada, which has a time offset of -03:30.
Usage:
GetPatients.php?Time=2016-05-04T18:19:00-0500&SessionID=<SID>&ReqKey=<Key>
&StartTime=<dateTimeString>&EndTime=<dateTimeString>
&Auth=<sha256(Secret + All Get Param values in the order presented except Auth)>
Arguments:
StartTime: Mandatory, The search range start time. String must be in yyyy:mm:dd hh:mm:ss format. This must
be urlencoded.
EndTime: Mandatory, The search range end time. String must be in yyyy:mm:dd hh:mm:ss format. This must
be urlencoded.
Returns:
XML data of patients with encounters in the time range specified. There is an accuracy range of 8 hours in the
patients returned., so if a patient has an encounter that has terminated within 8 hours of the input range start
time, that encounter may be returned.
Example:
https://WebServerAddress:8001//GetPatients.php?\
StartTime=2010-01-11 08:00:00&EndTime=2010-01-11 09:00:00
XML Format:

<RESULT>
<PATIENTS>
<START_TIME>input start time string</START_TIME>
<END_TIME>input end time string</END_TIME>
<PATIENTS_FOUND>integer</PATIENTS_FOUND>
<PATIENT>
<ID>
<NAME>HL7 string</NAME>
10-04-093 Page 51
<NUMBER>string</NUMBER>
<DOB>string</DOB>
</ID>
<OBIX_ID>integer</OBIX_ID>
<ENCOUNTER>integer</ENCOUNTER>
<ENCOUNTER_STATE>Active|Held|Pend Discharged|Discharged</ENCOUNTER_STATE>
</PATIENT>
<PATIENT>
</PATIENT>
</PATIENTS>
</RESULT>
5.2.2. GetActiveAndHeldPatients.php
Description: Returns a set of patients assigned to OBIX beds.

Usage:
https://<WebserverAddress:Port>/GetActiveAndHeldPatients.php
?Time=2016-05-04T18:19:00-0500&SessionID=<SID>&ReqKey=<Key>&Auth=<hash>
Arguments: None
Returns: XML data of assigned patients in the format below.
XML Format:
<RESULT>
<PATIENTS>
<NUMBER_OF_RECORDS>integer</NUMBER_OF_RECORDS>
<PATIENT>
<ID>
<NUMBER>string</NUMBER>
<DOB>string</DOB>
</ID>
<BEDNAME>HL7 format</BEDNAME>
</PATIENT>
<PATIENT>
...
Page 52 10-04-093
</PATIENT>
...
</PATIENTS>
</RESULT>
5.2.3. GetEncounterInformation.php
This returns the number of strips in the encounter and the strip IDs, start times, and durations. The time offset
includes minutes to account for time zones that have non-hourly time offsets.
Usage: https://<WebserverAddress:Port>//GetEncounterInformation.php?\
Encounter=<integer>&Time=2016-05-04T18:19:00-0330&SessionID=<SID>&ReqKey=<Key>
Arguments: Encounter (mandatory): numeric value of the patient encounter.
XML Format:
<RESULT>
<ENCOUNTER_INFO>
<NUMBER_OF_STRIPS>integer</NUMBER_OF_STRIPS>
<STRIP>
<STRIP_ID>integer</STRIP_ID>
<STRIP_START_TIME>yyyy-mm-dd hh:mm:ss</STRIP_START_TIME>
<STRIP_DURATION_IN_SECS>integer</STRIP_DURATION_IN_SECS>
</STRIP>
<STRIP>
...
</STRIP>
...
</ENCOUNTER_INFO>
</RESULT>
10-04-093 Page 53
5.2.4. GetEncounterInformationByPatientNumber.php
This command returns the encounters for all patients that match the PatientNumber entered. The time offset
shown in the returned data includes minutes .
Usage: https://<WebserverAddress:Port>/GetEncountersByPatientNumber.php?\
Time=2016-05-04T18:19:00-0500&SessionID=<SID>&ReqKey=<Key>PatientNumber=<string>
Arguments: PatientNumber to be matched.
Returns:
<RESULT>
<ENCOUNTERS_BY_PATIENT_NUMBER>
<PATIENT_NUMBER>integer</PATIENT_NUMBER>
<NUMBER_OF_ENCOUNTERS>integer</NUMBER_OF_ENCOUNTERS>
<ENCOUNTER_INFO>
<START_TIME>String in format yyyy-mm-dd hh:mm:ss</START_TIME>
<PATIENT>
<DOB>string</DOB>
</PATIENT>
</ENCOUNTER_INFO>
<ENCOUNTER_INFO>
...
</ENCOUNTER_INFO>
...
</ENCOUNTERS_BY_PATIENT_NUMBER>
</RESULT>
Page 54 10-04-093
5.2.5. GetStripHeaderInformation.php
Returns the strip start time, duration, number of records in the strip, and signals recorded.
Usage:
https://<WebserverAddress:Port>/GetStripHeaderInformation.php?\
?Time=2016-05-04T18:19:00-0500&SessionID=<SID>&ReqKey=<Key>&StripID=<integer>
Arguments: StripID: Mandatory, The numeric value of the strip

Return Example: https://webserveraddress:8001/GetStripHeaderInformation.php?StripID=241
XML Format:
<RESULT>
<STRIP_HEADER>
<STRIP_ID>positive integer</STRIP_ID>
<ENCOUNTER>positive integer</ENCOUNTER>
<STRIP_START_TIME>String in format yyyy-mm-dd hh:mm:ss</STRIP_START_TIME>
<STRIP_DURATION_IN_SECS>positive integer</STRIP_DURATION_IN_SECS>
<NUMBER_OF_RECORDS>positive integer</NUMBER_OF_RECORDS>
<SAMPLE_PERIOD_IN_SECS>positive integer</SAMPLE_PERIOD_IN_SECS>
<SAMPLES_IN_PERIOD>positive integer</SAMPLES_IN_PERIOD>
<NUMBER_OF_SIGNALS>positive integer</NUMBER_OF_SIGNALS>
</STRIP_HEADER>
</RESULT>
10-04-093 Page 55
5.2.6. GetStripRecords.php
Returns the strip records requested with the associated signal values. Returns have a time offset that includes
minutes.
Usage:
https://<WebserverAddress:Port>/ GetStripRecords.php?StripID=<integer>\
&NumberOfRecords=<integer>&StartRecordNumber=<integer>
&Time=2016-05-04T18:19:00-0500&SessionID=<SID>&ReqKey=<Key>
Arguments:
StripID: Mandatory, The numeric value of the strip
NumberOfRecords: Mandatory, the number of records to return (maximum limit: 2500 records).
StartRecordNumber: Mandatory, the record offset from where records will be returned.
Returns:
<RESULT>
<STRIP>
<HEADER>
<STRIP_ID>integer</STRIP_ID>
<START_RECORD>integer</START_RECORD>
<RECORDS_REQUESTED>integer</RECORDS_REQUESTED>
<RECORD_COUNT>integer</RECORD_COUNT>
</HEADER>
<RECORD>
<SignalName1>value1</SignalName1>
<SignalName2>value2</SignalName2>
...
<SignalNamen>valuen</SignalNamen>
</RECORD>
<RECORD>
...
</RECORD>
...
</STRIP>
</RESULT>
Page 56 10-04-093
5.2.7. GetNotes.php
Returns notes in the requested time duration that matches the note specifications. Note entry time, not note
start time, is queried on. The time offset in the returned data includes minutes.
Usage:
https://<WebserverAddress:Port>/ GetNotes.php?Encounter=<integer>\
&StartTime=<dateTimeString>&Duration=<integer in seconds>
&Time=2016-05-04T18:19:00&SessionID=<SID>&ReqKey=<Key>
Arguments:
Encounter: Mandatory. The numeric value of the encounter.
StartTime: Mandatory. The notes entry start time, string in yyyy:mm:dd hh:mm:ss format. This must
be urlencoded.
Duration: Mandatory, Numeric value in seconds.
Returns:
If the number of notes processed (not matched) exceeds the MaxNotes (default 500) configuration parameter,
then NOTES_FOUND will equal MaxNotes and NOTE_COUNT will be set to the value of the notes returned. In
addition, only in this case, the LAST_NOTE_ENTRY_TIME tag is added with the "entry time" of the last note
returned. This will assist in determining the StartTime and Duration for future queries. Notes are returned in
descending order of the EntryTime,NoteTime tuple.
XML Format:
<RESULT>
<NOTES>
<START_TIME>Date time string</START_TIME>
<DURATION_IN_SECS>integer</DURATION_IN_SECS>
<NOTE>
<ENTRY_TIME>Date time string</ENTRY_TIME>
<NOTE_DATA>string</NOTE_DATA>
</NOTE>
<NOTE>
<ENTRY_TIME>Date time string</ENTRY_TIME>
<NOTE_DATA>string</NOTE_DATA>
</NOTE>
...
<NOTES_FOUND>integer</NOTES_FOUND> //Total notes found for the time duration.
<NOTE_COUNT>integer</NOTE_COUNT> //Number of notes that matched the spec.
<LAST_NOTE_ENTRY_TIME>date time string</LAST_NOTE_ENTRY_TIME> //Only if MaxNotes
</NOTES>
</RESULT>
10-04-093 Page 57
5.2.8. GetAuditLogs.php
This command returns audit logs in the requested time duration in descending order of time. The time offset
includes minutes to account for time zones that have non-hourly time offsets, such as Newfoundland time zone
in Canada, which has a time offset of -03:30.
URL: https://<WebserverAddress:Port>/ GetAuditLogs.php?StartTime=<dateTimeString>\
&Duration=<integer in seconds>&FacilityHandle=<integer>
Usage: &Time=2016-05-04T18:19:00&SessionID=<SID>&ReqKey=<Key>
Arguments:
StartTime: (mandatory) log start time, a string in yyyy:mm:dd hh:mm:ss format. This must be urlencoded.
Duration: Mandatory, Numeric value in seconds.
FacilityHandle: Optional.
Returns:
If number of logs processed exceeds the MaxAuditLogs (10000) configuration parameter, then the
LAST_ENTRY_TIME tag is added with the "entry time" of the last log returned. This aids in determining StartTime
and Duration for future queries.
XML Format:
<RESULT>
<AUDIT_LOGS>
<START_TIME>2014-10-07 10:45:00</START_TIME>
<DURATION_IN_SECS>1200</DURATION_IN_SECS>
<FACILITY_HANDLE>101<FACILITY_HANDLE>
<LOG>
<ID>591</ID>
<ENTRY_TIME>2014-10-07 11:04:11-0500</ENTRY_TIME>
<CLIENT_IP_ADDRESS>192.168.75.1</CLIENT_IP_ADDRESS>
<USER_ID/>
<USER_NAME/>
<ACTIVITY_TYPE>ALERT_ACTIVATIONS</ACTIVITY_TYPE>
<ACTIVITY>...
</ACTIVITY>
</LOG>
<LOG>
<ID>590</ID>
<ENTRY_TIME>2014-10-07 11:02:37-0500</ENTRY_TIME>
<CLIENT_IP_ADDRESS>10.20.7.17</CLIENT_IP_ADDRESS>
<USER_ID>...---...</USER_ID>
<USER_NAME>OBIX</USER_NAME>
<ACTIVITY_TYPE>Menu_PAB</ACTIVITY_TYPE>
<ACTIVITY>
<Menu_PAB>
<PATIENT_INFO>
Page 58 10-04-093
<NAME>GRUEÂPPLE^G</NAME>
<DISPLAY_NAME>GRUEÂPPLE^G</DISPLAY_NAME>
<DOB>1984-01-05</DOB>
<MATCHED>1</MATCHED>
<ID>
<SCOPE></SCOPE>
<NUMBER></NUMBER>
</ID>
</PATIENT_INFO>
<ENCOUNTER_INFO>
<HANDLE>7</HANDLE>
<STATE>1</STATE>
<ACCOUNT_NUMBER>2700000003-A1</ACCOUNT_NUMBER>
<ENCOUNTER_ID>2700000003-E1</ENCOUNTER_ID>
<FACILITY_NAME>DGROUP1</FACILITY_NAME>
<BED_NAME>LDR1</BED_NAME>
<START_TIME_ISO>2014-10-07 11:02:35-0500</START_TIME_ISO>
<START_TIME>907758155</START_TIME>
<START_TIME_UTC_OFFSET>-25200</START_TIME_UTC_OFFSET>
</ENCOUNTER_INFO>
</Menu_PAB>
</ACTIVITY>
</LOG>
<LOGS_COUNT>2</LOGS_COUNT>
</AUDIT_LOGS>
</RESULT>
WebServices Schema Definition

The following is the schema definition for the WebService XML output.
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="https://www.w3.org/2001/XMLSchema">
<xs:complexType name="T_PATIENT_ID">
<xs:sequence>
<xs:element name="NAME" type="xs:string"></xs:element>
<xs:element name="NUMBER" type="xs:string"></xs:element>
<xs:element name="DOB" type="xs:string"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_PATIENT_INFO">
<xs:sequence>
<xs:element name="ID" type="T_PATIENT_ID" />
<xs:element name="OBIX_ID" type="xs:int" />
<xs:element name="ENCOUNTER" type="xs:int" />
<xs:element name="ENCOUNTER_STATE" type="xs:string" />
<xs:element name="BEDNAME" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
10-04-093 Page 59
<xs:complexType name="T_PATIENT_LIST">
<xs:sequence>
<xs:element name="PATIENTS">
<xs:complexType>
<xs:sequence>
<xs:element name="NUMBER_OF_RECORDS" type="xs:int" />
<xs:element name="START_TIME" type="xs:string" minOccurs="0"/>
<xs:element name="END_TIME" type="xs:string" minOccurs="0"/>
<xs:element name="PATIENT" type="T_PATIENT_INFO" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_LOG_INFO">
<xs:sequence>
<xs:element name="ID" type="xs:int" />
<xs:element name="ENTRY_TIME" type="xs:string" />
<xs:element name="CLIENT_IP_ADDRESS" type="xs:string" />
<xs:element name="USER_ID" type="xs:string" />
<xs:element name="USER_NAME" type="xs:string" />
<xs:element name="ACTIVITY_TYPE" type="xs:string" />
<xs:element name="ACTIVITY" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_LOG_LIST">
<xs:sequence>
<xs:element name="START_TIME" type="xs:string" />
<xs:element name="DURATION_IN_SECS" type="xs:int" />
<xs:element name="FACILITY_HANDLE" type="xs:int" />
<xs:element name="LOGS_COUNT" type="xs:int" />
<xs:element name="LAST_ENTRY_TIME" type="xs:string" />
<xs:element name="LOG" type="T_LOG_INFO" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_ENCOUNTER_STRIP">
<xs:sequence>
<xs:element name="STRIP_ID" type="xs:string" />
<xs:element name="STRIP_START_TIME" type="xs:string" />
<xs:element name="STRIP_DURATION_IN_SECS" type="xs:int" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_ENCOUNTER_INFO">
<xs:sequence>
Page 60 10-04-093

<xs:element name="ENCOUNTER_STATE" type="xs:string" />
<xs:element name="NUMBER_OF_STRIPS" type="xs:int" />
<xs:element name="FACILITY_HANDLE" type="xs:int" />
<xs:element name="STRIP" type="T_ENCOUNTER_STRIP" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_PATIENT_INFO2">
<xs:sequence>
<xs:element name="NAME" type="xs:string"></xs:element>
<xs:element name="DOB" type="xs:string"></xs:element>
<xs:element name="OBIX_ID" type="xs:int" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_ENCOUNTER_PATIENT_INFO">
<xs:sequence>
<xs:element name="END_TIME" type="xs:string" />
<xs:element name="PATIENT" type="T_PATIENT_INFO2" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_ENCOUNTERS_BY_PATIENT_NUMBER">
<xs:sequence>
<xs:element name="PATIENT_NUMBER" type="xs:string" />
<xs:element name="NUMBER_OF_ENCOUNTERS" type="xs:int" />
<xs:element name="ENCOUNTER_PATIENT_INFO" type="T_ENCOUNTER_PATIENT_INFO" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_NOTE_INFO">
<xs:sequence>
<xs:element name="NOTE_TIME" type="xs:string" />
<xs:element name="NOTE_DATA" type="xs:string" />
<xs:element name="STATUS" type="xs:string" minOccurs="0"/> 
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_NOTES">
<xs:sequence>
<xs:element name="DURATION_IN_SECS" type="xs:int" />
<xs:element name="NOTES_FOUND" type="xs:int" />
<xs:element name="NOTES_COUNT" type="xs:int" />
10-04-093 Page 61
<xs:element name="LAST_NOTE_ENTRY_TIME" type="xs:string" minOccurs="0"/>

<xs:element name="NOTE" type="T_NOTE_INFO" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_STRIP_HEADER_INFO">
<xs:sequence>
<xs:element name="STRIP_ID" type="xs:int" />
<xs:element name="STRIP_START_TIME" type="xs:string" />
<xs:element name="STRIP_DURATION_IN_SECS" type="xs:int" />
<xs:element name="NUMBER_OF_RECORDS" type="xs:int" />
<xs:element name="SAMPLE_PERIOD_IN_SECS" type="xs:int" />
<xs:element name="SAMPLES_IN_PERIOD" type="xs:int" />
<xs:element name="NUMBER_OF_SIGNALS" type="xs:int" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_STRIP_REQ_HEADER">
<xs:sequence>
<xs:element name="STRIP_ID" type="xs:int" />
<xs:element name="START_RECORD" type="xs:int" />
<xs:element name="RECORDS_REQUESTED" type="xs:int" />
<xs:element name="RECORD_COUNT" type="xs:int" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_STRIP_RECORD">
<xs:sequence>
<xs:element name="FHR1" type="xs:int" />
<xs:element name="UA" type="xs:int" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_STRIP_INFO">
<xs:sequence>
<xs:element name="HEADER" type="T_STRIP_REQ_HEADER" />
<xs:element name="RECORD" type="T_STRIP_RECORD" />
</xs:sequence>
</xs:complexType>
Page 62 10-04-093
<xs:element name="RESULT">
<xs:complexType>
<xs:sequence>
<xs:element name="RETURN_CODE" type="xs:int"></xs:element>
<xs:element name="RETURN_INFO" type="xs:string" minOccurs="0" ></xs:element>
<xs:element name="REQUEST_KEY" type="xs:string" minOccurs="0" ></xs:element>
<xs:element name="SESSION_ID" type="xs:string" minOccurs="0"></xs:element>
<xs:choice minOccurs="0">
<xs:element name="PATIENTS" type="T_PATIENT_LIST" />
<xs:element name="AUDIT_LOGS" type="T_LOG_LIST" />
<xs:element name="ENCOUNTER_INFO" type="T_ENCOUNTER_INFO" />
<xs:element name="ENCOUNTERS_BY_PATIENT_NUMBER"
type="T_ENCOUNTERS_BY_PATIENT_NUMBER" />
<xs:element name="NOTES" type="T_NOTES" />
<xs:element name="STRIP_HEADER" type="T_STRIP_HEADER_INFO" />
<xs:element name="STRIP" type="T_STRIP_INFO" />
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
10-04-093 Page 63
OBIX Document Imaging - COLD Feed

The Document Imaging Interface allows individual patient data (notes, forms, and/or fetal
monitor traces) in the OBIX system to be sent to a hospital document management system. At
discharge, the patient’s data is first converted to a PDF, Tiff, or PNG format and then sent with
the accompanying metadata to the document imaging repository. The OBIX system works with
a wide variety of document imaging vendors accommodating many different requirements for
sending patients records. This section outlines the different types of transmission messages of
the individual patient data to the document imaging repository.
File Drop with Metadata in File name

After the patient is discharged the OBIX system will generate the configured report(s). The OBIX interface will name
each file with specific metadata required by the document imagining repository and then copy the file to a hospital
provided network location.
In the below examples, the file names consist of: ApplicationID_Account/Visit Number_FormID.
OBIX_92829282_Notes.pdf
OBIX_92829282_Triage.pdf
OBIX_92829282_Admit.pdf
OBIX_92829282_Delivery.pdf
There are many other configuration parameters that can be added to the file name that are not shown above
including, but not limited to: DOB, Sex, Create Date, Create Time, Delete Flag, Unit Number.
File Drop with HL7 Message Pointer & Metadata

After the patient is discharged the OBIX system will generate the configured report(s). The OBIX interface generates
each file and copies the file to the hospital provided network location. Next, the OBIX server will open a TCP
connection to the hospital specified server. It then creates and sends an HL7 message containing the appropriate
PID information and the full path and file name of each file into separate OBX segments to the hospital server.
Finally, it closes the TCP connection to the hospital server. Below is a sample message:
MSH|^~\&|OBIX|EAST|HIS|EAST|20140716111549||MDM^T02|20140716111549373000|P|2.3.1|||||||||
EVN|T02|20140716111549|||||
PID|||230361001R||MOORE^MADELINE^||19940129|F|||||||||||||||||||||||
PV1||O|||||||||||||||||||||||||||||||||||||||||||||||||||
TXA||OBIX_DOC^^pdf|FT|20140716111549|||20140716111549|||||356869|||||AU|||||||
OBX|1|RP|OBIX_DOC^^pdf||D:\OBIXCF\0000356869_Notes.pdf^^pdf||||||F|||||||
OBX|2|RP|OBIX_DOC^^pdf||D:\OBIXCF\0000356869_FormTriage.pdf^^pdf||||||F|||||||
OBX|3|RP|OBIX_DOC^^pdf||D:\OBIXCF\0000356869_FormAdmit.pdf^^pdf||||||F|||||||
OBX|4|RP|OBIX_DOC^^pdf||D:\OBIXCF\0000356869_FormDelivery.pdf^^pdf||||||F|||||||
Page 64 10-04-093
Note: The previous example is just one sample and the messages can be customized to meet the needs
of most document imaging repositories. Please contact your CCSI technical representative for more
information.
File Drop with Metadata in text file

After the patient is discharged, the OBIX system will generate the configured report(s). The OBIX interface will create
each report and copy them to a hospital provided network location. Additionally, the OBIX interface will also create
a control file named Account/VisitNumber.control which contains metadata required by the document imaging
repository and then copy the file(s) and control file to a hospital provided network location.
HL7 Message with Embedded documents

After the patient is discharged, the OBIX system will generate the configured report(s). The OBIX interface generates
each file and encodes each file using Base64 encoding. Next, the OBIX server will open a TCP connection to the
hospital specified server. It then creates and sends an HL7 message containing the appropriate PID information and
embeds the encoded data of each file into separate ZPD segments to the hospital server. Finally, it closes the TCP
connection to the hospital server. Below is a sample message where the actual encoded files have been removed
from the message:
MSH|^~\&|OBIX|EAST-HOSPITAL|HIS|EAST-
HOSPITAL|20140716111549||MDM^T02|20140716111549373000|P|2.3.1|||||||||
EVN|T02|20140716111549|||||
PID|||510001587||MOORE^MADILINE^||1992-09-19|||||||||||7894564637|||||||||||||
PV1|||^W15^ÊAST-HOSPITAL^^^^^^||||||||||||||||456153|||||||||||||||||||||||||20140722094532
TXA||0||20131003134109||20131003134109|20131003134109|||||^^20070612151301|||||AU||AV|||||
ZPD|1|PDF|0000276512_Notes.pdf|{ENCODED FILE #1 HERE}|
ZPD|2|PDF|0000276512_Triage.pdf|{ENCODED FILE #2 HERE}|
ZPD|3|PDF|0000276512_Admit.pdf|{ENCODED FILE #3 HERE}|
ZPD|4|PDF|0000276512_Delivery.pdf|{ENCODED FILE #4 HERE}
10-04-093 Page 65
SSOPC for Single or Multiple Facilities

This section describes a light-weight non-CCOW version of single sign-on and patient context
selection interface. This interface enables a partner system to launch OBIX and perform single
sign-on and patient context selection.
The main client module for OBIX is Patient Manager. If Patient Manager is launched with
proper command line arguments, it will perform automatic user sign-on, patient selection, and
display active strip if available.
OBIX Command Line Syntax

The OBIX URL encoded data can be passed to OBIX as follows:
OBIX launcher with optional parameters --logindept --url “url-encoded-data”
OBIX launcher with optional parameters contains an optional path and the name of an OBIX launcher
followed by one or more parameters. The parameters identify, among other things, an instance of OBIX to be
launched. OBIX launcher with optional parameters is installation dependent and is configurable at the
time of installation. Examples are provided later in this section.
deptID identifies the location where a user logged on to the partner system. deptID must contain alphanumeric
characters only (without any space characters).
url-encoded-data contains per user and patient context data. It must be enclosed in double-quote (“)
characters. Otherwise, Windows command line processor interpret and action on ampersand (&) characters.
Enclosing URL encoded data will not create ambiguity because URL encoded data will never contain double-quote
characters.
7.1.1. Encoding Rules for url-encoded-data

url-encoded-data consists of a sequence of field-name and field-value pairs, as follows:
field1=value1&field2=value2
Where value 1 and value 2 are encoded using standard URL encoding. See Section 8.2.1 of RFC 1866
(http://www.rfc-editor.org/rfc/rfc1866.txt) for more information. Since the field names are alphanumeric
characters only (A-Z, a-z, 0-9 and no space or other characters), then no special encoding is needed for field
names.
OBIX can work with the older and less strict URL encoding rules where spaces are converted into plus signs and
no encoding is done for “^.” To prevent problems with future versions of the product that could use other
transport agents, we should use stricter URL encoding rules. The newer rules require every character except A-Z,
a-z, 0-9, underscore (ASCII value 95), and hyphen (ASHII value 45) to be converted into a three-digit escape
sequence that consists of a literal percent (%) sign, followed by the character’s ASCII value represented as two
hexadecimal digits.
Page 66 10-04-093
7.1.2. Parameter Field Definitions for url-encoded-data

The following is a list of parameter fields that OBIX supports:
UserID: User ID of the login user. Example: UserID=MaryJ
PatientName: Name of the selected patient. Patient name should be presented in HL7 format, which is
Last^First^Middle.
PatientName without middle name: Name of the selected patient. Patient name should be presented in HL7
format, which is Last^First^.
MRN: Medical Record Number.
Enterprise ID: Enterprise ID Number. For Epic Enterprises this is EPT ID TYPE.
DOB: Patient Date of Birth in YYYYMMDD format.
Auth: Authentication.
The parameters can be placed in any order in the URL.
EXAMPLES:
The OBIX Instance is 8001 and a user is logged into deptID 12345 with ID MaryJ, she logged into a partner
system and selected patient Jane Ann Doe (Doe^JaneÂnn) with DOB of 3/7/1988 and MRN of 12345678. Then
the command line looks like this:
C:\Program Files\CCSI\{OBIXVersion}\{OBIXInstance}\PatmgrX.cmd -–logindept
12345 -–url
“UserID=MaryJ&PatientName=Doe^JaneÂnn&MRN=12345678&DOB=19880307&Auth=73261^
3F16A764”
Or, like the following if a stricter URL encoding rule is used:
C:\Program Files\CCSI\{OBIXVersion}\{OBIXInstance}\PtmgrX.cmd --logindept
12345 --url
"UserID=MaryJ&PatientName=Doe%5EJane%5EAnn&MRN=12345678&DOB=19980307&Auth=73
2615%5E3F16A764”
Note: If using older versions of OBIX, OBIX 7.1.1 P3 and earlier the MRN parameter within the URL. Newer
versions of OBIX, OBIX 7.1.1 P4 and above will use the Enterprise ID parameter.
When upgrading from OBIX 7.1.1 P3 to a newer version, these parameters will need to be changed. If
upgrading a multi-facility site, then you will have to make the change on the HIS side and bring all
facilities up at once or configure the HIS system to be able to launch multiple ‘buttons’.
Please contact your OBIX Technical Service Representative for your sites specific OBIXVersion,
OBIXInstance, & PtmgrX.cmd.
10-04-093 Page 67
7.1.3. Data Authentication

To prevent potential abuse by unauthorized person(s) who might try to invoke OBIX without logging in or
altering selected patients, we need to authenticate that the data comes from our partner applications without
any alterations. We also need to make sure that hackers cannot reuse stale command line parameters from past
sessions. The algorithm described here is easy to implement and reasonably secure:
1. We need to create a shared secret between the partner system and OBIX. It is a block of data (could be a
password or pass phrase) that is hard coded into both the partner system and OBIX. No one needs to
remember this. We should let as few people know about this as possible.
2. Generate a random number. We can use a random number generator or simply a system clock with sub-
millisecond resolution.
3. Put data together into a string as follows:
{random number} {current time in YYYYMMDDhhmm format}{user ID}{patient
name}{MRN}{DOB}{secret}
Where { } is used as notation here and not included in the string. Note that when OBIX verifies the
authentication data, it will try the current time first. If it fails, it will try again with current time minus one
minute. This will prevent authentication failure if the partner system launches OBIX just before the system
clock advances to the next minute.
4. Run MD5 hash on the string, which produces a 16-byte data.
5. Fold the 16-bit data into a 4-byte data using XOR as follows:
{1st 4 bytes} XOR {2nd 4 bytes} XOR {3rd 4 bytes} XOR {4th 4 bytes}
6. Print the resulting 4 bytes in hexadecimal form, which is an 8-character string.
7. Combine the random number and the hash result to form the Auth value as follows:
{random number}^{hash result}
In the example above, 732615 is the random number and 3F16A764 is the hash result.
MD5 source code is freely available in many languages. We could also use more secure SHA1 hash but it is
unnecessary.
Page 68 10-04-093

10-04-093 - OBIX 7.x - 8.x Epic Interface Configuration Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

10-04-093 - OBIX 7.x - 8.x Epic Interface Configuration Guide

Uploaded by

Copyright:

Available Formats

OBIX® 7.x - 8.

1. OBIX Inbound HL7 Interfaces

OBIX System HL7 Inbound Interfaces

OBIX System HL7 Registration Only Interface

Registration Message segment requirements:

EVN Event Type R

PID Patient Identification R

PD1 Additional Demographics

NK1 Next of Kin

PV1 Patient Visit R

DB1 Disability Information

1.2.2. Update Message: Type(s) A08, A31

Update Message segment requirements:

EVN Event Type R

PID Patient Identification R

PD1 Additional Demographics

NK1 Next of Kin

PV1 Patient Visit R

DB1 Disability Information

1.2.3. Merge Message: Type(s) A40, A18

Note: Both patients must be registered in OBIX to perform a merge.

Merge Message segment requirements:

1.2.4. OBIX Registration Interface HL7 message segment requirements

MSH Segment Required column; R = Required, O = Optional

Note: If the system is in more than one time zone, a

EVN Segment Required column; R = Required, O = Optional

PID Segment Required column; R = Required, O = Optional

PV1 Segment Required column; R = Required, O = Optional

Example: Epic CSN number used as the OBIX

MRG Segment Required column; R = Required, O = Optional

OBIX System HL7 Full ADT Interface

1.3.1. Admit Message: Type(s) A01

Admit message segment requirements:

EVN Event Type R

PD1 Additional Demographics

NK1 Next of Kin

PV1 Patient Visit R

DB1 Disability Information

1.3.2. Transfer Message: Type(s) A02, A06, A07, A10, A12

Transfer message segment requirements:

EVN Event Type R

PD1 Additional Demographics

NK1 Next of Kin

PV1 Patient Visit R

DB1 Disability Information

1.3.3. Discharge Message: Type(s) A03 and A11

Discharge message segment requirements:

EVN Event Type R

PID Patient Identification R

NK1 Next of Kin

PV1 Patient Visit R

DB1 Disability Information

Registration message segment requirements:

Segment Segment name Required

EVN Event Type R

PID Patient Identification R

PD1 Additional Demographics

NK1 Next of Kin

PV1 Patient Visit R

DB1 Disability Information

1.3.1. Update Message: Type(s) A08, A31

Update message segment requirements:

EVN Event Type R