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)
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.
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?
This gives a pk_identity or pk_staff for searching/constructing in lab_request.
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.
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
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.
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 ),
and test_results can be created which can be linked into lab_requests.
What needs to be done on the backend may be more precise fields in lab_request
to
store loinc_code, and loinc_name ?
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
