With some PACS contacts running to an end in the next few years, what should we build into the next generation of Imaging system specifications to accommodate the brave new world?
When you take into account the NHS Long Term Plan and the plans on Recovery and Renewal post-COVID, I would suggest something that facilitates AI, either from the vendorâs own partnerships or from another vendor that you could add in at a later date. Making AI available within your renewed contract, may be the most cost-effective option, I would have thought.
I would also consider VNA capability if you donât already have it, being able to bring together the entire health record in one place, especially with the push on genomics within the above mentioned plans, makes logical sense.
I would ensure that, even with compression, you have enough storage as, if you are going to store genomics, the file sizes are huge compared to standard DICOM files sizes that a PACS is used to.
Mike, Thank you, all good points. Anyone have examples of AI specifications that would add value to a future contract?
Do you have advice regarding Image Sharing? Is there a need to incorporate Cross Enterprise Document Sharing XDS functionality within future specifications? Or has the proliferation of PACS Consortia reduced the demand within regions?
Regards Tim
Hi Tim
I know youâre very well aware of some these points already!
I am strongly of the opinion that a modular architecture and compliance with open standards are the most important principles when considering new imaging systems.
Basic security considerations that are worth thinking about are:
- self updating
- mandating encrypted network traffic (including internally) - i.e. no use of FTP, SSL securing all web interfaces
- mandated single sign on (via LDAP / Active Directory).
I appreciate that these security requirements could be seen as idealistic for some sites but, if mandated national guidelines, they will become cheap.
One other thing that might be worth thinking about is considering a deprecation plan at the point of procurement. How hard will a migration be? Is there anything we can consider at the outset to reduce vendor lock-in?
It may be AI today but we do not know at this point what will be required in the next 10 years. It will be a lot harder to adapt to unknown future requirements if relying on proprietary systems that do not adhere to industry standards.
Let me know if you want to discuss in further detail.
Best wishes
Mark
I would ask for the elusive Zero downtime upgrades.
1 Like
Zero downtime upgrades are probably only likely with cloud PACS solutions donât you think?
Like I said. We have a cloud Pacs but it is still elusive, despite it being in the OBS.
Cloud is only where the databases/servers live. It wouldnât guarantee âzero downtime upgradesâ.
To have a zero downtime ugrade, PACSs need a âtemporary running/continuation serviceâ while the upgrade is taking place PLUS a scheme to align the new upgraded live service with whatever happened on the temporary space during the upgrade time.
All possible from cloud or local installation.
1 Like
If web based, single sign on using OAuth (whatever the ID provider application)
We are currently trying to develop a next generation PACS for the SouthWest of London. We are adopting a cloud first approach for PACS, RIS and any third party apps/services. The idea is that the user will be able to login from home to the PACS system without a Trust VPN or VDI, with a single sign-on, and the system will be fully integrated into all necessary systems including VR. Change Healthcare are our chosen PACS vendor, and are fully supporting this goal. We are going live next year.
The other goal is to rap the functionality of the systems around specific use-cases and care pathways in order to optimise the workflows of the Radiologists, Radiographers and Clerical Staff. This is a wholistic approach that will attempt to mange the radiology informatics environment both upstream and downstream, as well as within the Radiology Departments themselves. So technologies like AI are taken as a possibility, but not an end in themselves. The idea is to find ways of managing capacity and demand, but also taking the wellbeing of the staff as a priority.
Anyway, thatâs the hope. Fingers crossed.
Simon Rickaby
Digital Transformation Lead
SWL PACS Programme
1 Like
Traditionally the system specification (Output Based Specification) with the supplier was crucial for the procurement stage. Thereafter the specification provided the âexpectation frameworkâ for services. The OBS was one component of a healthy supplier customer relationship, as well as a back stop for troubled times.
Perhaps listing some of the 1,500+ criteria found in some OBS (to which the suppliers often respond âyes, product meets this criterionâ) remains necessary. But is there a better way?
⢠What phrases in previous contracts added most value?
⢠What omissions were later realised through contract life?
⢠What proactive steps should we take now to avoid lock-in? (of special concern for large scale EPR).
⢠If zero downtime is required what technology should we consider supporting, in doing so are there compromises that offset this desire?
⢠If we need to specify image sharing with x, y, z then how is this specified? Proprietary standards vs Open standards?
If you want the next contract to add tangible clinical and system management value, then refreshing the criteria for the next clinical system needs dedicated time well before procurement meetings populate your diary.
In the past, I we assumed that technology would solve our problems, and we just had to describe what we needed in the OBS. But now we want transformation, but arenât exactly sure what will deliver that transformation in a useful way.
We stated that the SWL project was first and foremost transformational, and used the word transformation in virtually every procurement meeting we had with the suppliers. The only company that really got this was Change, the other suppliers just sounded like they were echoing what we wanted without any real commitment.
The other thing we did was insist on an off-prem cloud-first solution that would align with open standards. This was clearly very challenging for most of the suppliers, but it has encouraged Change to push the technology envelope; also it has forced the local IT Departments in the Sector to move forward and consolidate in relation to networking and user authentication.
The whole approach has been a lot more dynamic than simply stating an OBS, Change are openly exited about what can be achieved over the next ten years. (I say âsimplyâ, but obviously the development of the OBS and contract was far from simple).
Hi Tim, I was just about to post a similar set of questions.
Especially your last paragraph hits the nail on the head if you want to run a cost and resource efficient service.
We specified a managed equipment service and and during procurement potential provides would simply state âYESâ to the specifications listed. In reality, after signing the contract, a lot of these turn out to be âYES ⌠but only ifâŚâ.
We found that although a penalty system was specified, our supplier would simply tag a difficult ticket as a âproblem recordâ after which it disappeared from radar. Two years with a voice recognition system that crashes, disappears, corrupts profiles is a long time. Cost to the NHS is massive due to disruption/lost reports/fault searching. The cost to the supplier⌠1 penalty charge.
That is not even a peanut for the supplier and hardly an incentive to drive for a resolution.
I would love to see suggestions for a better contractual mechanism to get a supplier commitment to address a problem.
I have worked as a contractor for many Trusts when they run an OBS procurement and a lot of questions are asked and boxes ticked and then not delivered. The whole concept of a VNA was brought up 10-15 years ago and magically every suppler had one. When you try and add other âologies to it you find for some reason they canât store or display the images or videos.
I still have not seen any true VNAs that can do this.
As we progress with all the latest exciting uses of the images we have lots of different silos holding patient data in a proprietary format that cannot be accessed easily. When it comes to data migration that brings another host of issues and most Trusts hide the problems hoping it will go away.
My suggestion is that you map out what you want a system to provide and contract against that. Use the words like â all conformanceâs stated is assumed purchased and providedâ.
The NHS keeps buying devices that do not conform to any conformance like HL7 & DICOM to start with.
I see this all the time in the Trusts I currently work in.
It would be a great topic to hold a meeting to discuss this topic with a new set of ideas. I have many OBSâs I have used before but I think we need a new idea as we progress.
2 Likes
I just wanted to share a few thoughts since standards are mentioned. I am the current chair of IHE UK.
The IHE RAD profiles are, in the main, DICOM and HL7, with a few rules about how to use the DICOM and HL7 (which,by the way, line up with the RCR guidance).
The extenstion of this is XDS-I; a way to publish the existance of studies to a shared Registry (this extends the messaging world of DICOM and HL7 to the âpublish subscribeâ model used in most web applications).
Then, if DICOM Web Services are also used according to the IHE profiles, this lifts a DICOM/HL7 world fully into a web based paradigm.
If a VNA is to be used as a âsharing hubâ I would encourage the use of IHE open standards for integration, rather than relying on proprietary APIs that come with the VNA. Despite the VAN name, a proprietary API is another kind of vendor lock in (no matter how the data in the VNA is persisted).
Note, using a VNA as a sharing hub rovides an index in the VNA, a home for the Regisrty - again, better to instatiate this as an IHE Registry than a proprietary index in the VNA.
The additional benefit of the IHE layer, is it gives a mechanism to catch some meta data that can assist in the non-radiology/non/cardiology imaging (where nice concepts like Study and Accession Number are harder to pin down). IHE/XDS-I privides a separation of meta-data that helps organise less organised imaging paradigms.
1 Like
Totally agree. But we PACS managers tend to get only involved after a purchase is made as that is often the point where they figure out the new device needs to connect up to to some other system, via the network and that has an OS that needs patching regularly. After the signature is placed, you are not in the best position to start sentences with âbut what about âŚâ
1 Like
Chris.
I could not agree more, VNA was floated as the ultimate solution. Admittedly 15 years on great progress has been made and I do think there are solutions out there getting (VERY) close to that panacea we are looking for.
Robinâs comment on open standards is key, but also open APIs.
2 pennies worth on the 'ologies. Areas such as pathology must be considered as part of this, they do not necessarily comply with the expected DICOM standards yet, and we are looking at ridiculous file sizes, but solutions allowing for flexibility to accommodate this in future should be considered for a central VNA for all things image related, (Letâs not even go down the Ophthalmology or VLI rabbit hole!)
I think IHE again solves a lot of these issues but I think the NHS has lost its focus on using this. They have been more focused on other interoperability. I think itâs time to restart the IHE courses and means to be able to put an IHE level into the builds.
Hi Robin.
I can not speak for all but think that a lot of us will struggle to translate the above into clear, binding statements in our OBS. We had statements with regards to IHE standards in our OBS in 2013:
(6) The supplier must provide a conformance table for all of its products in relation to the Integrated
Health Enterprise (IHE-UK) standard profiles and the date that these were tested and proven. Any
development paths to HIPAA compliance must be stated.
Obviously, no supplier responded to that in the hope we would not insist on it. Reading your post, I think it needs to be expressed as part of specific interfaces or system parts to which a YES/NO answer is unambiguous. I will definitely put more effort in that section this time around.
1 Like
Yes - I fear youâre right. Partly it is because supplying truly open interfaces leaves suppliers âopenâ to supporting external services pushing data in and pulling data out (and all the work that goes into ensuring privacy/consent and of course systems performance). But for me, these are to be captured in the contract.
I think this is helpful - if you can connect the need for the standards to Use Cases, it helps draw a boundary around the required open standards functionality. Like, âI want to do xyz in an open standards way to acheive abc.â
For example;
<<The supplier system must be able to support distribution of radiology images using DICOM Web Services (controlled through IHE Meta-Data managed in an XDS-I environment) to support image information cinsumers external to the supplied soution. >> you could then list specific known systems, like âRegional Shared Care Record Systemâ, assuming your Regional Shared Care system can consume IHE XDS-I DICOM Web Services 
- of course you should check this first. And you may well come across shared record systems that have their own âblob serverâ and their own proprietary APIs for unstructured data like images.
Linking the open standards requirements to Use Cases is a good way forward, because then you have to inspect the reality of who/what will use the open interfaces. It is a continual struggle to keep interfaces open, and the knee-jerk reaction of suppliers is to âuse my index/registry and my APIsâ. This is not so Machiavellian as it seems - suppliers have to limit their liability for data curation and systems performance. So, to help suppliers draw a boundary (and limit their liabiity in a contract) it is helpful to focus on Use Cases.
1 Like