[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] how to do intended_reviewer / requestor? (was: HL7 te
Re: [Gnumed-devel] how to do intended_reviewer / requestor? (was: HL7 test results import.)
Mon, 9 Aug 2010 07:24:14 -0700 (PDT)
ok, this is the third in the series on this topic (whew!) - this one involves
a proposal where, instead of shoe-horning the "auto-create" concept into
existing gnumed table structure so as to avoid the (imo painful) need for
praxis administrators to get remotely near the raw HL7 data, some simple
changes are made to clin.lab_request and clin.test_data.
the changes are very very simple:
a) the clin.lab_request.fk_identity field is allowed to be NULL
b) the clin.encounter fk_patient field is (unfortunately) allowed to also be
c) a string field "unidentified_person" is added to clin.lab_request
d) the clin.test_data intended_reviewer field is allowed to be NULL
e) an array of string fields "unidentified_reviewers" is added to
the need for b) is because you absolutely absolutely _must_ have an
encounter entry, it is the _only_ way to maintain the inter-relationship
between OBRs and their associated OBXs - there _is_ no other way (except to
create a new database table). so, for the above to work, clin.encounter's
fk_patient field has to be NULL (and/or an "unidentified_patient" string
restraints can be added which either allow fk_patient _or_
unidentified_person field to be set but not both and not neither (an XOR
these simple changes would make it possible to absolutely guarantee the
insertion and import of (syntactically-correct) HL7 data, as any unmatched
patients or practitioners would go into the "unidentified" string fields.
by having a string array, you could even store both the copies_to and
intended provider fields, even if _those_ were "unidentified".
and, you would have the added advantage of not having to create "fake
patients" or "fake staff"
_and_, the same code and the same procedure could be used for _other_
importers: they _too_ could "always succeed".
View this message in context:
Sent from the GnuMed - Dev mailing list archive at Nabble.com.