[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Backend support for a record of incoming data "jobs"
From: |
Jim Busser |
Subject: |
[Gnumed-devel] Backend support for a record of incoming data "jobs" |
Date: |
Fri, 24 Jun 2011 01:08:44 -0700 |
When looked-for results cannot be found in an EMR, the questions are
- did the patient / specimens make it to the lab?
- was there any problem or delay in the lab?
- is the result available?
- did we receive it yet?
An easy "check" would be
when did the EMR last receive and process *any* results.
For that reason (and more) I would like to suggest a table
incoming_data_log
with fields
job_start datetime
job_end datetime (or "duration" of type interval)
process_ip
process_num
process_user
db_user
data_source_ip
data_source_url
file_specification
script_specification
encounter_number
records_imported
exit_status
exit_comments
what I was thinking in regard to "process_" fields was to identify the machine
from which the download / import was being driven… thinking these could help IT
support to track down problems in case the processes had problems associated.
Not all fields would be used for every transaction:
- the table might separately capture automated download and import events
- downloaded files might, in some cases, be obtained by a manual step via web
login; in such cases, there would be no record of data sources
- imports would reference the file specification of whatever the user had
manually deposited into the directory watched by the importer (cron) script
- records of download-only would not populate the encounter_number and
records_imported fields
-- Jim
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnumed-devel] Backend support for a record of incoming data "jobs",
Jim Busser <=