ughjhhjh

determine WebPAS message type;

In MSH segment check the 9th field, this is meant to contain

<message type (ID)> ^ <trigger event (ID)>

(see https://www.hl7.org/documentcenter/public_temp_B5A64101-1C23-BA17-0C953B25BD420909/wg/conf/HL7MSH.htm)

our PAS is a knob and has it like this instead:

Message	Description	Message Type
A01	Admit a Patient	ADT^A01^ADT_A01
A02	Transfer a Patient	ADT^A02^ADT_A02
A03	Discharge a Patient	ADT^A03^ADT_A03
A05	Pre-admit a Patient	ADT^A05^ADT_A01
A08	Update patient Information	ADT^A08^ADT_A01
A11	Cancel Admit	ADT^A11^ADT_A09
A12	Cancel Transfer	ADT^A12^ADT_A12
A13	Cancel Discharge	ADT^A13^ADT_A01
A14	Pending Pre-Admission	ADT^A14^ADT_A01
A21	On Leave	ADT^A21^ADT_A02
A22	Return from Leave	ADT^A22^ADT_A02
A27	Cancel Pending Pre-Admission	ADT^A27^ADT_A02
A28	Add Person Information	ADT^A28^ADT_A28
A31	Update person Information	ADT^A31^ADT_A01 OR ADT^Axx^ADT_01 when using alternate “A” message
A34	Merge Person Information (Patient ID Only)	ADT^A34^ADT_A30
A44	Change U/R for a Visit	ADT^A44^ADT_A43
M02	Practitioner Message	MFN^M02^MFN_M02
S12	Notification of New Appointment Booking	SIU^S12^SIU_S12
S14	Notification of Appointment Modification	SIU^S14^SIU_S12
S15	Notification of Appointment Cancellation	SIU^S15^SIU_S12

Just check the first two fields.  The second appears to indicate the event that raised the message, for example admitting someone in PAS (admission event = A01) may send out:

preadmit message ADT^A05^ADT_A01
then update patient info ADT^A31^ADT_A01
then admission message ADT^A01^ADT_A01

The ADT events we mostly care about:

A01 Admit / visit notification
A02 Transfer a patient
A03 Discharge/end visit
A04 Registration (e.g. ED visit where not admitted)
A05 Pre-admit a patient
A08 Update patient information
A18 Merge patient information
A19 QRY/ADR - Patient query
A31 Update person information
A34 Merge patient information - patient I

full list

The OBX segment is a jerk - how to use encapsulated data in an OBX segment

So say your hospital has this application that makes patient results (like the results after a procedure), and it does it in a PDF with embeded pictures and a nice layout and it looks all awesome. You want to get this PDF and jam it into your results repository so that the clinical staff can go to this single place to view results from different applications (if they have to log into multiple places they will get a severe case of the frowny faces). Now, it also turns out that your hospital has an 'enterprise messaging system' because that is the kind of insanity we like to get involved with in the health sector so that means you're using HL7 messages to pass information between applications.

Enter the OBR message. Ta da.

The OBR HL7 messages are used to send results, and the OBX segment of the message is what contains the actual results details.  Often they might just be holding that information as text, but you can also cram whole files into the OBX segment. The problem with the OBX is that it is a bit of a jerk and likes to be all mysterious and poorly documented by systems that both produce and consume OBR messages.

The second field in the OBX determines how you are sending your data. You've got options here; these seem to be the least useless options of putting data into an OBX:

RP = Reference pointer
ST = String
FT = Formatted text
TX = Text data
ED = Encapsulated data

The string, text and formatted text are sending the results as string data.  The reference pointer allows you send a link to a file (e.g. on a network drive).  Encapsulated data allows you to embed the entire contents of a file (e.g. a PDF or a DOCX) into the message.

A message with two sets of results (two OBX segments) where one is formatted text and one is encapsulated data looks like this:

MSH|[snip]
PID|[snip]
PV1|[snip]
ORC|[snip]
OBR|[snip]
OBX|0001|FT|1006^MCH^L^28539-5^^LN||"this is formatted text"|pg|||||I
OBX|0002|ED|1003^Haemoglobin^L^718-7^^LN||ClientFile^application^pdf^Base64^CBSL0xlbmd0aCA2Ny9QcmV2IDk0MjIvUm9vdCAxMSAwIFIvU2l6ZSAzMi9[snip]

So, the OBX which is set to encapsulated data ('ED') has the base64 encoded binary contents of a PDF jamed into the OBX.5 field.  That's kind of cool!

What these message actually look like on the recieving system I guess depends on how the application deals with them.  In our results repository (Eclair), if you send a single ED OBX (containing for example a PDF) it will open and display the document in panel as shown to the left.









If you send multiple OBX segments then the ED ones will show with clickable icons.













Yuuussssss.