1. OpenREM Avatar OpenREM
  2. OpenREM
  3. OpenREM
  4. Issues

Use HL7 to get procedure information

Issue #250 new
Ed McDonagh created an issue

Some systems don't transmit procedure information in RDSR objects, particularly interventional fluoroscopy systems.

Sometimes this information is available after the procedure from RIS systems, in a HL7 feed.

This could be adopted by OpenREM to improve the quality of the data.

Comments (12)

  1. Ed McDonagh reporter

    Created a task @dplatten because I had a look earlier and it seems there are two HL7 python modules that would be easier to use and incorporate into OpenREM than using MIRTH.

    • python-hl7
    • HL7apy

    I don't know which is better to use; both seem to use HL7 v2 rather than v3, but so do most hospital systems.

  2. Luuk

    As we see need for this in our hospital (sometimes RDSRs are very bare bone) I had a look at this.

    HL7 python module

    I started using HL7apy as that is the only library that I found containing a MLLP server and that does have some recent development. You can loosen strict HL7 validation as implementations may vary widely.

    Implementation

    The main "problem" with implementing HL7 updates is the mapping of HL7-elements to DICOM tags. This can be very different for different countries and/or hospitals due to national extensions and specific local implementations. I couldn't get away with a simple mapper like OBR-18 always ends up as DICOM AccessionNumber. So I made a "basemappping" based on the IHE documentation (radiology SWF) that can be overridden in a child class. The pitty of this approach is that for a specific hospital implementation extra python coding is needed. But except for some scripting language, I don't see another way that can support all use cases (i.e. picking the right value in repetitions of segments and components). Our production HL7/DICOM broker also uses some scripting language for this. So far my code supports:

    • Update of patient information by ADT-messages (and configurable also by order messages)
    • Patient merge - ADT_A40 (A18 not supported, I personally never saw such a message)
    • Update of study information by ORM/OMG/OMI/ORU messages

    I performed some preliminary testing and it all seems to work (basically). Implementation is not complete (and I have to look at the IHE documentation more closely), but before continuing I would like to hear your opinions @edmcdonagh, @dplatten, @tcdewit. The implementation so far can be found in my own playground (here). So, what do you think?

  3. Ed McDonagh reporter

    Awesome @LuukO

    HL7 is always going to be beyond the reach of most OpenREM users, but for those who can, it would be great to have the OpenREM end ready wand waiting to be tweaked.

    Does this rely on a feed from one system or another, or is there a 'query' mechanism? My HL7 knowledge is weak (although I seem to be getting exposed to it more and more!). Most of the communications I know about are all updates/scheduling/results etc being sent from one system to another, and once it is sent it is lost.

    I am wondering in that case about which sort of systems the HL7 feed will come from (RIS? PAS? Cardiology?) and what you do with messages that come into OpenREM before any corresponding RDSR etc has come in (but might soon after)?

    If all that isn't a problem, then I guess we need to make the mapping of message types and elements to DICOM fields as easy to configure as possible - it would need to be in some sort of _local.py file that we don't overwrite with updates.

    Very excited to see this development. Thank you.

  4. Luuk

    Most HL7 implementations just send the HL7 messages and if you don't process it, the information is lost. HL7 feed is mostly coming from HIS/EMR and/or RIS. Most HIS/EMR systems allow querying of patient information, but this is not implemented in the code now (I don't know about a mechanism for querying order (study) information. I think it doesn't exist).

    For now I neglect messages from studies / patients that are unknown. You could "prefill" studies that you would expect to get a RDSR from (based on modality). If the report in an ORU message is also sent to OpenREM, you can get a lot of information from that and it will be sent after receiving the RDSR in almost all cases (mpps information could potentially help here also).

    In the current implementation the base (IHE) HL7 mapping is in the file "basehl7mapping.py" and the child (local) class in "hl7mapping.py".

    I'm trying to get a HL7 feed from the test environment of the ZIS/RIS in our hospital. Than I can play around with some scenarios to see if it works in those use cases.

  6. Luuk

    Some comments to the first HL7 commit:

    • ADT tested quite well in one site (Radboud University Medical Center; in production environment now)
    • Order messages tested very limited
    • Order messages are kept in database for later use if corresponding study is not found
    • Python script created to delete messages from database if today is later than a configurable days after the studydate (script tested, not in combination with Celery beat)
    • documentation and automated tests should still be written.
  8. Luuk

    Refs #250 Support for Hl7 messaging

    • Added order status in mapping
    • Made it possible to save messages only from specific order status (default: in progress)
    • Changed logging configuration to openrem general configuration
    • Added Celery beat task to clean up old hl7-messages in database
    • Solved issue with printing hl7-messages in unicode format

    → <<cset 332293e58f65>>

  11. Luuk

    Yes, documentation didn't finish yet. Just a first set-up.

    All seems to work in our hospital now (runs for just a week in production). Would be great if someone is interested to test in his/her hospital environment to see what we encounter.

  13. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
new
Component
Import: RDSR
Milestone
Future
Votes
0
Watchers
2
Jira Software: the preferred issue tracker for Bitbucket. Join the team!