My trust is in the advanced stages of an EPR procurement and the project director is currently drafting the contract with the preferred supplier. I joined the trust after the project had gone to tender and have had no direct input into the process.
As far as radiology is concerned the contract schedules specify the EPR system must interface with the current RIS and there are general requirements for enabling remote requesting of examinations and viewing radiology history/appointments and reports through the EPR system’s generic user interface.
I am concerned that this high level specification does not give sufficient detail on the level of integration between the EPR and our current RIS system to allow us to determine how it will work in practice. I am told this exercise will be undertaken after the contract has been signed when the links with the third party systems will be established. Any further requirements that may require specific development time will be dealt with under change control.
I would be grateful for your advice on whether this level of specification is standard/acceptable within the contract or whether I should push for a more detailed specification of the level of integration at this stage. Does anyone have a EPR/3rd party RIS integration specification they would be prepared to share with me? Thank you.
You are quite right to be concerned. To be honest, I'm not sure how a preferred supplier has been chosen without the level of detail you referred to. Responsibilities for integration have to be clear and up front.
In my experience change control = "it's your problem, but if you provide us with a full spec to fix it, we'll charge you to develop it...."
> Why not specify what you want in detail BEFORE a contract is signed. I have seen many people promise lots when going for the sale but offer little after the contract is signed. I work for a RIS supplier (It my even be our RIS product that you are detailing) Two good suppliers/systems should have no triuble in interfacing the systems for Order comms and Results although some RIS system may not be able to do this especially older ones.
company: Cypher IT Ltd position: managing director
As much detail as feasible should go in before the contract is signed. Feasiblity is also affected by how well the Trust knows what it wants, which isn't always easy. And of course more detail means a longer/more costly procurement period.
However one of the main points of using preferred supplier status is that you only go to that level of detail with one supplier, instead of doing three times the amount of work if you ran it to the wire with three suppliers.
I would suggest you do push, and the above may help justify. Also if you identify limitations that the EPR supplier probably hasn't thought of, then this may help sell the more detailed process to your colleagues.
For example most Trusts still have a mixed economy, at least to some degree. So if viewing Rad history doesn't indicate if it's digital or not, will the user search PACS or for a lost packet? It's only one field, but a big impact on end-users. It's core functionality to the Trust; a chargable customisation to the EPR supplier.
I'm sure there will be better examples specific to your situation which will help explain your very valid concerns.
Dear Rhidian, This sounds a very dangerous way of doing things. We are in the process of doing the same and I would suggest an output based specification as would be written for any PACS system. You get the functionality and the risk of delivering it (& working with other companies) is transferred to the supplier (you hope). Links to PMI to keep RIS & PMI in synch, updating reference files for doctors & sources, order/comms for request in/report out (unauthorised or authorised) to EPR or intranet, dictation/speech recognition systems, radiology GP messaging, quick addressing systems, PACS to EPR links are just a few areas that spring to mind. All this functionality and tailoring is costly for the supplier so I would suggest that it needs to be agreed before contract signature along with penalties for non-compliance. I presume that the Trust lead on this project understands all the intricacies of your service and all the IHE data flows. Another solution is does your EPR supplier have a good RIS so that your RIS is merely a dedicated module in the EPR? Then you have to build all the RIS-PACS links e.g. DICOM worklists, etc, etc? Simon Daniell
Our Trust had a fairly loose EPR specification for a contract which was signed in 1998 and has been problematic ever since. There is no doubt that the devil is in the detail. The problem is that you don't really know what you want with an EPR until you have an EPR! PS We still don't have a functioning EPR - need I say more?
Thanks everyone. I see you share my concerns. The OBS for the EPR was done before I joined the trust and is only to interface the EPR system (preferred supplier System C) with our existing RIS (Torex Radcentre - formerly Amersham). System C have their own integrated RIS but this was not considered as an option within the business case. We do not have PACS.
As preferred supplier, I understand System C have met with Torex/Amersham to establish a cost for interfacing the system to provide core EPR functionality. On several occasions I have raised the question of what level of integration is being proposed, in order to help me understand how the systems will work together in practice. The answer has been that we are not at that stage yet, and it is only recently I have discovered that this we be established after the contract is signed. I am told by our project director the preferred EPR supplier cannot be expected to go into this level of investment in detail without the reassurance of a signed contract.
Like Simon I am surprised this level of detail was not included in the OBS or detailed statement of need (DSON). I am not clear myself at present which fields need to be shared, which ones need to synchronised and how quickly this synchronisation should take place to enable the systems to work together seamlessly (hence my request for a specification from the group). My feeling is that we should ask the preferred supplier to either provide this level of detail so we can analyse it to see if it will meet our requirements, or alternatively have a very tight OBS in the contract detailing how we would like various tasks to be completed using the systems.
I suspect it will have to go ahead in its current form and we will run into the problems you are anticipating. My consolation is that I will have greater control over the separate PACS project (in theory) and I will be able to work on a EPR/RIS/PACS integration specification that will address any problems that occur.
Presenter: Rex Osborn (AHRA August 2004 Boston, MA)
Session Title: Embedding Clinical Connectivity in Today’s PACS IDN (Integrated Delivery Network) - A Practical Approach
Session Category: PACS
Session Description: Integration is the key to success in making PACS a worthy investment. This session will demonstrate – in practical application – the Integrated Healthcare Enterprise (IHE) and what each segment of integration means in the day-to day operations of the Radiology department.
When considering how to apply IHE principles to an IDN enterprise, a fundamental question emerges for IT personnel, Radiology Administrators and Chief Radiologists alike: “How do we initiate the embedding of PACS to ensure that both clinical and diagnostic images are available when and where we will need them?”
In this session, we will take an interactive tour, combining workflow with clinical connectivity, to gain an understanding of current practice and to identify key integration points Radiology uses everyday. Discovery of these integration points will lead to a discussion on available integration tools and conduits in today’s PACS, RIS, HIS and healthcare IT market place.
This session will navigate real-life issues presented by the audience in addition to case studies from First Consulting Group (FCG) clients where complex sets of scenarios confronted the integration teams. We will walk the group through the finer points of objective-based project planning and then talk about resolution tools; working with the audience interactively.
We will produce a visual set of examples for each integration point, justification for each identified solution, and solicit examples from the audience that may also present solutions to the integration issue under review. We will also engage the audience to “try to stump the integrators!”
The discussion will cover the following areas of Clinical Connectivity:
 The advantages of using an Episodic-Centric View of a Case when clinical data is needed for a study (CbPR – EMR)  The efficiency of utilizing MPPS from the modality (pros for the Technologist as well as for the Radiologist)  The practicality of completing procedures at the QC workstation or at the modality for CT, MR and Ultrasound  Structured Reporting for Radiology: how integration to a PACS can make an IDN’s OP Imaging Facility(ies) more profitable  Transcription, Voice and Digital Dictation integration with RIS vs PACS: What makes sense and why.  How synchronization-based integrations work and why they are so popular  Workflow, and why it matters  Recommendations for reducing interventions and keystrokes via practical integration  Single sign on, and biometrics to engage a single-sourced Diagnostic Workstation for the Clinician in every Radiologist  Practical IHE tips and ways to initiate a discussion with the non-believers!
