> I am realizing a problem GNUmed will suffer in BC, CA (very possibly > elsewhere as well) where, until all parts of the request had become > finalized, it is possible that one or more tests could get cancelled > or recoded or deleted, communicated only in the more-general level > OBR without the detail of the specific OBX that we would have already > imported being re-provided. > > One example would be a value that was originally reported as a random > glucose, becoming reclassified as a fasting glucose. While the lab > will re-issue an OBR for the original test code "random glucose" > indicating that it had been X-revoked, the lab does not re-issue the > OBX detail. It only supplies a new OBR and OBX for the seemingly-new > fasting glucose. Unless the hl7 data contains anything making it possible to find out which OBXs the OBR change relates to no software can automate that. One can, however, invalidate *all* OBXs connected to the revoked OBR which, by all means, revoking the root node of child nodes can sensibly only mean. The OBX-to-OBR relationship would be captured in the test_result to test_panel (to be created) link. We may indeed have to create a clin.test_panel table in which to capture OBR instances. If we make the foreign key nullable we can leave out OBRs where they aren't used (as in Germany) or at a later time derive them at order entry time if labs don't (re-)provide them.
> It leaves me unsure how we would relate the already-imported > test_result to the new message that its parent test_code was re- > received and is communicating that it (the "child" result) was to be > considered invalid or cancelled. We cannot unless requests are uniquely identifiable (even if only temporarily). > PS just making sure we have the same view that test_type_unified has > the purpose of what we, in GNUmed, develop internally as a clinically > useful internal scheme. - internally, yes - clinically useful, yes - but not as in "panel" test_type_unified serves to group GLUC GLU BS (blood sugar) which all report the same physiological value but are named differently by different labs or the same lab over time. Personally I would NOT group SGLUC (serum glucose) UGLUC (urine glucose) via test_type_unified for obvious clinical reasons. *Such* a grouping would be achieved via test_types_profile -- locally, user-defined, lab-independant groupings of independant but clinically related lab tests, say: liver enzymes diab screening It should be separate from any capture of how > local labs group and label their various tests into test_codes or > test_panels or test_profiles whatever we use to store this, because > these labs all call them different things. Correct. There's three groupings we eventually want: test_panel - groups ordered tests and returned results test_profile - groups different tests clinically test_type_unified - groups the same test received under different names The first iteration will only support test_panel as OBR vs OBX requires that. The others are convenience for now. Karsten -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
