Can anyone share with me how they are resolving Pt name conflicts? I am trying to set pacsone up as a telerad solution, after which hope to begin doing softcopy reads. We currently don't have a RIS/HIS interface (Anyone know of a free/cheap interface to meditech) so if pt names are entered in just the least bit different manner the study is rejected by Pacsone.
Is there a way of accepting the study but putting it into a temporary database? then the next morning the data could be corrected and merged with the main database? Anyone have 2 servers running, 1 for telerad, 1 for pacs?
Any thoughts?
Thanks- Jeff
RESOLVING ID CONFLICTS
This seems like a request for new feature, but the real difficult part is how to resolve such patient id conflicts?
For example, let's say we have a method of storing the new study with the conflicting patient id into a temporary table somewhere, now how do you propose to fix the two patients with identical patient id?
You could try assigning a different patient id to either the existing or the new patient, but:
1. How do you guarantee the newly assigned patient id is unique so that such conflicts will not occur again?
2. Now that the patient id has changed for one of the patients, existing or newly received, but the users are not aware of the newly assigned patient id, so when they perform a search by patient id, there's a 50% chance that they actually find the other patient by surprise.
The only real solution is to fix the duplicate patient id problem at the source, which is when the patient ids get created by some centralized source, e.g., HIS/RIS server. If you don't have such a system, it should still be easy to find a program to generate globally unique ID strings to use as patient ids. (Try Goggle for 'GUID algorithm' or 'Globally Unique ID' from the search engines)
For example, let's say we have a method of storing the new study with the conflicting patient id into a temporary table somewhere, now how do you propose to fix the two patients with identical patient id?
You could try assigning a different patient id to either the existing or the new patient, but:
1. How do you guarantee the newly assigned patient id is unique so that such conflicts will not occur again?
2. Now that the patient id has changed for one of the patients, existing or newly received, but the users are not aware of the newly assigned patient id, so when they perform a search by patient id, there's a 50% chance that they actually find the other patient by surprise.
The only real solution is to fix the duplicate patient id problem at the source, which is when the patient ids get created by some centralized source, e.g., HIS/RIS server. If you don't have such a system, it should still be easy to find a program to generate globally unique ID strings to use as patient ids. (Try Goggle for 'GUID algorithm' or 'Globally Unique ID' from the search engines)
RESOLVING CONFLICTS
We have a unique ID. The problem we have is with the names.... Sometime Mary Lou Smith is typed at the modality as Smith, Mary... Smith Mary L... Smith, Mary Lou... and sometimes Smith, Marry L.
Would it be possible to have Pacsone accept the study but put "ERR" or some other searchable string in front of the ID. Then, the records could be modified by the administrator at his convenience, and the study would still be available in the system.
Anyone else have a thought?
Jeff
Would it be possible to have Pacsone accept the study but put "ERR" or some other searchable string in front of the ID. Then, the records could be modified by the administrator at his convenience, and the study would still be available in the system.
Anyone else have a thought?
Jeff
Jeff Wolf
This sounds like the same issue we are having with our Konica CR. If it sends pacsone a different name it gets an error and resends the image until you cancel it. I realize this is a problem with people not putting in the same info, but people don't always give the same name when checking in, and trying to get staff to check and see what the name should be before entering it has been next to impossible.
I'm surprised. I never noticed PacsOne rejecting Studies that have an already existing Patient_ID but a different Patient_Name.
What seemed to happen is whatever the inititial Patient_Name was, is the one that will be returned in a search.
Does it sound possible ?
Tell me, otherwise I'd better check my records to make sure everything is there...
What seemed to happen is whatever the inititial Patient_Name was, is the one that will be returned in a search.
Does it sound possible ?
Tell me, otherwise I'd better check my records to make sure everything is there...
Let's clarify things first before we go any further:
The current PacsOne Server implementation rejects the newly received study, if the new study contains a patient ID that already exists in the database but with a different patient name.
Now there seems to be requests for two different features:
1. The patient ID is already unique, but sometimes the patient name gets entered differently, e.g., John Doe versus Doe John. In this case, the request is to allow the new study to be stored with the existing patient id, since it is the same patient, just with names entered differently.
This feature can be implemented easily, we just need to relax the patient name checking a little to recognize John Doe and Doe John as the same names.
2. The other case is when the patient ID is NOT truely unique, and the request is to store the new study under a temporary patient ID, and to be fixed manually by the administrator.
This feature requires much more work, and it'll not fix the source of the patient ID conflict problem, because neither the existing patient ID nor the "corrected" patient ID manually entered by the administrator is truely unique (not from the same single source like HIS/RIS)
Any other comments?
The current PacsOne Server implementation rejects the newly received study, if the new study contains a patient ID that already exists in the database but with a different patient name.
Now there seems to be requests for two different features:
1. The patient ID is already unique, but sometimes the patient name gets entered differently, e.g., John Doe versus Doe John. In this case, the request is to allow the new study to be stored with the existing patient id, since it is the same patient, just with names entered differently.
This feature can be implemented easily, we just need to relax the patient name checking a little to recognize John Doe and Doe John as the same names.
2. The other case is when the patient ID is NOT truely unique, and the request is to store the new study under a temporary patient ID, and to be fixed manually by the administrator.
This feature requires much more work, and it'll not fix the source of the patient ID conflict problem, because neither the existing patient ID nor the "corrected" patient ID manually entered by the administrator is truely unique (not from the same single source like HIS/RIS)
Any other comments?
AGFA have their way to solve it.... Maybe something alike?
I think this is a common problem in PACS. In our "big" AGFA Impax PACS it is solved so that images wich have bad information is stored in a separate area called "unverified" studies. Then the administrator can then do whatever with them afterwords.
(In an emergency anyone needing the images before they are corrected can retrieve them from the unverified area.)
Principally there is a problem as already stated, who can be sure about ID afterwords... But in daily life this is a recurrent problem.
We use Worklists and have a Broker in order to secure and verify every data before anything is permanentely stored in PACS, but still sometimes things does not match, and then this is rejected to this unverified area.
One problem is to secure the history, how to store the initial data and also the "corrected", and to create proper logging of this renaming. Maybe a legal and Dicom conflict... (Agfa is not changing ID in the original image-information, they have a separate database wich points to images. Changes and logging of changes is taken care of outside of Dicom. The image patient data is changed later on if/when exported to another Dicom node, like a CD for example.)
One maybe to simple approach would be to store both images, maybe with some added info in the corrected header to point out this renaming.
(The proper place to do renaming would probably be from the Quality Assurance station at the modality where the image was created, and if we would do so, we would get a new series of images, with unique series ID and so on. So if we want to do it properly, that process should be simulated. But then we would have to invent a new series ID...)
Still it would be good to have a "unverified" area instead of completely rejecting the study. But with this comes a lot of tools to change info, and questions of how to do it properly, so it is probably a fairly big project.
(In an emergency anyone needing the images before they are corrected can retrieve them from the unverified area.)
Principally there is a problem as already stated, who can be sure about ID afterwords... But in daily life this is a recurrent problem.
We use Worklists and have a Broker in order to secure and verify every data before anything is permanentely stored in PACS, but still sometimes things does not match, and then this is rejected to this unverified area.
One problem is to secure the history, how to store the initial data and also the "corrected", and to create proper logging of this renaming. Maybe a legal and Dicom conflict... (Agfa is not changing ID in the original image-information, they have a separate database wich points to images. Changes and logging of changes is taken care of outside of Dicom. The image patient data is changed later on if/when exported to another Dicom node, like a CD for example.)
One maybe to simple approach would be to store both images, maybe with some added info in the corrected header to point out this renaming.
(The proper place to do renaming would probably be from the Quality Assurance station at the modality where the image was created, and if we would do so, we would get a new series of images, with unique series ID and so on. So if we want to do it properly, that process should be simulated. But then we would have to invent a new series ID...)
Still it would be good to have a "unverified" area instead of completely rejecting the study. But with this comes a lot of tools to change info, and questions of how to do it properly, so it is probably a fairly big project.
DATA COERCION? TO HANDLE DUPLICATES?
I would like to see something like how the data coercion works.... If a duplicate ID exists, or duplicate name with different ID.. instead of rejecting the Data, Put a string ("UN" for Unverified?) in front of the ID and then perhaps even save it in a different data directory. It would then be up to the SA to correct the data at the source modality and resend the study to PACSONE and then delete the incorrect study.
I think that relaxing the Name checking is the wrong way to go... we just need a way to fix the mistypes
Jeff
I think that relaxing the Name checking is the wrong way to go... we just need a way to fix the mistypes
Jeff
Jeff Wolf
Yes, this was a bug in versions prior to version 2.1.4 where the first image of the new study was put under the existing patient with the identical patient ID.Antw1 wrote:So, is it possible that an earlier release of the PacsOne Server would allow images with different Patient_Name to be stored under a same Patient_ID ?
This seems to be what happens with our version of PacsOne Premium...
This bug has since been fixed in version 2.1.4.
Re: DATA COERCION? TO HANDLE DUPLICATES?
This seems reasonable and we'll need to come up with a way to make the "modified" patient ID unique so that the "modified" patient ID itself won't get duplicated again. Also we'll add a menu in the Tools page for the SA to find and delete all the problemed/duplicated patient IDs.JEFFWOLF wrote:I would like to see something like how the data coercion works.... If a duplicate ID exists, or duplicate name with different ID.. instead of rejecting the Data, Put a string ("UN" for Unverified?) in front of the ID and then perhaps even save it in a different data directory. It would then be up to the SA to correct the data at the source modality and resend the study to PACSONE and then delete the incorrect study.
I think that relaxing the Name checking is the wrong way to go... we just need a way to fix the mistypes
Jeff
How long do you think it will take to get all these changes implemented? Not trying to rush you, but my Physicians really want to get it up and running. Also, any idea what will happen when I import my current patient studies that already have duplicate names in efilm? Do I need to have them edit all the dicom headers before importing them? Thanks for all the help.
Here's the proposed solution for resolving the duplicate patient ID issue:
1. When a new image is received with a duplicate patient ID of an existing patient, a Warning response will be sent back to the sender of the image with the status code of "Warning: Data Element Coerced".
2. The patient ID of the newly received image will be modified by appending a "[xxDUP]" string to the end of the duplicate patient ID string, where "xx" is a random number from 0 to 99.
3. A "Check for Duplicate Patient ID" menu will be added to the Tools page, where the Administrator can view a list of patients with duplicate patient IDs (all patient IDs ending with "[xxDUP]")
4. At this point, the Administrator can decide to do one of the following:
4.1 Nothing. That will leave the new image with the "[xxDUP]" patient ID suffix.
4.2 Fix the duplicate patient ID by assigning a correct patient ID from the source, delete the current duplicate, then re-transmit the corrected image to PacsOne.
If you're performing an Import and encounter the same duplicate patient ID problem, then the imported image will have the same "[xxDUP]" string appended to the end of the duplicate patient ID. You'll need to assign a correct patient ID by modifying the Dicom header of the original image, delete the imported image with the "[xxDUP]" suffix, then Import the modified original image with the correct patient ID again.
1. When a new image is received with a duplicate patient ID of an existing patient, a Warning response will be sent back to the sender of the image with the status code of "Warning: Data Element Coerced".
2. The patient ID of the newly received image will be modified by appending a "[xxDUP]" string to the end of the duplicate patient ID string, where "xx" is a random number from 0 to 99.
3. A "Check for Duplicate Patient ID" menu will be added to the Tools page, where the Administrator can view a list of patients with duplicate patient IDs (all patient IDs ending with "[xxDUP]")
4. At this point, the Administrator can decide to do one of the following:
4.1 Nothing. That will leave the new image with the "[xxDUP]" patient ID suffix.
4.2 Fix the duplicate patient ID by assigning a correct patient ID from the source, delete the current duplicate, then re-transmit the corrected image to PacsOne.
If you're performing an Import and encounter the same duplicate patient ID problem, then the imported image will have the same "[xxDUP]" string appended to the end of the duplicate patient ID. You'll need to assign a correct patient ID by modifying the Dicom header of the original image, delete the imported image with the "[xxDUP]" suffix, then Import the modified original image with the correct patient ID again.
The only problem I see with this is that some modalities such as the Konica will automatically resend the image on an error. Leaving us with the same issue we have now. We may not get the duplicate images, but it will stop all other images from transfering until it is corrected on the Konica. I'm not sure how my other modalities will react to the error, but I will contact Konica again to see if they can stop it from retransmitting on a
"Warning: Data Element Coerced" error. What should it do on a typical modality when it gets that error? Does it just mark it as failed?
"Warning: Data Element Coerced" error. What should it do on a typical modality when it gets that error? Does it just mark it as failed?
The "Warning: Data Element Coerced" status is a Warning, not an error. But still Konica may choose to retransmit the same image over and over when it receives such a Warning response. To me, this behavior is not acceptible even in the case of errors because this will simply stop itself from doing anything else but to keep transmitting the same image forever.dustinn3 wrote:The only problem I see with this is that some modalities such as the Konica will automatically resend the image on an error. Leaving us with the same issue we have now. We may not get the duplicate images, but it will stop all other images from transfering until it is corrected on the Konica. I'm not sure how my other modalities will react to the error, but I will contact Konica again to see if they can stop it from retransmitting on a
"Warning: Data Element Coerced" error. What should it do on a typical modality when it gets that error? Does it just mark it as failed?