gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: Mirth channels and HL7 import for the GNUmed proj


From: James Busser
Subject: Re: [Gnumed-devel] Re: Mirth channels and HL7 import for the GNUmed project - test source message
Date: Tue, 09 Sep 2008 17:19:36 -0700

On 9-Sep-08, at 4:43 PM, David Mackenzie wrote:

Hi Karsten,

may I ask you to document the steps that were necessary on
our Wiki ?

Certainly. I'll start on it tonight when I get home.

:-)

I have created a stub named "Mirth Project" given that is the URL (www.mirthproject.org) located on the wiki page

http://salaam.homeunix.com/bin/view/Gnumed/TestResultImport

thus if you just click the "?" following "Mirth Project" on that page and then login (having created a wiki account) you can fill in the "Title" and "... content goes here."  Above the editing window you will note a link "Show help" which will display formatting information ---++(+) for headings, *bold*, _italics_ etc.

I will probably do the Mirth code analysis on the weekend. I suspect that you would also like a recommendation for a solution to HL7 messaging? What is a typical scenario for how HL7 messaging is used. Is it the following:

1) A system(s) sends an HL7 message to the Mirth Server

In my locale, a fetcher program would typically write files into a directory which Mirth would monitor and respond-to by importing... this is the basis of the channel that is under development. I beleive In Australia they receive encrypted messages (whose content may not yet be HL7) emailed to them, and the practice server decrypts these automatically using a key stored on the server and (I think) PROCMAIL.

2) The Mirth Server processes the message, decodes it, and stores the data within the message in the GNUMed database

stores *a copy of* the data in the GNUmed database. Mirth does also maintain a copy in its own database. The Mirth database might nicely permit repurposing of its content for example providing the patient a nicely formatted PDF of certain results though I did not yet look at that. I suppose Mirth might more easily than GNUmed produce a copy of (or a subset of) a patients' results if another doctor who was not using GNUmed wished to have an importable HL7 version of a patient''s results sent to them.

Depending on whether the message can be unambiguously identified with a person (patient) the message gets added to the patient's record (lab tests are added to clin.test-result) and otherwise added to clin.incoming_data_unmatched. It is possible that we might in future receive HL& messages about patients for things that are not test results. Time will tell.

3) The GNUMed client can then access the data from the database

Yes, within which there is the intent for the client to be able to help to match the unmatched messages so that Mirth could re-process them into the correct patient record.

Once the HL7 message has been decoded and stored in the database, is there a need to refer back to the original message? I am assuming the HL7 message is decoded and is now just data in the database.

See above.

Will GNUMed ever be sending HL7 messages to the Mirth Server?

Not sure yet. I expect Mirth could be very suitable for interchange. For example the channel used to write data from Mirth into GNUMed might be reverse engineered without too much trouble and any medical practice system that had a Mirth channel could in this way interchange their information.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]