> 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