Using practical methods and real-world scenarios, this session will cover the various roles and applications of the IHE initiative today with an overview of clinical connectivity in Radiology. The attendee will walk away with a clear understanding and – more importantly – a useful knowledge of IHE and what it means to Radiology. Applying the IHE principles to the unique needs of large hospital networks enables IDN administrators, IT staff and physicians to design workflow solutions that meet the goals of all healthcare providers: to better, and more efficiently, serve the patient population in our respective communities.
Learning Objectives: This session will enable radiology administrators to:
• Identify the key areas of integration as it relates to their current workflow
• Understand the value of clinical connectivity and the practical nature of IHE as a tenable standard
• Appreciate the value of desktop integration and what it means to the Radiologist
• Identify integration conduits available in the marketplace today that are working with IHE standards as well as their R&D road map
• Realize that without integration Radiologist cannot be the clinicians they are expected to be, and we fail as Administrators not understanding the nature of integration and how it effects our financial outcomes
SCENARIO – CLINICAL CONNECTIVITY
The Radiologist logs in to his or her diagnostic workstation, designed to meet the Radiologist’s needs by using the standard back-end HL7, DICOM integration with the facility’s Radiology Information System (RIS) and digital modalities.
The Radiologist peruses the Interpretive Worklist and selects a group of Diagnostic Images (i.e., the first patient on the list)
Patient: Osborn, Patsy C Medical Record Number: 498809309-1 Date of Birth: 11/24/62 (Calculated Age: 42 Years Old) Sex: F = Female Procedure: 10124-67 Abdomen Series (3 Views; KUB Upright/Flat and PA Chest) Patient Type: OP = Outpatient Reason For Study: NOS Abdominal Pain
The initial impression: WNL Abdominal Series PA, KUB Flat and KUB Upright – Kidneys normal size, no abnormality seen. Bowel normal, no abnormalities seen. PA Chest view normal, the lungs are clear, no free air visualized on upright or chest.
Overall Impression: KUB-FL/UR&CH1 Normal.
ALTERNATIVE WORKFLOW SCENARIO
Imagine what the Radiologist could have done for this patient if he or she had clinical connectivity at the workstation:
 The radiologist logs in to the Diagnostic Workstation, simultaneously and automatically logging into the facility’s Radiology Information System, Electronic Medical Record system and the Transcription System (in this case, Voice Recognition system).  The Radiologist clicks on the query for Unread Diagnostic Studies.  The Radiologist opens the first patient: Osborn, Patsy C, and notices a flag on the toolbar, indicating that clinical notes are active for Mrs. Osborn.  He or she clicks on the toolbar script button and discovers that Mrs. Osborn’s last episode of care had her in as a series patient being treated for a Phase II protocol for Basilar Arterial Cancer. She also has a dietary assessment clinical note that indicates that she is on a high fatty content diet.  If the Radiologist wants to see more information on Mrs. Osborn, he or she can then click on “Detail” and see what other procedures Mrs. Osborn has had performed across the enterprise, from Same Day Surgery to Ambulatory Care or even Home Health. (Note: these are all cross-enterprise systems are connected via desktop integration and tied to the current login and patient query data by the Radiologist).  Results – from pathology to the blood pressure check performed prior to stepping in to the radiology chamber – can now be viewed, as they have been documented and are available via the enterprise-wide integration. Along the line of each intervention – be it documentation or patient contact – information will have been entered into a relational clinical information system.
