2009 Implementers Group Meeting Program Coding Interoperability

Owned by Former user (Deleted)
Last updated: Aug 18, 2010Version comment
4 min read

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