Re: [Gnumed-devel] proposal for HL7 v2.3 to gnumed parsing

[Karsten Hilbert]

> The samples given seem to show 
> there is a common order of segments for
> a given set of test results for one patient
> 
> MSH ( 1, message header)
>  PID ( 1, person id)
>    OBR ( 1,  obs request)
>     OBX ( many,  observation results)
>    ORC  ( 1 ,order control,  not in AU example, but in Oscar example)
Sounds reasonable.

> The proposal for mapping is :
> as parsing hits PID, 
> 
> patient_name , date_of_birth  is used to match a patient.
> If no match, match to dummy "unmatched" patient.
> Result is a pk_identity for later use.
What if several matches occur ?

Please also consider using test_result_unmatched and propose
improvements thereupon if necessary.

> parsing Hits OBR,
> if the message has ordering_provider field, which has a form
> (id, title, firstname, lastname) , then an attempt is made
> to match in v_staff
> also attempt to match to each ~ separated provider 
> in results_copies_to field, if it exists.
> If no match, then ? match to staff who has corresponding current_user name?
Either that, yes, or - however a lot more complicated - try
matching the time to an encounter and get the staff from that
encounter.

> This gives a pk_identity or pk_staff for searching/constructing in 
> lab_request.
Another useful option is to let the user define a database
account to be used for importing lab results. In that case
there could be a dedicated account just for import - at
whatever granularity of lab/source etc - which allows tracking
which data came from which source, eg data associated with a
given account was auto-imported. I'd vote for that approach.

> the time fields 
> requested_date_time , quantity_timing, specimen_received_date_time,
> observation_date_time , results_report_status_change,
> 
> may need to be matched to existing or extra fields on lab_request.
yes

> the universal_service_id  which as a minimum consists of
> loinc_code , and loinc_name   needs to be matched to something on
> lab_request. e.g.  The request HepS.5 , Hepatitis Serology
Off the top of my head you'd need to match something in
test_type and/or test_type_unified.

"Our" concept of request is one level above "test type" in
abstraction. It signifies that "something" was requested from
the lab, not what. Here in Germany at least you'll hardly get
people to enter what they request into a computer since
they'll have to manually mark it up on lab slips anyways.

Nonetheless allowing for lists of requested test results
(maybe in a table adjunct to lab_request ?) is certainly a
consideration for places where people do enter the tests.

> If a lab_request can't be selected according to the requested_date_time
> and loinc_code / loinc_name, 
> then perhaps one linked to a dummy "unknown requestor" staff can be created.
> This helps for say when someone outside forwards a result for a common patient
> to you.
IOW when we do not find a request for incoming data. We could
either make one up - or else just store the test results
without linking them to any request ... This is possible since
we link them via a lnk_result2lab_req table that does not
enforce direct linking inside test_result (which it shouldn't
in any case btw as test_result is wider in scope than lab_request).

> once the lab_request is found or created, 
> then obxs are parsed according to their type NM ( numeric), ST ( short text)
> FT ( free text  - > ? goes in a narrative ),
test_result.val_alpha I'd say

> and test_results can be created which can be linked into lab_requests.
yes

> What needs to be done on the backend may be more precise fields in 
> lab_request to 
> store loinc_code, and loinc_name ?
I would not put loinc_code or loinc_name (not even generic
code, name fields) directly inside lab_request. But if
necessary I do support adding a table to allow for linking
requested tests to a lab_request where fk_lab_request might
even be NULL.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346