The list of medications, allergies, history/physical(s), discharge summary(ies), charts/assessments/VSIO and prescribing/ordering physician contact data are all available within the framework of clinical history available in multiple clinical systems. This data is no longer located on a data island; rather, it is connected and integrated with multiple systems within the framework of today’s medical institutions.
Are we willing to do what it takes to get this clinically relevant and patient-specific data to the radiologist to allow him/her to participate in delivering a higher quality of service? The radiologist should be freed of hard copy requisitions, handwritten notes and multiple logins to multiple systems prior to interpreting a film. Each of these tasks impedes his or her ability to provide sufficient care.
Instead, the radiologist should have a functional desktop, one that is capable of providing access to data that resides within the network of care and designed to benefit the healthcare professional and, ultimately, the patient.
This is the definition of clinical connectivity. Assistance for achieving true clinical connectivity in the IDN exists in the form of the IHE standards (today and those being developed), are seen in CCOW efforts in Europe, and can be managed by contracting professional integrators that understand workflow and Information technology connectivity across the Enterprise.
It is fairly obvious That IHE is of paramount importance to radiographers radiologists and clinicians. Has this been taken on board by NPFIT? Will the PACS RIS and PAS suppliers be asked to demonstrate IHE conformance before they become the preferred suppliers for LSP. Or will we have to make do with systems that do not meet IHE standards just because they are supplied by LSP.
In the consulting world when we perform a system selection using the IHE framework as the primary functional requirements, proof of concept (for demonstrations) and open lines of dialogue specifically related to workflow we have vendors that are less than confident about what parts of IHE they can really meet the requirements even though these components have been well defined. The naming nomenclature still seems to be a language barrier between those of us that understand clinical connectivity via our experience from the Information Systems side of the house and can express the reasons as to what data elements are passing from one system to another still have difficulty using (with confidence) words like order filler and placer. I try to break down the IHE requirements by putting an emphasis on the HL7 streams associated with that which has been defined technically by IHE gurus.
Example: • ADT/Patient Registration (IHE) really means HL7 = A01 thru A07, A11 thru A13, A38, A40 for ADT management
• Order Placer (IHE) really means HL7 = ORM, NW, ORU, ORNCA, ORNDC, ORM/SN, ORM/SC, ORM/OC for order communication management and status updates
• Department System Scheduler (DSS)/Order Filler (IHE) really means HL7 = SIU messages for pre-fetching
I just completed an effort at a client site to integrate a PACS system to their HIS EPR/EMR/AMR solution; Meditech HIS HCIS EPR (NT Version). The concept is similar with other HIS systems using a URL call with an HL7 outbound feed of Order Status (HL7-ORU), or an XML interface allowing a java type of applet to embed in to the EPR application. Some PACS systems offer a Key Note focused integration rather than the entire series but very few vendors have gotten to the point that they are pushing studies to an EPR system which is probably around the corner to meet the requirements of clinicians.