1. The OpenMRS
HL7Query module
An introduction to the HLQuery module,
its design and use
Suranga Nath Kasthurirathne
2. What we’ll cover
Planning and designing
Specific uses cases
Design process
What the module currently supports
Included hl7 message types / structure
Configuring the module
How the module can be extended / modified
Demo
3. What, how and why
A means of exporting OpenMRS data
Translates OpenMRS data into hl7 messages
Asynchronous
Supports both pipe delimited and xml based
hl7 messages
Groovyscript to design message structure
4. Why ?
No universally agreed approach to export hl7
from OpenMRS
Jembi Health Systems needed this
requirement
No two people agreed on the same hl7 to
OpenMRS data mapping
Needed to support multiple message types
5. Design
HL7 message structure
Messages broken down into segments
Some segments are mandatory, some are
not
Some segments can be repeated, others
cant
All depends on your definition of ‘what's
correct’
How stringent do you want your message
to be ?
6. Design cont.…
How did we do this ?
Create templates per each segment
Introduce a template hierarchy
Parent templates can call child templates
Parent templates decide hl7 message
structure
Child templates decide message contents
(data)
7. Template hierarchy
cont.…
Please refer to
https://wiki.openmrs.org/display/projects/ORU_R01+S
pecification+for+the+hL7output+Module
Example
ORUR01 template calls the PID template.
PID template may call PID.3 once or many
times
You can even introduce your own PID or
PID.3 templates !
8. Why not Mirth ?
Supports integration with mirth
Module creates message, and hands it over to
you
Users can integrate Mirth for routing these
messages (if you want to)
Why don’t we provide Mirth as default ?
We DON’T want a dependency on Mirth
9. Setting up the module
Required OpenMRS 1.8.2 or higher
Edit global properties
MSH data fields
Name of parent template you’re using
Set implementation Id
Used to export concepts without any
mappings
11. Querying for ORUR01
messages
ORUR01 messages represent medical
observations
They are supported by default
In OpenMRS-speak, ORUR01 represent
encounters and observations
Single request can contain one or many
encounters
12. Sample query
parameters
patientId
idTypeUuid
encounterUuid
startDate
endDate
None of these parameters are mandatory !