UK Imaging Informatics Group
PACS as part of patient's Electronic ... PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards >
Message/Author
 Link to this message Neelam Dugar  posted on Monday, November 17, 2008 - 03:35 pm Edit Post Delete Post Print Post
PACS(whether from LSP or not) is part of a patient's electronic health record. It stores and displays images (radiology and cardiology currently). It also displays reports associated with the images, by calling the report repository (RIS in the UK).
1. However, PACS is only an element of the patient's electronic health record. For efficient and improved patient management and from a patient safety perspective it is important that PACS integrates with other clinical applications. Integration between Clinical Applications was the ethos of the NPFIT Programme.
2. API Interfaces (often called a desk-top integration) are required between PACS and
a. RIS, Cardiology Information Systems, NBSS for reporting processes
b. results reporting systems (whether part of an EPR or stand-alone or part of ordercomms), for clinicians to "read" and "file" away reports (as part of NPSA Safe Practice Notice 16)
c. other products that also need to have API intefaces are Orthopaedic templating, thin client 3D applications
API intefaces are vital for integration of NHS patients care record and also to allow Trusts to buy the best clinicall applications (rather then based on a vendor based monopoly)
3. It is important that Connecting for Health actually helps in "connecting" between different elements of a patient clinical record (based on clinical needs).
4. It is important that commercial interests from LSPs dont result in a fragmented patient record within the NHS (particularly when so much of public money is at stake), by their refusal to work with non-LSP products to develop standard API interfaces.

This in my view is vital for the strategic direction of NHS IT. I would like this to be raised at the PACS Stakeholder Board and hence, would like to invite comments from the Group.
 Link to this message Dr John N H Brunt  posted on Monday, November 17, 2008 - 04:55 pm Edit Post Delete Post Print Post
May I suggest that in considering this, we should have, in this thread, a copy of the OBS (i.e. NHS NPfIT Integrated Care Records Service Part II - LSP SERVICES, Output Based Specification), as background reading / reference material.

Of the many sections in the 608-page OBS, clearly Section 115 “PACS” (pages 253-340) is most relevant for us.

However, other informative sections include the initial one, “Visioning the LSP Services” (pages 4-20).

Reading “Visioning the LSP Services”, and the initial pages of other sections, helps understanding of the extent of integration and connectivity that the LSP Services were to provide. The bidding LSPs were also to have indicated what integration they would be providing by the milestone date of January 2010 (now just 14 months away).

I would encourage others to read this background material.

John.
 Link to this message Neelam Dugar  posted on Tuesday, November 18, 2008 - 11:52 am Edit Post Delete Post Print Post
Thanks John.

"The LSP must provide solutions that allow users to define the data items that are collected and must also allow users to
flexibly define how data in the system is presented (including clinical notes, flowsheets, worklists, tables, graphs, pictures, diagrams, and images)."

"In addition, today’s systems generally fail to support the care delivery at the point of care and lack close integration with the business and clinical processes. Bridging the gap will be done by chosen LSPs working in partnership with the Authority."

"The LSP must provide solutions that allow users to define the data items that are collected and must also allow users to
flexibly define how data in the system is presented (including clinical notes, flowsheets, worklists, tables, graphs, pictures, diagrams, and images)."

Above are some extracts from the OBS vision. The whole concept of NPFIT was based on an integrated patient record through LSP systems or LSPs providing solutions for integration between disparate Clinical IT systems. However, there has been a stark difference between what was the vision and what is indeed reality.

The reality is that LSPs are commercial organizations, and their share-holders are their prime responsibilty (and quite rightly so). Contracts are shrouded under commercial secrecy so as end-users in the NHS we do not know exactly what they are required to deliver.

Let us see what is LSPs best interests from a commercial angle:
1. get the cheapest solution possible that fits with the minimum clinical requirements
2. Be relunctant to integrate their systems with other suppliers systems(so as to force Trusts into buying their product).
If we were in their shoes, we would do the same. It is naive to think otherwise (as they are not a charity but a business!)

However, NHS and NHS patients (public) are the customers. The best interests of the patients lie in
1. Integrated systems which improve efficiency and improve patient safety.
2. Best of breed clinical systems which provide enhanced clinical functionality and improve the patient care.

