Re: [Gnumed-devel] Re: A few questions

[Karsten Hilbert]

On Wed, Jan 27, 2010 at 11:56:49PM -0800, Jim Busser wrote:

>> 1) In Australia, messaging between ... Does GNUMed
>> already have a way to handle incoming messages, and, either
>> pass them to Mirth or Mirth poll a database/directory for
>> them? Or does this functionality have to be either
>> built/borrowed?

GNUmed will try hard to concern itself with incoming
messages as little as possible. IMO, a sane workflow would
be (and this is how I believe things should work):

1) new data gets onto the local machine "somehow"

        - it should not matter whether this is via automatic or
          manual download, copied from some media, saved out of
          an email, you name it
        - this will be different per lab
        - it should not matter at all which format the incoming data is in
        - this should be neither GNUmed's nor Mirth's responsibility

2) new data is picked up by Mirth from the local machine

        - it should not matter how it got there
        - either Mirth polls a place looking for data
        - or Mirth is somehow signalled to re-start processing
          (there are several thinkable ways to do that)
        - Mirth can only pick up HL7 data (AFAIK) and that's OK
        - after pickup Mirth could either delete the local source
          or move it to an "old stuff" area because it will keep
          the raw data in its own data store
        - GNUmed should not have anything to do with this step

3) Mirth processes the new data

        - if it can match data to a patient it will import it
          into GNUmed for that patient
        - if it cannot match data to a patient it will import it
          into GNUmed under clin.incoming_data_unmatched keeping
          the raw data as-is in clin.incoming_data_unmatched.data
        - GNUmed is only used as the target datastore

4) GNUmed notifies the provider about unmatched data

        - the provider will have to look at the data and take
          appropriate steps to correlate which patient the data
          belongs to
        - GNUmed could notify Mirth to re-process the data
          taking into consideration the doctor's correlation which
          would make Mirth re-do step 3)

5) or Mirth could poll for now-correlated previously unmatched data

        - this would make it re-do step 3)

I believe this puts the least amount of coupling between
things. The concept is much like printing :-)

> At present the lab results supplier gives no good option
> except to require a credentialed user to perform an attended
> (manual) login via Firefox to load the XML messages and then
> do a "Save As" saving the file into a local machine or local
> server directory. The lab does also supply a non-browser GUI
> client for Windows, but this also requires an attended
> connection and only save a couple of user steps, but without
> enabling automatic downloads.

I would think this may be possible to be scripted - if the
login is standard https login even wget can do it. Other
than that it would need to be page-scrape scripted. All this
only concerns step 1 in the above workflow.

> Mirth could be set up to point to, and poll, a stable
> destination directory and I would propose that an additional
> step in the Mirth import script, after the import would be
> completed, would move the source file to a different (e.g.
> "imported") directory.

Step 2

>> 2) The current medical software programs dad uses have
>> the concept of a "message holding bay", whereby doctors can
>> view all messages that have arrived at the surgery and chose
>> to import them into the database.
>>
>> There is a screen which lists all the doctors names as
>> found in the incoming messages with some details about the
>> message. Is this a feature you are familiar with and desire?
>> This would be a feature of GNUMed and not Mirth. Mirth would
>> simply put the messages into the "message holding bay" in
>> the database.

That would be our to-be-written viewer for
clin.incoming_data_unmatched which would only show what
Mirth wasn't able to automatically import for doctors to
correlate with a patient after which Mirth would re-do its
thing.

> 1) allow the raw messages to live in Mirth
> 2) Mirth would try to match messages to identifiable patients in GNUmed
> 3) Mirth would write matched results into GNUmed results tables etc
> 4) Mirth would write unmatched lines (messages) data into
>       clin.incoming_data_unmatched
> 
> so #4 could be what you describe (as unmatched results) for the doctor to 
> know about.

Yep, that's what we want.

>> This may need to be thought through a bit further, as
>> the messages may require further parsing once the import to
>> database function is selected.

Well, GNUmed would still not concern itself with importing
messages. It would only make doctors correlate patients to
unmatched messages upon which Mirth would, again, import
those messages based on the new information

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346