The dangers of assuming Patient ID is a unique key - DICOM

This is a discussion on The dangers of assuming Patient ID is a unique key - DICOM ; There is a thread on AM that anyone who is contemplating or already sharing MRNs from different organizations in the same PACS absolutely needs to read and understand: http://www.auntminnie.com/forum/tm.aspx?m=145473 There are a lot of lessons to be learned from this ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: The dangers of assuming Patient ID is a unique key

  1. The dangers of assuming Patient ID is a unique key

    There is a thread on AM that anyone who is contemplating or already
    sharing MRNs from different organizations in the same PACS absolutely
    needs to read and understand:

    http://www.auntminnie.com/forum/tm.aspx?m=145473

    There are a lot of lessons to be learned from this about use of patient
    related DICOM attributes in MWL, Q/R and composite instances in RIS,
    PACS and workstation design, and the danger of assuming Patient ID is
    a reliable unique key.

    David

  2. Re: The dangers of assuming Patient ID is a unique key

    On Tue, 24 Jun 2008 09:20:47 -0400, David Clunie
    wrote:

    >There are a lot of lessons to be learned from this about use of patient
    >related DICOM attributes in MWL, Q/R and composite instances in RIS,
    >PACS and workstation design, and the danger of assuming Patient ID is
    >a reliable unique key.


    The main problem is that DICOM does not specify WHAT uniquely
    identifies a patient.

    As far as I know the patient-id should be unique within one instituion
    ... as long as you do not mix images from different instituions without
    correcting the patient-ids you should have no problems.

    What do YOU recommend for identification of patients uniquely
    'worldwide' ?

    Of course you can always have sites which give all patients the same
    patient-id, study-instance-uids etc.

    Having patient-id, name, birthdate as key doe not work either (think
    of marriage) ...


  3. Re: The dangers of assuming Patient ID is a unique key

    You have to distinguish between fully integrated environments, where
    you can/have(*) to trust Patient IDs and non- or rather loosely
    integrated environments, where you have to consider also patient
    demographic information to identify a patient.

    (*) IHE Patient Information Reconciliation (PIR) Integration Profile
    requires that an Image Manager/Image Archive has to update the Patient
    Information in MPPS and DICOM Composite Objects received from
    modalities, because the modality may have fetched the MWL item before
    the ADT sent a Patient Update to the Order Filler, which forwarded the
    Patient Update also to the Image Manager. S. IHE PIR Use Case 6:
    Patient Information Reconcilation During Image Acquisition.

    The Open Source Archive application dcm4chee (www.dcm4che.org) uses
    the existence or missing of Issuer Of Patient ID (0010,0021) in
    received MPPS and Composite Objects to control, if only Patient ID +
    Issuer Of Patient ID, or if also Patient Name and Birth Date is used
    to match an existing Patient Record with the received object. And for
    "trusted" modalities which does not copy Issuer Of Patient ID from the
    MWL item into MPPS and Composite Objects, you may configure to add
    Issuer Of Patient ID on receive, before such match is performed.
    --
    gunter

  4. Re: The dangers of assuming Patient ID is a unique key

    On Wed, 25 Jun 2008 02:27:27 -0700 (PDT), gunter zeilinger
    wrote:

    >You have to distinguish between fully integrated environments, where
    >you can/have(*) to trust Patient IDs and non- or rather loosely
    >integrated environments, where you have to consider also patient
    >demographic information to identify a patient.

    that is right, normaly we target more the fully integrated
    environments, because our system was primarly build for large MG
    screening sites.
    Of course we could make it better, the question is how important is
    this for our customer .. how many end-user-sites have such problems
    and how big are they?
    (that means Licenses vs. Problem )
    We are already thinking of a better solution but its not our part to
    decide which features to include and which not.
    Maybe we go for a fixed solution (bad idea), configureable number of
    identifying tags (better) or an adaptive approach as you suggested
    (even better).

    And of course the assumptions about the Patient-ID are in the
    documentation .. even in the DICOM conformance statement; it does not
    hit without warning.

+ Reply to Thread