|
|
|
|
  Next PACS & Teleradiology Group Meeting
Friday 19th March 2010
British Institute of Radiology, London
|
| Message/Author |
|
|
|
|
PACS Replacement—a Supplier’s Perspective---Matthew Condron(McKesson). Another excellent presentation.
We should consider PACS Replacement as an alternative to simply upgrading at the end of contract with your supplier as an option. Do not let your PACS vendor scare you away from considering replacement.
Take home messages from Matthew
1. Choice of supplier---make sure they had experience with successful data migration.
2. PACS has moved in leaps and bounds since the 1st Generation PACS. Integrated modules for mammography reporting, cardiology display, PET-CT fusion, Integrated RIS/VR etc are now common place these days
3. Make sure project management is directly with your PACS supplier (rather than 3rd party)!!!!
4. Remote support and monitoring, with a dedicated support team with FREE phone call access to support team.
5. Constant software updates (every 3 months) available and communicated.
6. Timely resolution to all escalations
7. Direct access to developers (I personally think this is hugely important). Software vendors need to understand that there needs to be direct dialogue between the user community and the person who will do the software development to ensure that the requirements are understood before a huge amount of development work is done only to find out that it does not meet the needs of the users. (My view----Nowadays many suppliers employ a large number of salesmen who do not let you have access to a developer directly and your message gets distorted before it reaches the developer)
8. Real time support. The support representative owns the support call till resolution. This is really important to the user community.
 PACS Replacement—a Supplier’s Perspective---Matthew Condron (McKesson)