However, the stark national reality is NHS is having to make a choice between
1. Integrated systems only if you buy an LSP product (which maybe more expensive and less VFM and lack desired clinical functionality---and therfore may end up with products that clinicians refuse to use in their day to day practice
2. buy best of breed clinical applications and result in a fragmented patient record (by refusal of LSPs to integrate).

The public and NHS patients are losing out both ways unless there is a national view taken about need for systems integration, and need for NHS to buy best of breed clinical systems.

Although there was no problem with the NPFIT vision there is a definite stark difference between vision and LSP commercial interests today. NHS needs good strong leadership in CFH to be able to see the public/patient perspective to implement strategy which actually delivers
1. best of breed clinical systems
2. ensures that integration between clinical systems is at the heart of Clinical IT Strategy.
This will prevent fragmentation of the patients record for commercial interests.
 Link to this message Neelam Dugar  posted on Monday, November 24, 2008 - 09:32 am Edit Post Delete Post Print Post
Dear All,

I have requested Nicola Strickland to raise the following issues at the PACS stakeholder Board.
1. PACS is part of a Clinical Health Record.
2. Standard API Integration with other Clincal systems like
a. Reporting Systems (RIS, CIS,NBSS etc)
b. Results reporting systems (stand-alone, part of OCM, or part of EPR)
c. specialist imaging systems (3D, CT colonoscopy, PET-CT etc)
is vital.
3. If API integration is ESSENTIAL for
a. increased efficiency in NHS (otherwise huge costs to public)
b. improved clinical management
c. improved patient safety.

If integration is not allowed by LSPs, this will result in huge long terms costs to NHS and the public purse. It will also result in a fragmented/dis-integrated health record delivered under the LSP programme.

I have also requested John Somers and Laurence Sutton as Clinical CFH Leads to raise it at all national meetings that they represnt Clinical Users in the NHS.

Could I please request all Group Users to please raise it all Meetings/forums at Trust/SHA/national levels that you individually attend. This is in national interests and in the interests of our NHS patients, and the public purse.

Thanks,

Neelam
 Link to this message Nick Samuel  posted on Monday, November 24, 2008 - 11:52 am Edit Post Delete Post Print Post
Dear All,

The term 'API' is open to various interpretations. Generally it is used for >A< front-end product that interfaces with a range of applications.

Is the propasal to be put to the PACS stakeholder board that there be an application API that pulls together the information from: (RIS, CIS,NBSS etc); (stand-alone, part of OCM, or part of EPR); (3D, CT colonoscopy, PET-CT etc) etc.?

Nick
 Link to this message Neelam Dugar  posted on Monday, November 24, 2008 - 12:37 pm Edit Post Delete Post Print Post
Nick,

From a user perspective we require the ability for one clinical application (PACS/RIS/OCM etc etc) to open another clinical application for the same patient or episode. This may be automatic or by manual intervention.

Currently we have an API interface between RIS and PACS. The episode is synchronised through accession number. This is called "desk-top integration" by us. This is automated for reporting through RIS worklists. We have icons on both RIS (called show images) and PACS (called RIS enquiry) for manual synchronization, when required. This is extremely vital for efficiency in NHS.

Our McKesson RIS (non-LSP) also synchronizes with various other applications for opening request cards, opening the digital dictation application from other vendors/applications...

3D software vendor like Visage, Voxar and Tera-recon provide such API intefaces with multiple PACS including the likes of Agfa.

We require a similar synchronization with other clinical applications with the LSP PACS. Even to an non-technical person, it is clear this is technically obviously possible, but there are LSP commercials in England that are preventing such integration (as there is an incentive to force NHS into buying more expensive products from them.

The proposal to be put to PACS Stakeholder Board is to get LSP products to interface with other Clinical Applications based on clinical Requirements.
 Link to this message Martin Peacock  posted on Monday, November 24, 2008 - 12:59 pm Edit Post Delete Post Print Post
The 'desktop integration' or 'api integration' described is well covered by the HL7 CCOW standard. It covers the synchronisation of user context (important for auditing) and patient context (crucial for safety) specifically but can be extended to include, for example, episode context. It is well thought out, and encompasses use cases like where a 'slave' application cannot change context without first committing (or losing) some data. Some, but far too few vendors admit to supporting CCOW.
 Link to this message Neelam Dugar  posted on Monday, November 24, 2008 - 01:58 pm Edit Post Delete Post Print Post
Thanks Martin. You are right, what is actually required is for ALL Clincal applications to support CCOW (from HL7) and it actually fulfils our needs. However, as I have alluded to before there is dis-incentive to adopt CCOW standards (or for that matter any standards) in the Commercial Sector.

If NHS made it mandatory for all software suppliers to adopt CCOW for integration
1. It would improve efficiency
2. improve patient safety
3. improve patient management
However, without integration between Clinical Applications (whether by use of standards or by proprietary interfaces) we are going to have a totally fragmented electronic patient record in the NHS due to lack of leadership, and for commercial gains.
 Link to this message Neelam Dugar  posted on Friday, November 28, 2008 - 02:26 pm Edit Post Delete Post Print Post
There have been some developments supported by CFH regarding integration between clinical applications with PACS. We are likely to see emergence of a catalogue item on the LSP catalogue for integrating clinical applications to PACS (which now rightly is considered a part of the patient's health record). I do think this is an enormous step in the right direction by CFH.

As I have alluded to in my previous postings, it is vital for PACS to be considered to be a part of the Clinical Health Record. It is important that PACS is integrated with various other relevant Clinical Applications
a. Image reporting Systems: RIS, Cardiology Information Systems, NBSS etc
b. Results reporting systems (whether part of an EPR or stand-alone or part of ordercomms), for clinicians to "read" and "file" away reports (as part of NPSA Safe Practice Notice 16)
c. Other imaging products that also need to have API interfaces are Orthopaedic templating, thin client 3D applications etc.

As Martin has quite rightly pointed out, CCOW is the international HL7 standard which relates to this type of API/Desk-top integration.

"CCOW or Clinical Context Object Workgroup is an HL7 standard protocol designed to enable disparate applications to synchronize in real-time, and at the user-interface level. It is vendor independent and allows applications to present information at the desktop and/or portal level in a unified way.
CCOW is the primary standard protocol in healthcare to facilitate a process called "Context Management." Context Management is the process of using particular "subjects" of interest (e.g., user, patient, clinical encounter, charge item, etc.) to 'virtually' link disparate applications so that the end-user sees them operate in a unified, cohesive way.

Context Management can be utilized for both CCOW and non-CCOW compliant applications. The CCOW standard exists to facilitate a more robust, and near "plug-and-play" interoperability across disparate applications."

From a national strategic point of view, it is important that such Healthcare IT standards are adopted by NHS (so as to provide a cost effective electronic health record for our public and patients through vendor neutral "plug-and-play" integration).
 Link to this message Andrea Procter  posted on Friday, November 28, 2008 - 02:45 pm Edit Post Delete Post Print Post
"There have been some developments supported by CFH regarding integration between clinical applications with PACS. We are likely to see emergence of a catalogue item on the LSP catalogue for integrating clinical applications to PACS (which now rightly is considered a part of the patient's health record). I do think this is an enormous step in the right direction by CFH."

Neelam, any idea when this is likely to actually happen?

Andrea
 Link to this message Neelam Dugar  posted on Friday, November 28, 2008 - 02:56 pm Edit Post Delete Post Print Post
Andrea,

I do hope this will be soon. I am acutely aware that integration with other clinical applications is required by all Trusts in the NHS, to prevent a dis-integrated and fragmented NHS patient record. I would reccomend, you discuss this with your CFH representative in your patch. You if do not get a helpful answer, please contact me off board. (Although, I am sure you will be helped by CFH.)
 Link to this message Neelam Dugar  posted on Monday, December 01, 2008 - 10:56 am Edit Post Delete Post Print Post
I am pleased to hear that PACS is considered to be a part of the clinical electronic health record by CFH and PACS Stakeholder Board, as this is important from a clinical efficiency and patient safety point of view.

1. When CRS becomes available it will be integrated with PACS. This is indeed re-assuring.
2. For PACS to be integrated with with "Interval" NHS Clinical Systems (until CRS becomes available), discussions will need to be had at local Trust level.
3. Trusts need to be responsible for integration requirements between LSP PACS and other Clinical Systems.

Regarding Integration Methodology, yes indeed there are multiple ways of integration. A large number of proprietary methods exist. Having been involved in some projects, each proprietary integration between 2 clinical applications costs approx £40K (just a rough figure from the top of my head!!). Prior to the advent of Dicom Standard of integration, each CT scanner/CR/MRI (from different vendors) to be linked at your PACS may have cost this much, using proprietary methods of integration. However, because we now globally use Dicom the costs for such integrations from multiple vendors are significantly lower.

XDS-I---is the international integration standard between PACS systems of different Trusts from different vendors. NHS may choose to use this methodology for long-term cost benefits, or may choose to adopt more costly proprietary solutions from suppliers
CCOW--is an HL7 international standard for front end-integration between multiple clinical applications (irrespective of vendors). NHS may choose to adopt this standard or could choose proprietary integration which will be very costly to NHS in the long term.

Obviously from a commercial perspective, proprietary integration is better as it generates more income for the suppliers. Hence, there is been resistance to development of standards by suppliers.

PACS is required to front-end integrate with the following Clinical Systems
1. Reporting Systems (RIS, CIS, NBSS etc)
2. Results Reporting Systems (stand-alone/part of EPR/Part of ordercomms)
3. Add-on imaging systems (3D, PET-CT fusion, CT colon, Cardiac CT, orthopaedic templating etc.
This front end integration could be perfored using CCOW if your PACS and your Clinical Application supplier supported CCOW. all these applications need to reside on your PC or PACS workstations.

I would reccomend that at each Trust level you start asking for CCOW from the suppliers, and let us see where it gets.
 Link to this message Neelam Dugar  posted on Tuesday, December 02, 2008 - 12:07 pm Edit Post Delete Post Print Post
Some easy to understand information about CCOW.
http://www.cryptlib.orion.co.nz/
CCOW implementation could be part of your Single Sign on projects that are currently running in a large number of NHS organizations.
 
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Password:
Options: Automatically activate URLs in message
Action: