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

[John Mackenzie]

Where does the doctor's checking of the incoming data 
(pathology, radiology results etc) come in ? ... 

The doctor needs to sight these results, then designate 
that the result is either: 
a) normal -> file 
b) abnormal -> non-urgent notify or review of patient 
c) abnormal -> urgent notify or review of patient. 

John Mac
(Oz GP) 

> On Thu, 2010-01-28 at 11:58 +0100, Karsten Hilbert wrote:
> 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