[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: A few questions
From: |
John Mackenzie |
Subject: |
Re: [Gnumed-devel] Re: A few questions |
Date: |
Thu, 28 Jan 2010 23:28:44 +1100 |
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
Re: [Gnumed-devel] Re: A few questions, Karsten Hilbert, 2010/01/28
Message not availableRe: [Gnumed-devel] Re: A few questions, Karsten Hilbert, 2010/01/28