Do accession numbers need to be unique to support integrated multivendor RIS and PACS systems as envisaged in the national programme?
Our LSP have put a proposal to NPfIT that they agree a standard format for accession number and allocate unique ranges to different LSPs, along similar lines to IP addresses. This will have implications for data migration and support for existing systems.
I've discussed this our solution architect and various other people but nobody seems entirely clear what the impact of non unique accession numbers would be. Clearly if they are not unique there is the potential for unrelated studies to share the same accession number and for systems to somehow relate them. Whether this has any practical implication depends on how systems have been designed to interpret the accession number, and what if any additional fields must match for them to be considered to be related.
Can anyone advise on this? Is there any part of IHE (or how IHE compliant systems deal with accession numbers) that specifically requires them to be unique?
I believe it is essential that Accession Numbers are unique since they identify a specific episode of care. Whilst it is possible to concatenate say the patient NHS Number to the accession number, this still allows for the possibility of the same patient having an accession in 2 different institutions and just happen to get the same accession number and so falsely indicating the same episode of care.
This is particularly important with RIS reports being sent to the data spine. While it is possible to make the accession unique based on patient, date and time it seems sensible to ensure uniqueness by simply have a facility code as part of the accession number. This allows each facility to control its own accession number formats but ensures uniqueness in the large environment.
posted on Tuesday, December 14, 2004 - 10:12 pm
Each Trust has a three letter code eg I think ours is RPX. You often see these in NHS e-mail address books. Maybe this could be used as a prefix or suffix to the local Accession Number within NPfIT ?
This issue needs investigation as many RIS PACs links rely on the accession number for report distribution. It also adds to the question regarding central storage of images. Are these images and reports to become part of a true single database or separate partitions of data for each site/trust/LSP, with a single access method, pulling data with identical accession numbers (but different NHS numbers) from different partitions. The consequences of data passing into an incorrect database and matching an existing accession number would give cause for concern. Accession number management is part of administration for every PACs ,but at present I can only imagine that every PACs in UK has very similar ranges of accession numbers.
posted on Wednesday, December 15, 2004 - 12:37 pm
There is clarification regarding Accession no. on Appendix A of the IHE technical framework on page 157. In simplistic terms it corresponds to order filler no. assigned by a RIS. In terms of whether the spine will be able to appropriately query and retrieve images and reports from multiple databases (multiple RIS/PACS archives)using IHE. This is dealt with in the "Access to Radiology Information" integaration profile of IHE. However for that we need RISs and PACS that support this profile the following actors within RIS need to support this profile 1.Report Reader 2. Report Repository 3. Enterprise Report Repository 4. external Report repository The following actors within PACS need to support this profile 1. Image Manager 2. Image Archive 3. Image Display
This response is courtesy of Peter Bates, Data Quality and Standards Manager, Calderdale and Hudds NHS Trust:
I can only make an educated guess, but here goes:
I don't know how many imaging requests are made each year up and down the country, and how many years worth of images would be retained on PACS, but suffice it to say a lot. Therefore a nationally unique accession number would be unwieldy and unworkable.
Given that as things stand I expect there to be locally configured RISs but county-wide or cluster-wide PACSs, the logical solution would be:
Each local RIS generates an accession number which is unique locally. It should then be associated with the organisation code of the acquiring Trust to ensure it remains unique within a wider PACS environment.
e.g. an accession number for C&H (Cald and Hudds) would appear in PACS as RWY00/G123456
posted on Thursday, December 16, 2004 - 02:08 pm
I asked my colleague John Paganini, Director for Product Management - Healthcare Systems about his views on this subject as he is a long-time member of the Radiology Society of North America/Integrating the Healthcare Enterprise (IHE) Radiology Planning Committee.
ĎHere is a summary of the unique accession number from an IHE perspective.
The Accession number is the primary unique identifier between the order and the procedure. The obvious dangers of duplicate accession numbers are lack of synchronization in both reporting results and procedure billing.
Theoretically in IHE, one could actually get away without an accession number by using the Filler Order Number and the Procedure ID. This works if you link images and reports to Procedure IDs, procedures to the orders and then link these to the visit.
When looking at the various information systems on the market today, the accession number is in fact a very common data element.
And in the case of the UK National Programme, I would suggest a scheme to maintain accession numbers across the enterprise and even across vendor boundaries. Without accession number uniqueness, the potential for issues arise if these systems have to search across enterprises and different vendor information systems for procedure and reporting data.í
within our RIS (CRIS system) every procedure/exam is allocated a unique accession number when the exam is entered into the RIS. Within our software for all communications in / out of the system we can make use of a suffix and/or prefix facility. It seems to make sense to me for all RIS systems to put an organisation code prefix in front of there existing format accession number whenever communicating with a PACS or 'spine'. With this method even older RIS systems without a prefix ability can be catered for by using an integration engine and configuring the engine to add a prefix. I think MITRA(or equivalent PACS broker) could even add the prefix. All images then sent to the spine will be unique.
Please post any comments on the draft proposal below.
posted on Monday, January 24, 2005 - 04:11 pm
I feel I must object to the first sentence within scope; "The DICOM standar d makes provision for the use of Accession Numbers and AETs, which are defi ned solely for purposes of use within (and between) Radiology Information S ystems (RIS) and Picture Archiving and Communication Systems (PACS)."
AETs (if not Accession Numbers) are used across DICOM and not just within R IS & PACS systems as indicated in this sentence. I know that most Radiothe rapy Treatment Planning Systems (TPS) use DICOM servers/clients with associ ated AETs some of which will inevitably require to communicate with a PACS. I likewise know that most TPS vendors set-up their systems with standard AETs. It may only be a small problem to NPfIT but I can foresee the possib ility of multiple TPS with the same AET connecting to the same PACS from di fferent sites, and NPfIT have appeared to have completely overlooked Radiot herapy again.
Ian Beange Principal Medical Physicist (Radiotherapy Physics) Department of Medical Physics & BioEngineering Raigmore Hospital, Inverness, IV2 3UJ
From what I have read, I feel a universally unique identifier will be impossible to apply across the country. Accession numbers are more unique and useful when associated with an institution or group of institutions, hence the hospital-prefix number. A unique address for each exam for the whole country would have to be allocated from a central RIS which does not exist and highly unlikely to do so for a long time. (An allocation of a range of accession numbers to each LSP as mentioned by Rhidian has been proposed) An IP address type system would allow both exam origin and unique identifier to exist together and further validation would occur when checking other fields, i.e., patients name and NHS number. Laurence
Looking at the overall picture, I presume attendance no. to the diabetic clinic will be a unique no. throughout the country. I presume that will apply to visits to chest/fracture/ENT clinics etc. etc. Are they any different to a visit to a radiology department which then produces an accession no.?
Iíve sought permission to update members on national proposals on Accession numbers, as there was some confusion at the SIG meeting last Wednesday over this.
Members may remember the initial proposal (posted above) was a requirement to implement nationally unique accession numbers in PACS. This was subsequently revised following input from the BIR IHE-UK committee, and distributed to key stakeholders for comment (attached below). Iím told initial responses have been collated and no significant further changes are anticipated before the document is formally signed off.
The key points are:
1. Accession number only has to be unique within the context of the order filler. In radiology this will typically be a department RIS or a SHA RIS instance. Outside radiology (e.g. in endoscopy) accession numbers may be allocated by separate dedicated information systems.
2. Accession number is intended to be a human readable equivalent of the IHE Filler Order Number. Traditionally, in paper request based radiology clinical workflow, radiology department staff use the accession number to locate grouped work items (requested procedures) on the information system. Although this is often done by barcode reading, there is still a requirement to be able to enter a relatively 'human readable' number when a barcode reader does not work, or is not present.
3. In a completely paperless worklist driven environment the requirement for a 'human readable' accession number is largely removed. However, it is likely that many trusts will still need to retain a paper driven system to facilitate clinical workflow in some areas.
4. Although in DICOM an accession number can be up to 16 characters long, in practice one would want it to be as short as practicable, bearing in mind it is intended to be a human readable field.
5. As highlighted in the document, as the accession number is not guaranteed to be unique outside the RIS, other identifiers should be used during retrieval of images on PACS to ensure the images correspond to the requested procedures in question.
6. Adoption of the revised national/IHE data model for accession number will simplify data migration and integration with existing RIS systems.
Dave Harvey posted in a separate thread >> Generating a Study UID is a basic and mandatory feature of DICOM modality worklist, so ANY RIS/PACS which acts as a modality worklist server MUST supply a study UID (and all that I know of do comply). http://www.pacsgroup.org.uk/cgi-bin/forum/show.cgi?195/10260
Daveís response touches on a problem the national design steering group have been asked to address, namely how do we ensure a unique reference between a RIS study, the corresponding study on PACS, and any reference to the study on any other information system e.g. the EPR. Study UID is the logical link as it is guaranteed to be unique, and is incorporated in the WADO standard which will enable direct web access to a DICOM study from an EPR. For Study UID to form this link however, it must be generated within the order filler (generally the RIS) with a modality worklist (MWL) providing the link to PACS, and/or communicated from PACS to RIS and stored as part of the modality performed procedure step. Unfortunately neither of these are universal at present. In addition, as Dave has replied off board, although it is a requirement in DICOM and IHE that the order filler generates a study UID for the MWL, some vendors to not store this study UID in the RIS or PACS to provide this link.
Many suppliers have traditionally used accession number to provide the link between RIS and PACS. This may serve the purpose at a local level, but falls short when addressing the national problem as they are not guaranteed to be unique. Whilst LSPs may now be designing their systems to generate unique accession numbers within their cluster, this does not address the problem of cross cluster data integrity and the problems of importing and data migration of accession numbers from existing systems.
I agree wholeheartedly with everything you've stated.
The Study UID should be generated by the order filler, and communicated to the PACS via MWL. The loop should be closed then with the PPS. Someday we'll get there, but vendors really to need adhere to standards, and buy into the concept that their system isn't the center of the world. IHE helps, but adoption is not as rapid as we would like.
The legacy of PACS and RIS is that of departmental systems. Most RIS do not create the Study UID (or even store a Study UID if informed of it), and many PACS don't even use the Study UID as they should - instead choosing to use their own internal study identifier. The question remains as to how an EMR/EHR/EPR application is to obtain the Study UID in order to make WADO requests.
Accession Number, as you state, is often used to bridge this gap. That often works in the department, but not necessarily in cross department or cross enterprise situations. Obviously this is because Accession Number is not a unique field, and is not even a Type 1 tag in DICOM.
How we've solved this in our system (an enterprise archive) is through an organizational hierarchy. Imagine, if you will, a distributed tree structure of all of the facilities (and possibly specific departments as well) that span a deployment.
Each node (hospital, clinic, department, etc) on this tree is allowed to maintain its own rules about how to deal with Accession Numbers. Some examples may be; accession number is unique to a study, accession number encompasses multiple studies, generate a unique accession number if one does not exist, etc. We'll call this node that defines these accession number rules a Study Management Organization (STMO). These STMOs can also define a Patient ID Type (or site code), so that the patient identifier (MRN) that they use can be different than the patient identifier that a different node uses when dealing with the same patient. The system keeps one patient record, with multiple ids.
When a request for data (DICOM Query, Retrieve, WADO, etc., along with non-DICOM requests such as HL7 or user queries) arrives at the system, the system looks at who is requesting the data and gives it back to them in the format that they know. This includes their Accession Number and patient identifier. This is possible because the system knows where the data came from (what node on the organization tree), and what rules were applied or need to be applied.
If cross organizational access is desired (the enterprise or national EHR/EPR view, so to speak), all data may be accessed (assuming the appropriate authentication/authorization). The accession numbers and patient identifiers are returned in the format of the requestor if possible, otherwise in their original formats.
When I say access to, or request for data, I mean access in the form of DICOM, HL7, or a human user. All of these interfaces, devices, users may be defined within the context of the organizational tree. This is not enough though, as mentioned, because there is a need for enterprise or national access. In this case; sometimes defining the device, system, or user at a higher level in the organizational tree does not work out. For those cases it is possible to enable inbound interfaces (DICOM called AE Titles, HL7 listeners, etc.) which override the organizational context of the caller, instead using a defined overriding organizational context. Therefore a departmental calling AE Title within one hospital may gain access to data stored from multiple hospitals or at a national level.
Of course, the necessary infrastructure must be in place to do something like this, and all imaging data (radiology, cardiology, radiation oncology, etc.) must flow through, be stored, or indexed within the system.
I don't know if this helps you at all. If nothing else, it gives some insight into how someone else (TeraMedica - obviously a vendor) has approached the problem. I've left a lot out, but hopefully you get the basic idea.