Why not to change patientID of a dicom image

    This is an attempted explanation for a problem that can occur in DICOM when you change the patient ID if an image (explanation work in progress):


    A dicom image is identified by four identifiers:


    patientID e.g., 9904321
    studyUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7766
    seriesUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7767
    imageUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7768


    UID's have no meaning except that are intended to be globally unique, that's why they are so long.


    When an image is stored in conquest or other dicom archives, four databases are updated: DICOMpatients, DICOMstudies, DICOMseries, and DICOMimages. The UID's are keys to this table, i.e., each record has a different UID. The study database refers to the patientID, the series database refers to the studyUID, etc. When multiple images of the same series are loaded only the DICOMimages database grows, the rest stays the same.


    When you query the database or load an image it is a simple matter to go through the databases to access all image, study, series and patient related information.


    What happens when somebody edits the patient ID and stores the same image again in a DICOM server?


    patientID e.g., 9901234
    studyUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7766
    seriesUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7767
    imageUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7768


    The server should see that the image is already stored - no change. It should see that the series is already stored - no change, and that the study is already stored - no change. But then, it sees that the patient ID differs. It could change the patientID in the study database and this image is stored correctly. But all other images stored before would become invalid: the database does not correspond with the other images of the series. Or it could keep the old patientID and then the modified image would become invalid: the database does not correspond with the image.


    So actually, the server has no choice but to reject the modified image: because the same image, series and study would belong to more than one patient. This happens on most full sql servers, as the uniqueness of the UID index to the study databases would be broken. However, on older versions it does not happen on dbaseIII: this is a bug. Actually in dbaseIII the study would be entered twice, each with a different patientID. But a series or image query will return only a single study, so the images of the other patient are 'lost'. This bug is fixed in 1.4.14beta.


    If you do need to change the patient ID, use the conquets dicom server to do it. In the conquest dicom server, all UID's are changed when the patientID is changed: so that the modified image does not conflict with the original image when loaded into the same archive. The relation between old UID and new UID is kept in table UIDMods, so that multiple images can be modified wihout breaking their organization in series and studies. This mechanism is used for "change patient ID", anonymize, split and merge.


    Marcel

    Hi,


    On the commandline, I suppose you have to implement
    dgate --modifypatid:patid,file
    for each of the images where the PatID have to be changed.


    Or is it possible to change patid for a study within one command?


    Chris

    Hi,


    Here are a couple of way to change patient ID correctly of an entire study:


    1) use the windows GUI


    2) write a batch file that extracts all filenames and runs dgate --modifypatid:patid,file on each file. Examples can be found in the forum


    3) with 1.4.16: create a zip file from a study (e.g., using dgate --export:patid,stuid,,,file.zip), and run dgate --addimagefile:zipfile,patid, this will add the study with all images with a new patient ID.


    4) with 1.4.16: use dgate '--export:patid,stuid,,,file.zip,newuids;set PatienID to "newpatid"'.
    The latter part is a script that is run for each exported image.


    Marcel

    Hi,


    in version 1.4.16e there is a command that should allow such operation in one statement:


    dgate '--modifystudy:patid,studyuid,newuids set PatientID to "newpatid"'


    or (change the entire patient):


    dgate '--modifystudy:patid,,newuids set PatientID to "newpatid"'


    the syntax is:


    dgate --modifystudy:patientid,studyuid,script


    where script is anything you can do in an ImportConverter (see manual). newuids generates all new uids, then you can change any dicom tag you like. Still waiting for somebody to write a nice gui for linux, or add stuff like this to the web interface.


    Marcel

    If deleting the patient to allow the incomming data to get stored (without Conquest refusing because of PatientId/Uid conflict), you could clean up the database by running the following sql AND manually delete the patient folder(s) containing the DICOM files.


    IMPORTANT: Only do this if the existing files are unwanted and blocking for the correct files to get stored.


    Code
    declare @PatientId varchar(64) = 'MamEdxt'delete from DICOMSeries where StudyInsta in (select StudyInsta from DICOMStudies where PatientID = @PatientId)delete from DICOMSeries where SeriesInst in (select SeriesInst from DICOMImages where ImagePat = @PatientId)delete from DICOMPatients where PatientID = @PatientIddelete from DICOMStudies where PatientID = @PatientIddelete from DICOMImages where ImagePat = @PatientId


    We use the sql listed above, because Conquest/dgate cannot delete a patient if the database is in a invalid state (for some reason). For example: the patient is not delete if the patient does not contain any study! In the example below the patient exists with several images but no study


    Code
    declare @PatientId varchar(64) = 'MamEdxt'

    select * from DICOMPatients where PatientID = @PatientId    -- 1 row

    select * from DICOMStudies where PatientID = @PatientId     -- 0 row

    select * from DICOMSeries where StudyInsta in (select StudyInsta from DICOMStudies where PatientID = @PatientId) -- 0 row

    select * from DICOMSeries where SeriesInst in (select SeriesInst from DICOMImages where ImagePat = @PatientId)   -- 1 row

    select * from DICOMImages where ImagePat = @PatientId     -- many rows

    Hi Marcel,


    I'm running into an issue perhaps related to this. We are doing a migration where the source PACS has been storing exams with duplicate Series UID's. I'm using Conquest to assign new UIDs with an ImportConverter (newuids). But, I often see exams with the following error.


    [UIDFIX] ***Refused to enter inconsistent link StudyInsta into DICOMSeries: PatientID = 'RMCxxxx' SeriesInst = '1.2.826.0.1.3680043.2.135.736541.53602582.7.1501619801.513.54' AND SeriesPat = 'RMCxxxx', Old='2.16.840.1.114151.4.292.40946.5553.2639799', Refused='1.2.826.0.1.3680043.2.135.736541.53602582.7.1501621959.553.88'


    Conquest fails to store these. If I am having Conquest change the UID's as they arrive, why do I continue to see this error? How can I fix them?


    jeff

    Hi,


    newuids changes data consistently, i.e. all of series A are changes to to series B, and all of C to D. So if there is a conflict it stays. You can try "newuids stage %VPatientID", which would create a 'new' database for each patient ID; but you will have to choose a stage variable that would keep consistent data together but breaks inconsistent links.


    Marcel

    Hi Marcel,


    This is working for the most part, although the variable I'm using is SOP UID. The remote PACS is a mess though. I'm still seeing some with the same inconsistency error, so I'll have to figure out what variable to use for those.
    Thanks for your help!


    Jeff

    Hi,


    What if I have to change the patient ID?

    Situation: there is a conquest with 5000 studies where every study got the patient id = 00000000. Thats the only data in there. There is no way to sort this and we want to send them to an archive, which wants a unique patient id. Otherwise it won't accept the image for different demographics (age, sex, name).

    My wish would be an import converter or something similar which adds an autoincrement prefix. So the first study becomes 0000001 and the 123th study becomes 000000123 and so on. Is there a way to do this?


    Regards

    Sebastian

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login