[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Lab import (data) matching

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Lab import (data) matching
Date: Sun, 03 Feb 2008 23:18:50 +0100

> Before we can develop something configurable in which GNUmed  
> installations can define their rules for matching, we would have to  
> figure out the kinds of requirements.
It is most important to find out the *minimum* requirements for your
use case. It is easy to overdesign with all kinds of (useful and
desirable) bells and whistles. The first iteration must be simple
but effective, IOW focussed or else it will never get off the ground.

> In the case of having "unique" outgoing reference numbers that could  
> be returned to GNUmed and assist a "match", I think such numbers may  
> not always be enough, by themselves, for two reasons.
Such number can surely be in error but there is no way to make
them fail-safe, not even scanning.

A certain amount of trust is needed. Preferably that trust is
backed by a audit trail enabling the user to trace the decisions
taken by them system when needed.

I propose the following approach:

- define a "system" (expected-to-be-there) external ID type "lab request ID"

- enable the user to associate such IDs with patients
  - this already works but can be further refined

- the importer auto-matches those results which coincide in either:
  - firstname, lastname, dob, and gender
  - or lab request ID and - when available - any of the above
  - or lab request ID only if none of the above is available
    (IOW pseudonymized results)
  with *existing* patients

- the importer imports *all* other data into clin.data_unmatched

- eventually the importer will try its best to add candidate
  matches (there's a field for that) via any of the options you

- if incoming data contains a flag for "complete" (rather than partial)
  and it is matched to a patient via a lab request ID that ID is
  removed from that patient (it'll still be there in the
  lab requests table)

- partial are initially imported as if they were a complete result set
  on their own, IOW, there'll be consecutive result "batches" possibly
  with repeated values - ugly but safe - the result status may be set
  to "partial" and the GUI may later decide to exclude repeats but
  we don't "throw away" data in the initial implementation

Anything I missed here ?

> The biggest problem to matching is usually variants of the first or  
> middle names or exchanges between them e.g.
>       Smith, Ann Marie
>       Smith, Annie M
>       Smith, Marie
>       Smith, A Mary
> can be different forms of the same person.
Sure, but there's no way to avoid that. But they will all provide very
good candidate matches from which a user can easily select the proper

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]