[Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results)

[J Busser]

Is the table purposely named to disaggregate it (in any listing) from 
test_results? Can we instead use test_result_unmatched?

Or in fact, would people import fetched results into a staging table 
and should this table be part of the schema? I suppose it would have 
"core" fields, and maybe additional fields which would depend on the 
source laboratory or data clearinghouse. Would the preferred approach 
be to see whether core staging table can serve many data sources? I 
might think that instead of writing unmatched results into an 
"unmatched" table, we are really taking about the records that are 
"leftover" from the staging table after being unable to be matched? 
Or is it proposed to move them out into another table for workflow 
purposes?

>  > > > I still need a simple table for unmatched [path] results, 
> something like:
> >  Canada (British Columbia) will need the same thing.
> Here is the status quo:
>
> #----------------------------
> create table unmatched_test_result (
>         pk serial primary key,
>         fk_patient_candidates integer[],
>         request_id text
>         firstnames text,
>         lastnames text,
>         dob date,
>         postcode text,
>         other_info text,
>         type text,
>         data text               -- bytea, perhaps ?
> ) inherits (audit_fields);
>
> select add_table_for_audit('test_result');
>
> comment on table unmatched_test_result is
>         'this table holds test results that could not be matched
>          to one single patient automatically, it is intended to
>         facilitate manual matching,
>
>          - use "modified_when" for import time';
> comment on column unmatched_test_result.fk_patient_candidates is
>         'a matching algorithm can be applied to produce
>         a list of likely candidate patients, the question
>          remains whether this should not be done at runtime';
> comment on column unmatched_test_result.request_id is
>         'request ID as found in <data>';
> comment on column unmatched_test_result.firstnames is
>         'first names as found in <data>';
> comment on column unmatched_test_result.lastnames is
>         'last names as found in <data>';
> comment on column unmatched_test_result.dob is
>         'date of birth as found in <data>';
> comment on column unmatched_test_result.postcode is
>         'postcode as found in <data>';
> comment on column unmatched_test_result.other_info is
>         'other identifying information as found in <data>';
> comment on column unmatched_test_result.type is
>         'the type of <data>, eg HL7, LDT, ...,
>          useful for selecting an importer';
> comment on column unmatched_test_result.data is
>         'the raw data';
> #--------------------------------
>
> >  I can contribute some suggested fields in the next week or two if
> >  there is no rush defining the table.
> Please do !
>
> Karsten
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel