> Source files will contain messages that pertain to multiple patients > in one of (I think just) four scenarios: > ... persons who already exist in GNUmed and are automagically > matchable i.e. according to configurable rules that define the > adequacy of a match as not needing user verification Yes, see my other post.
> ... persons who already exist in GNUmed but whose matching requires > user assistance (or, at least, verification) IOW where there's ambiguity as to what the match should be. Goes into clin.incoming_data_unmatched with a strong set of candidate matches. > ... patients who do not yet exist in GNUmed but who are appropriate > to create from the data as a new patient) Those go to clin.incoming_data_unmatched with an empty candidate set. > ... patients who do not yet exist in GNUmed who the praxis may not > wish to create (e.g. information sent in error) As do those. > regarding this last use case, the praxis may choose to create the > person, even though the person did not receive care, to capture the > communication to the lab about their error I agree. Those which the praxis decides to not create will go to clin.incoming_data_unmatchable. > One thing I am wondering is whether the parser (Mirth or Hapi) will > be smart enough to evaluate and distribute, in a single pass through > the source file, every message according to rule-based decisions to > determine different places in the backend into which to write the > information, or whether all messages will need to be imported into a > table, each of whose rows would hold one message in raw data form. If necessary we can always setup another staging table fronting clin.incoming_data_unmatched. > All messages *could* be imported into the table > clin.incoming_data_unmatched > > where the auto-matchable records would be migrated out of the table. correct > This would leave behind those for which an algorithm can suggest a > match, and one other class of message results, which would depend on > a user salvaging a match, or abandoning messages which could then be > moved over to > > clin.incoming_data_unmatchable correct > So here is another question... even if it is decided that Mirth or > Hapi could evaluate the matching rules, and --- for the well-enough- > matched records --- write the results into the clinical tables, we > would still end up with some of the message information going into > incoming_data_unmatched Surely. > and into incoming_data_unmatchable, But only after human intervention. > and so we > would need a way for some of *that* data to be re-processed after the > identity of the patient had been confirmed or provided. Sure. > So > essentially, we would need to use the output of a query on the user- > matched records as the input for a post hoc reprocessing of those > messages. So if processing will need to be done from these tables > anyway, is there value having a front-end channel to intercept part > of the data? It might well make sense to have HAPI/Mirth import all data into clin.incoming_data_unmatched and have a (GNUmed-side) demon go over *that* and produce candidates moving unambigous matches into clinical tables. Makes sense, yes. Would need to be triggered somehow, however. Karsten -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
