gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Fwd: Lab data support in OSCAR


From: Jim Busser
Subject: [Gnumed-devel] Fwd: Lab data support in OSCAR
Date: Wed, 5 May 2004 21:08:41 -0700

For interest and comparison, here is the approach to lab data taken to this point in OSCAR. The angle bracketed items (>) are my postings to their local list, and the replies are those of an IS person working to add to and improve OSCAR's functionality on behalf of a local clinic.

One other functional design element not included below is the need to "flag" new results as having to be looked at by a doc in the clinic, perhaps flagging abnormal results as even more important, and to capture the fact once these have been viewed (i.e. by which doctor). Is it felt that such functionality, and some items listed below, should be targets for GNUMed?

 > preferably there would be the ability to support / enable
 > manual MD input of test result data e.g. historical or otherwise
 > not importable/interfaced electronically, where it is of sufficient
 > value/interest to the doctor to input

We have not included this feature, although it could be added with ease in the future. This addition would probably require separate database tables,
as our lab system is built strictly to handle HL7 lab data.

 > - batch download and processing of resulted tests (automated via
 > schedule) which I expect is a given basic minimum for an EMR

Yes - the lab module downloads and processes test results automatically
every 10-20 minutes (this value is easily configurable).

 > - user-triggerable downloads and processing, for example where the
> Oscar (or source lab) server had been down and come back up and where
 > a scheduled pickup would have been missed. Alternatively where a
 > patient is sitting with you in the office and it is suspected that a
 > patient's important results could have come available since the last
> scheduled batch job - here it would make the doctor's job easier than
 > to have to phone the lab, wait on hold, and then handle results by
 > phone/fax until they can be later imported.

Missing a lab "pickup" shouldn't cause any problems, as the lab results sit
in a queue on PathNET's servers until they are downloaded.  We could
probably give the user the option to trigger PathNET downloads manually. However, PathNET has a minimum delay between downloads (10 minutes). Thus, user-triggerable downloads, while possible, wouldn't be very useful due to
PathNET's setup.

 > match and link results to individual patients PROVIDED the i.d.
 > tags meet pre-defined criteria, otherwise offer soft matches
 > for users to confirm (with undo ability)

Our lab module automatically matches Lab data to OSCAR patients based on PHN numbers. However, users must verify the matched data before it is "Linked" to the patient's EMR. As well, users must manually link any lab results that are not matched automatically. Undo functionality is provided. You
can find a screenshot of our "Patient Linking" page here:
http://blake.redirectme.net/oscar/lab1.jpg

 > - unmatched data could represent a patient who does not yet exist in
> OSCAR yet can still be pertinent to the practice (patient referred in
 > but not yet seen/registered, patient seen outside of OSCAR eg at
 > hospital and may be seen at the office for the first time in
 > followup) - here it would be convenient if the software could permit
 > a new patient to be created from the lab data reconciliation screen
> and could helpfully take advantage of info already present in the lab
 > data file (it might include name & demographics?)

It would be possible to do this, but probably not useful due to the nature of PathNET's demographic data. For example, their (patient) first, middle and last names are all returned in one field, and the patient address is
also contained in a single field (Street Address, City and Province
combined). These data fields could theoretically be parsed and split for insertion into an OSCAR demographic record, but the process could be rather messy. I believe it would be simpler from a user perspective to enter the
demographic data into OSCAR manually.





reply via email to

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