McKesson.pdf (1775.0 k) |
|
|
|
|
|
Our Group (SIG of RCR) has been championing the need for a standards based inter-operability for image and report sharing. Members of this Group had an input the College position statement regarding National Strategy for Image and Report Sharing http://www.pacsgroup.org.uk/forum/messages/2/40624.html
This document caused some stir in CFH circles. CFH charged BT to see if Spine could be made XDS compatible. I do think this is a significant positive step towards a potential vendor neutral standards based multi-vendor competitive environment for PACS. However, retrofiting XDS/XDS-I standard on existing Spine would require some bespoke development by BT. However, delegates were concerned that ---would this bespoke BT development lead to a "proprietary standard from BT". This retrofiting also comes at a cost. Is this good value for money or would this be called "throwing good money after bad money". Before more millions are spent this issue needs to be debated with supplier community (particularly with non-LSP suppliers who belong to small and medium enterprises and continue to supply good software to NHS). SME do need standards to remain in the market and would support this initiative.
Overall despite my reservations, I do think overall the direction is correct. Debate of
XDS retrofitted to Spine as discussed here
vs
XDS EPR within Trusts with an XCA based document and Image sharing in NHS (independent of Spine)
needs to be debated openly and independently--to ensure VFM is delivered this time.
|
|
|
|
|
PACS Replacement---Data Migration Issues—Shannon Werb (Acuo Technologies)
And if Dr. Lacey had not managed to convince you that PACS Data migration is not scary, Shannon will definately convince you. Companies like Acuo, Krucom and I am sure there are others, who specialise in Data Migration. They are subcontracted by many of the PACS vendors. "Data migration is an art" .
Some take home messages that I felt were in the talk
1. Cost of data migration is per study (rather than per terabyte!!)
2. Value Added Data---Reports, Notes and Annotations are usually not stored in standardized format. If we could adopt robust standards for these, data migration would probably be easier. I think people need to ensure that we do not store these non-standard data objects when you consider PACS Replacements. Insist on standards.
3. Shannon confirms that technically there should be no issue of migrating data from CDS.PACS Replacement---Data Migration Issues—Shannon Werb (Acuo Technologies)
Acuo.pdf (419.0 k) |
|
|
|
|
|
Teaching Files and Training---Radiologist perspective---Dr. Nicola Strickland (NHS)
A very practical presentation from a real working radiologist, identifying the needs for us to improve our ability to teach and train the doctors of the future (who will in turn look after us when we need NHS care).
The Digital Library used by jobbing radiologists require integration as the key useful feature.
1. Tightly integrated to the PACS application (I personally think that PACS workstation is an outdated term with many vendors moving to a software only solution).
2. Integration with Speech Recognition (that is used for reporting by the radiologist)
3. Available on same PC hardware/workstation as used for regular reporting on RIS and PACS
4. Same log-in process with SSO
5. Ability to export overlay files (I think this is related to use of DICOM standards and avoid use of private tags on PACS)
6. Ability to manipulate images in the library --add annotations etc and ability to save these in the library.
7. Ability to copy and paste text data from report into the library
8. Good database structure for classification of items stored with ability to do keyword search. (CFH has removed the keyword search feature for teaching files with Impax 6.2 deployments in NHS)
9. anonymize but keep audit trail so that more information can be added later.
10. ability to have personal collections which cannot be deleted without permission--i.e privilege settings (CFH has removed this privacy feature on teaching files within Impax 6.2 deployments in the NHS)
11. Access to internet is vital for literature search and references (this is becoming a less of an issue with Vendors who are delivering the Next Generation PACS--in my view)
Most of us do share Nicola's vision and drive for what is required by radiologists who sit in front of PACS and report real patients images and wish to improve the quality of the next generation of doctors who will serve the NHS. I agree that a NHS wide buy-in is required. Hopefully the pilot run by McKesson and Imperial College will prove to the NHS clinical community of the huge benefits in teaching training and revalidation.
Teaching Files and Training---Radiologist perspective---Dr. Nicola Strickland (NHS)
nicola.pdf (380.3 k) |
|
|
|
|
|
Teaching Files and Training---Surgeon/Physician perspective—Dr. Linda de Cossart (NHS)
Teaching and training is not just limited to radiologists and their trainees. The Clinical community has seen a huge change for the better with national PACS deployments. A good teaching and training software will enhance and support the junior doctors in acquiring the ability to make good judgements. Judgement making is the key in clinical practical practice and this is what we need to teach doctors of the future.Teaching Files and Training---Surgeon/Physician perspective—Dr. Linda de Cossart (NHS)
Linda.pdf (7847.2 k) |
|
|
|
|
|
Results Acknowledgement and Alerts—Dr. Nick Hollings (NHS)
As a Group we have inspired and debated the concept of results acknowledgement systems. Nick brings what has been discussed and debated to ground reality of deployment.
NPSA SPN 16 is the key document for this concept.
RADIOLOGY DEPARTMENT RESPONSIBILITIES as per SPN16 :
1. Define timeframes for reporting (my view is that all Trusts need to have some local benchmarks for this--for example all inpatients reported within 24 hours, all Outpatient exams within 3 working days etc)
2. Ensure critical findings are emphasised and degree of action is clear. Nick quite rightly points out that there is a lack of agreement on what is considered to be critical by radiologists and clinical community as a whole. Nick's Trust has come to a decision to label a finding as critical --"if a finding could result in a patient coming to serious harm within 4 hours." These would result in an alert being sent to the clinical team--e.g. a telephone call to the referring team.
3. Define safety net procedures--copy reports to GP, copy report to MDT etc.
CLINICAL DEPARTMENTAL RESPONSIBILITIES as per SPN 16:
1. All reports are viewed and acted upon. Ensuring that this does happen is the ultimate responsibility of the "Requesting Responsible Consultant"---This is where the RAS systems come into play. RAS allow for the requesting teams to have an electronic process for reading acknowledging reports (rather than a paper pile of reports)
2. Ensure they develop safety net processes for reading and acknowledging reports:
a. particularly with recent loss of clinical team structures within NHS
b. to deal with locums, shift working, generic clinics, generic doctors, lack of handover processes, visiting consultants, annual leave sick leave etc etc.
3. There needs to be local benchmarks which define timeframes for reading and acknowledging reports--for example 24hours for inpatient reports. 3working days for outpatient reports.
Let us try and understand why RAS has not been the norm in the NHS.
A. Lack of IT systems to adequately support slick and efficient clinical workflows with a single mouse click for acknowledging reports.
Nick talks about the "inbox concept" for reading and acknowledging reports on IMS. It is similar to a worklist/filter concept I have been trying to get ICE Ordercomms to implement. I have been requesting ICE our suppliers to provide our clinical users to be provided with a results acknowledgment worklist/filter of all reports based on
1. Requesting responsible consultant
2. Requesting doctor
3. Current Responsible Consultant
4. Current Location
as a minimum. Meditech (used at Countess of Chester) also uses a filter/worklist approach I think. Whatever the methodology, it should try and achieve the same goal--try and get consultants acknowledge all reports.
B. Lack of context linking with images: Currently when the requesting community reviews a patients exams they review the images and reports on PACS as they are "together". Unless context linking between RAS and PACS is provided I do not think any Trust will be able to deliver 100% of their secondary care reports acknowledged on the RAS. This requires RAS and PACS vendors to work together for developing an API (alternatively use a middle broker system like Sentillion, Carefx or use standards like CCOW). We are struggling locally to get ICE to provide us with a technical specification for having a context synchronization with Impax 6.x. Margaret, describes that at the Countess they have context linking with Meditech RAS (part of their PAS/EPR)
C. RAS should be able to filter out the "autoreports". Otherwise this creates unnecessary burden to the clinical community.
D. Needs a culture change: Once we have IT systems to support results acknowledgement process as described above with worklist/filter/inbox concept, alongwith a context linking with image displays, filter out the autoreports, we also need a culture change amongst the clinical community. I do believe that once we have quick and slick IT process to deal with results acknowledgement, getting a buy-in from clinical community will be possible. However, in my view without effective IT systems, we cannot "dump" this system on the requesting community.
E. One of the good things that I have seen in the ICE system as the ICE mail within the system which allows for messages related to a report to be communicated from one consultant to another, consultant to secretary (i.e. get me the clinical notes etc), juniors to consultant etc. I do think this is a good added value feature of an RAS.
I do not believe that there is a robust RAS system within the NHS today. All products lack some functionality. However, it is important that we clinical users specify to the suppliers what our requirements are. Good relationships with suppliers who are willing to listen are key to good clinical system deployment in the NHS.
Excellent presentation from Nick.
|
|
|
|
|
Can Standalone IT systems survive in EPR world—Dave Harvey (IHE-UK)
Thank you Dave confirming that EPR/EHR/EMR/PMR is definitely possible using multiple departmental systems.
The following conclusions sum up Dave's presentation
1. We will always need “specialist” IT support system
RIS, LIS, CIS etc.
2. We’ve all seen what happens if you trust “Big companies” to “do it all Lorenzo, Millennium etc.
3. But Stand-alone specialist systems are no excuse for independent “silos” of clinical data
4. We can do it with PACS – why not the rest of the EPR?
The RIS is dead….Long-live the RIS!
I agree with Dave that worldwide adoption of DICOM made PACS possible (an integrated radiology record). Worldwide adoption of XDS will make EPR possible. Wales pilot for XDS-I will prove the concept. Well done Wales. Well done to GE for winning the contracts, and for continuing to prove their credibility as a pioneering company in the world of PACS and EPR of the future.
|
|
|
|
|
Can Standalone Ordercomms Survive an EPR world ---Dominic Dunn (Surquest—formerly Anglia ICE)
Many of us are aware of ICE as a supplier of Ordercomms. Thank you Dominic for confirming that as suppliers you do feel integration with other IT systems is vital.
1. By use of HCIF (Healthcare Interoperability framework), ICE ordercomms can be launched from other applications like GP systems. (ND--comment---I agree this is a crucial feature for getting GPs to use electronic requesting. I am sure this could be applied to other departmental systems in secondary care as well.)
2. Every Ordercomms also needs to get patient demographic and ADT info from PAS/EPRs using HL7 messages. Hence, HL7 interoperability is a must.
3. Dominic agrees that Ordercomms also need to be able to do context based views of multiple applications on a single screen (ND comment---we call this DTI or desk-top integration. DTI with RIS and PACS should be possible with Ordercomms).
4. Achieving integration with other IT systems does require adherence to standards---IHE, Web service views, Sql views
Dominic accepts that as a company, they are not there as yet. However, as a company they are moving in the right direction---OpenNet, US connectathon, iframes etc
A very powerful statement from Dominic at the end--he would like to change the question--Can EPR survive in a fully integrated "Best of Breed" world?
I personally do believe that no EPR could survive if the best of breed application vendors adopted robust integration standards to deliver a EPR that combined the output from the best of breed specialist systems. Adoption of robust standards is key to this concept. |
|
|
|
|
Can Standalone Ordercomms Survive an EPR world—Terry Fossey (IMS)
Excellent presentation from Terry. IMS provides Ordercommms and also a modular EPR, but can integrate with other EPRs as well (similar to Sunquest and others). Some take home messages:
1. A standalone Ordercomms MUST integrate with PAS (through HL7 messages) and departmental information systems (RIS, LIS, Endoscopy system, cardiology, ophthalmology systems etc through HL7 messages) to survive.
2. EPR is an electronic patient record which maybe single or multivendor, modular or monolithic. Hence, standalone Ordercomms is possible in a modular, multivendor EPR.
3. Slide 9 identifies why it is important that Ordercomms synchronizes status updates with information systems, to allow the requesting doctors to take action as required.
4. On slides 10-15 Terry describes how Ordercomms could move from a simple ordercomms with a simple clinical decision support to a more intelligent complex Clinical Decision Support tool. Currently most places have a simple decsion support tool with warnings about a repeat exam. However, for a complex Clinical Decision Support tool there needs to be a robust EPR in place. |
|
|
|
|
Ordercomms – The Must Haves—Margaret Cosens (NHS)
Margaret has a wealth of knowledge and experience of implementing Ordercomms in NHS. There are a lot of pearls of wisdom in Margaret's presentation. One aspect of Margaret stands out above everything else is her ability to push a software system to its maximum. Even with a Ordercomms system with blue screen type looks--look at the functionality that Margaret it able to get it to deliver. Afterall, it is not just about looks but about functionality and ability to deliver the workflows required by the clinical community.
Margaret discusses the following aspects of setting up an Ordercomms systems
1. Protocols/forms/Questions for requesting--which maybe exam specific
2. Access Controls for requesting--what an individual can request
3. Location--accurate record of patient location at request (with ability to know current patient location)
4. Acknowledging reports--the concept of team responsibilty
5. Importance of status updates and synchronization--?national standards
6. statuses that require to be acknowledged.
Margaret is always a step ahead
1. She discusses the issue of rolling out Ordercomms to GP and discusses the issues to matching patient with PAS/MPI
2. She discusses how she has been involved with electronic referrals and reports to and from GP surgeries using Medisec.
3. She highlights that Ordercomms should not just be limited to radiology and pathology. We need to look at the wider use. |
|
|
| |
|
|
