Next Generation PACS

Sorry (I know it’s a bit long winded), but to say that another way …

I genuinly think suppliers want to do a good job. If a requirement says just “give me such and such open standards interface.”, It’s too open ended - you have to help them draw a boundary around he functionality by saying “what for.”

Defining a system specification that enables accountability is really challenging. If you use precise specifications, you need confidence that what you are asking for will stand the test of time. If you are too vague, then suppliers may have too much latitude in what they provide.

An idea may be to include process maps to illustrate how you expect the system to fit into existing/future systems?

Has anyone included a distinct section regarding interoperability and associated standards in the scoring matrix used to assess systems, to help supplier focus? If so, did it work?

I’d be interested in such a matrix. But it is odd that as a “buyer” of a service or a system you have so little leverage if it doesn’t match up to what is delivered.

In 2013 our OBS listed a table of 4 SLA’s with various fix times. However, the suppliers use a “5th SLA” called a problem record. Problem records have no fix time.
It is appreciated that system problems that require development cannot be fixed within an SLA of 4 weeks. The problem is that they rarely get fixed. E.g. out RIS PACS interface crashes regularly requiring a system reboot. The problem was 1st reporting in May 2021. The problem is apparently fixed in the next release. The next release was announced in 2017…so a holding your breath contest is not wise.

The situation was the same in the CSC days. I suspect what is behind this is that product development and world wide roll out is expensive but it is a bit of a dinosaur attitude.

I’d would like to include some kind of construction that would limit the number of problem records allowed. Not sure if anyone has a similar situation and has found a better way.

1 Like

Thanks Robin, both answers are appreciated :slight_smile:

Customer satisfaction is key in my view. An OBS provides limited insight into these areas. Site visits are useful but are often restricted to a site selected by the vendor and may not be representative.

Independent reports such as KLAS can be helpful here. I’m not aware of any procurement exercise however that has managed to factor in ‘independent’ customer satisfaction survey metrics. I tried!

1-6 Unsatisfied 7 Acceptable 8 Satisfied 9 Very Satisfied

Customer Satisfaction Drivers

  1. Culture
  • keeps all promises
  • product works as promoted
  • proactive service
  1. Loyalty
  • part of long term plans
  • would you buy again
  • likely to recommend
  • overall satisfaction
  1. Operations
  • quality of implementation
  • quality of training
  • ease of use
  1. Product
  • supports integration goals
  • product has required functionality
  • timely delivery of new technology
  1. Relationship
  • quality of support
  • vendor executive involvement
  1. Value
  • avoids charging for every little thing
  • drives tangible outcomes
  • moneys worth
1 Like

Frank, that’s a sorry state of affairs! Presumably the interface performed well for at least a little while post go-live. My question then is: what changed? If the vendor is dodging this fix, I am of the opinion they should be named and shamed.

The biggest issue we’ve had in the last 2 years is an unstable reporting solution. Due to CRIS/Dragon11 not being compatible with Win10 and our roll back from CRIS/Dragon13 after 6 weeks in a previous year, Wellbeing advised to go to CRIS/Dragon15. Since that move, we’ve been plagued with CRIS not loading VR, CRIS disappearing, CRIS freezing, cursor jumping to random places in a report, CRIS not closing, profile corruption, microphone switching off, microphone not switching on and more…

Wellbeing has shown to be incapable of solving these issues effectively and every patch introduced more problems.

On top of that, for more than a year, our PACS doesn’t always launch (Synapse issue), or has a “windows magnification” issue. Each time the system has to rebooted. The solution is in the next release of PACS. The next release of PACS was announced in 2016. It is now 2022.

Over time, our RIS/PACS interface becomes slower and slower up to the point where it takes 10 to 12 seconds to bring up a study for reporting. That problem was reported 5 years ago and is still with us today.

A statement I’ve made many times before which I believe was as valid in the CSC days as it is now

  1. if the user produces a problem, we train the user
  2. if the configuration produces a problem, the supplier tweaks the solution
  3. if the solution has a problem, in the majority of cases, the user needs to find a work around

I would like to address point 3.

Not sure if that can be done by contract or smarter selection of the supplier or both. For me, Rhydian just hit the nail on the head in his previous post and I will try to use this. However, higher up in the Trust, manager have a more 3 word Boris like attitude as in “Get procurement done” and might not be all that interested in the effort the PACS and RIS team need to put in to keep a system running efficiently over the next 10 years.

1 Like

Frank, feel free to reach out to me directly.
I have been using other systems which seem to be stable, including a roaming VR license from a new solution.
Happy to share experiences.

Hi Frank, In regards to VR and CRIS, Wellbeing now offer a new product from Scribetech called Augnito, which works well with the newer versions of CRIS 2.12.4/5 etc.
We run Windows 10 on our reporting stations and have not encountered issues with CRIS.
Unfortunately I don’t have experience with Synapse so I can’t offer anything there.

Thanks Mike. We have been advised to wait for CRIS 2.12.07. The current Augnito version cannot learn new words which was not accepted by our radiologists as practical. It is going to be released at the end of this month.

Hi Dennis, we’re in a MES contract. We can’t use a different product.
But the point I was trying to make in the group chat is that we need better tools to hold suppliers to account when they don’t deliver a working product.

1 Like

How about adding something like this to the contract-

Significant Concern Remedy

Where a persistent and significant issue that impacts a broad cohort of users is evident, the customer may record the issue as a “significant concern”.

  • A significant concern must be reviewed by relevant parties within one month.
  • A mutually agreed plan of action to resolve the concern must be evident within two months.
  • The concern must be fully resolved within 12 months from the date of the issue being raised.

If unresolved after the 12 month period a financial penalty of “x” percent of the annual contract value will be made available for the customer to procure additional services from the supplier.

Where the issue remains unresolved after the initial 12 months, for each additional 3-month period an additional “x” percent of the annual contract value will be made available to the customer for additional services.

This may need further elaboration as to what constitutes “broad cohort”, “persistent” or “significant” etc.
By linking the “motivator” to providing additional services from the supplier, rather than financial loss of revenue for the supplier, the risk of increased contract cost may be reduced.

1 Like

Thanks Tim, that is valuable advice.