2009 Implementers Group Meeting Program Coding Interoperability
Coding for Interoperability Workshop – Sunday 2:30
Introductions with explanation of interoperability projects
large representation of lab information system data exchange
some representation of pharmacy information system data exchange
large representation of aggregate system data exchange
some representation of interfacing with other existing systems
Interoperability with lab systems
Christina (Haiti) –
Just implementing LIMS (own development)
Identified 3 types of information to transfer:
Patient demographics
Lab orders
Result reporting
Burke (Kenya) –
Commercial lab system (PCS)
Using REST module to get orders
HL7 to get results back
Coordinated IDs between 2 systems: concept, location, user, patient
Christina's version of this coordination:
LIMS queries for patient data
Location IDs specified by ministry
LIMS concepts are superset of OpenMRS concepts
Roger questioned whether this produced overly tight coupling between systems
Burke said that Christina's case was special because Haiti controlled both sides of the message
Carl talked about the idea of having OpenMRS produce an output according to a defined interface
Then use MIRTH to convert into other product's message structure
The importance of specifying what data in what format
Use messaging rather than services
Talked about experience at hackathon getting information to/from BIKA open source LIMS
Roger spoke about the history of demographic data in LIMS systems
At one time, there was a lot because LIMS were the basic surveillance system
Data proved to be inaccurate due to lack of patient contact
Current philosophy is to keep in LIMS only that demograhpic information needed for flagging
This turns out to be age and sex.
Roger began a discussion about error handling
Regenstief has a lab data warehouse for state of Indiana
They have 4 people whose job is to manage HL7 error queues
Somebody mentioned that MIRTH was good for this because of its many error handling features
Burke said that it was important to have a good way to resubmit requests after fixing
Christina said that e-links included error handling
Burke said that it was important to include placer's (OpenMRS) order number to match orders and results
There was a question as to how things were going between MIRTH and OpenMRS
Things are going well
Jacob had written into the OpenMRS core a way to get into Web Services
It added 9MB which not everyone would need, so this part has been moved to Web Services
Interoperability with aggregate (vertical, indicator) systems
Justin – New reporting framework should make it easier for reporting upwards
Combination of queries via the logic service and cohort definitions
Ability to access raw data through dataset definition
Ablity to export in XML, CSV, etc.
Problem is how to express indicators in terms of concepts, particularly without recreation at every installation
Burke initiated discussion of how to define indicators as derived concepts
They had a meeting and came up with 30 variables to define "HIV positive"
Roger questioned whether that was sufficient to handle indicators relating to treatment progress
Someone suggested that SDMX had a way to package metadata that could be used derived concept definitions
Bob and JEMBI – SDMX
Time-indexed indicators disaggregated by dimensions
Four messaging components, 2 of which are pure metadata
DSD (data structure definition) – indicators, dimensions
CDS (compact data structure) – values for previously defined indicator, aggregation, time
Carl advocated the same issue of creating an output and mapping it into the required format using MIRTH
Roger said that a local data cube (OLAP) appliance would be useful for data analysis and visualization
Burke said that work with Pentaho had stalled
Problem was that our requirements are more dynamic than Pentaho could deal with
Interoperability with other systems
OASIS – Mozambique
Chris Kelley, RTI
Had many systems for study data management
OpenMRS provided common mode of storage and a way to identify concepts common across studies
Found remote form entry a good way to move data into Open MRS
Slight reconceptualization of data organization
Just had to add an "exported" flag to indicate which records had been exported to OpenMRS
Importance of UUIDs for concepts, locations, etc.
Western Cape – JEMBI
Existing ART tracking system feature rich but used network access to a central DB
Connectivity problems made them want to keep a local DB, using OpenMRS for this
Some issues of security and authorizations across system boundaries
ANOTHER VERSION
Issues
Metadata exchange needs to be considered
Mapping (to dictionaries like LOINC) should done when useful
New systems start with their own vocabularies
Mapping enable decoupling of local systems
Middleware servers enable compromise
First question - What is the data you need?
Second question - What is the format?
It's useful to define interfaces in terms of necessary data
Sometimes lab test results need demographic information (i.e. to determine if a result is within normal limits based on age and/or general)
Integration code development, which depends on low level (code-based) functionality generally isn't a good idea
This is because code changes in the integrated can break functionality
Regenstrief is creating a data warehouse of tests across Indiana
A lot of time is spend on handling exception queues
It is necessary to define what to do when things go wrong
E.g. when concepts aren't mapped between systems
Ideally we'd like a console to make it easy to resolve exceptions
Middleware like Mirth helps solve some of these problems
Jacob (Mirth) did some customization on OpenMRS code to enable web services.
Has since been converted to a web services module
The web service ability is now in 1.5, but the actual web services hasn't been written
AMPATH uses base HL7 for lab system integration
It's important to be able to track orders uniquely through a lab system
Labs and pharmacy systems interoperability are a similar problem (horizontal data transfer)
Aggregate data systems are a different distinct (vertical data transfer)
Some discussion on complex logic queries versus indicator definitions and whether it's possible to standardize them.
It's a problem, even between OpenMRS implementations
Overview of SDMX
Use interoperability rather than custom development to save resources by developing reusable components
Use established standards for this
Always code against the OpenMRS API
This makes things easier because voided and retired data are taken care of
New functionality and changes to the API will ensure backwards compatibility