Does anyone have a definitive answer as to how should we store local patient IDs and NHS numbers within DICOM?
It seems like a pretty obvious thing to define, but I can't find it anywhere. Am I missing something, or is there at least some sort of consensus?
The NPfIT document NPFIT-PAC-DES-0412 "PACS Programme - NHS Number Approach for PACS and RIS - Compliance to DSCN 32/2008" says:
1) PACS must be capable of storing the NHS Number on patient records 2) PACS must allow users to find a patient record using the NHS number as part of the search criteria in conjunction with other demographic information, this should include the patients forename, surname, DoB, gender and the Local patient ID prefixed with the organisation’s ODS/NACS code. 3) PACS must include the NHS Number in any Patient Identifiable Data sent electronically. By default, NHS Numbers should be transferred electronically as 10 numeric characters (i.e. without spaces) 4) Where communication occurs across system boundaries, solutions will be required to ensure that the NHS Number, where available, is propagated. All current and future sharing mechanisms will be required to address this requirement.
If requirement 4 (above) is to be met, then surely this means that the NHS number has got to be stored in a DEFINED way, so that all systems know where to find it in data that is transferred between systems!
I can't find this definition anywhere - I'm drowing in IHE documents, as well as CfH. I can't find anything useful on the new "Health and Social Care Information Centre" website. (Although I like the fact that there info system is called TRUD!). There is an awful lot of trees out there, but I can see no wood...
DICOM itself has quite a few options. "Patient ID" (0010,0020) and the "Other Patient IDs Sequence" (0010,1002) both have the associated "Issuer of PatientID Macro", which has sufficient room to store detailed descriptors of the Patient ID. The "Other ID's" tag (0010,1000) is a bit more ambiguous however - it is simply a list of ID's with no descriptors.
What would seem most sensible to me would be to place the "most important" ID in (0010,0020), and make sure that the descriptors in the "Issuer of Patient ID macro" are appropriately populated, and put any other IDs into (0010,1002), again with the "Issuer of Patient ID macro" populated. Under this scenario, I'd avoid using (0010,1000) altogether because of the ambiguity. Which ID is "most important" would depend on system scope - for transfers within the hospital it might be the local hospital number, for between hospitals it should be the NHS number.
Moving back to the real world... Anyone know what standards (if any) other people are working with/towards?
I've not seen any evidence of the use of the other IDs sequence (0010,1002), but I have seen numbers that *could* be NHS numbers in (0010,0020) and (0010,1000). I say *could* be, because all I have to go on is that the number is 10 digits long, and the 10th digit follows the check digit rules (so there is a 1 in 10 chance that it is accidentally NHS valid...)
I've also occasionally seen a local hospital number simply prefixed with the hospital ODS code.
Also - silly question time... but what is the equivalent of the ODS code for a NHS number?
I'll continue to look for these answer myself, but if anyone has any insight to this, I'd be extremely grateful.
From a practical point of view NHS does need 2 numbers 1. Hospital ID--PAS No--This allows linking of information held in multiple departmental systems within a hospital to the same patient 2. NHS No--This allows linking or sharing of information between GP surgeries & NHS hospitals.
Our PACS & RIS systems these days store both IDs. a. PAS no b. NHS no.
We expect our XDS Registry & Repository compliant VNA do be able to store Source Patient ID as PAS no Patient ID as NHS no. as metadata enclosed RIS is the main metadata source
Thanks for your replies - but unfortunately the question still remains unanswered. IHE national extensions for UK only add a requirement to support Welsh. Although XDS is the ultimate aim for data sharing, the current everyday reality is DICOM networking or DICOM CD's. The main system used in England for inter-hospital DICOM sharing is IEP - but as far as I can tell (from looking at a random set of data) there no consistent use of local OBS codes or NHS number there at all. I have no idea what they do in Scotland, NI or Wales where IEP isn't so prevalent. I'm completely astounded that after the Millions/Billions spent on CfH/NPfIT that there is no clear specification for this. It is all very well mandating that NHS number should be used and stored, but with no specification of where and how it should be stored within the data, interoperability reverts back to every interface having to be customised to the site.
Sorry - I meant to add... With DICOM you can't just add a new field - you are stuck with what the DICOM standard specifies. DICOM doesn't have a field "Source Patient ID" as specified within the XDS requirements specification. The major issue is really the descriptors that describe the various patient IDs are mostly not used. I think it is unsafe to assume that a 10 digit number that you happen to find in a patient ID field is actually the NHS number. Is there a code that specifies that a given ID is indeed the NHS number?
If these DICOM fields were appropriately populated, stored, transmitted and read it wouldn't actually matter if the IDs were stored in PatientID or OtherPatientIDs! (Within the organisation putting the local hospital number within the PatientID might makes sense. For export, putting the NHS number into PatientID is probably the way to go.)
IF this was centrally defined somewhere, then gradually suppliers would start to implement it, and it could always be mandated for new systems...
I didn't mean this to become a huge monologue, but I've found out a bit more. The key fundamental point to all this is that the scope of the Patient ID needs to be defined and stated. There is little point in putting the NHS number into the Patient ID field if there is nothing to definitively state that it is the NHS number. This is critically important!
From DICOM 3.3, table C.2-2 (0010,0022) “Type of patient ID” is actually a DICOM enumerated type – which must be one of “TEXT”,”RFID” or “BARCODE”. So it is pretty useless – in most cases this will be set to “TEXT”. (So suggested use of this field in my earlier post was just plain wrong - sorry!).
(0010,0020) PatientID and (0010,0021) Issuer of Patient ID must be defined together. (0010,0024) Issuer of Patient ID Qualfiers sequence is optional…. Includes • (0040,0032) Universal entity ID • (0040,0033) Universal entity ID Type (0010,1000) Other Patient IDs. Should NOT be used (0010,1002) Other Patient IDs sequence should be used – and again (0010,0020) PatientID and (0010,0021) Issuer of Patient ID must be defined together
In the examples they provide, they have values for (0010,0021) Issue of Patient ID like “Site A” or “Site B”.
Proposal for the way forward
(0010,0020) PatientID - set to the relevant ID – either the local ID or NHS No depending on scope (0010,0021) Issuer of Patient ID - set to the local OBS code or “NHS”. (0010,0024) Issuer of Patient ID Qualfiers sequence (this is optional) (0040,0032) Universal entity ID Set to “2.16.840.1.1138220.127.116.11.1” for NHS number, or if to the local hospital UID – if they have one and it is known! (0040,0033) Universal entity ID Type – “ISO” (0010,1000) – Other Patient IDs – remove if present. Possibly parse it into other fields… but only if the scope of the Patient IDs known. (0010,1002) - Other Patient IDs Sequence - • (0010,0020) PatientID - set to the relevant ID – either the local ID or NHS No depending on scope • (0010,0021) Issuer of Patient ID - set to the local OBS code or “NHS”. • (0010,0024) Issuer of Patient ID Qualfiers sequence (this is optional) • • (0040,0032) Universal entity ID Set to “2.16.840.1.113818.104.22.168.1” for NHS number, or if to the local hospital UID – if they have one and it is known! • • (0040,0033) Universal entity ID Type – “ISO”
Accession Number There is also some stuff about the Accession Number in MIMA – but I think we have to be pragmatic. I don’t think we will, in general, be able to fill in all of the details in the “Issuer of Accession Number Sequence” (0008,0051), as MIMA requires as I suspect that in most cases the UID of the hospitals are not known. We could, however, fill in the (0040,0031) “Local Namespace Entity ID” part of it with the local hospital OBS code. This is valid DICOM, just doesn’t fully comply with the proposed IHE profile.
posted on Wednesday, April 17, 2013 - 02:13 pm
does IHE Patient Identifier Cross-Referencing (PIX) help (although I suspect this may be HL7 based rather than DICOM)?
posted on Wednesday, April 17, 2013 - 03:46 pm
There is perhaps a much easier solution - drop local ID and only use NHS no's
Nick, You are right. If we were to have IHE standards environment , we would need a PIX manager at a national level--"spine level" feeding all the XDS registries (within a Trust or group of Trusts). The PIX manager would also enable sharing across the border with Scotland too. The diagrammatic representation on the wiki page is very useful.
Locally, we are trying to get agreement regarding IDs 1. XDS source Rogan 2. XDS Registry & Repository-Acuo 3. XDS consumer-Fujifilm This is going to be real test bed for vendor neutral interoperability . I do hope standards triumph....
I discussion with Acuo today, is that Patient ID on the XDS metadata will need to be the same as source Patient ID. I.e we will have to use the PAS no. In the XDS metadata. I have asked whether we can use Reference ID new metadata field to include NHS no. In this way, we can retain the NHS no. Within a standards environment. Maintaining data in a standards way makes customer more powerful--VNA vendor cannot dictate the display/clinical portal vendor.
The 2 questions outstanding for us 1. NHS number--where do we include this in the XDS metadata set? Could we include this in Reference IDs? 2. Intended Recipient--We feel that this should be part of the standard XDS metadata set (and not limited to XDR)