10 years ago, many modality suppliers was selling a workstations with some storage space and image manipulation capabilities. Many hospitals had workstations--1 for MR, 1 for CT, 1 for NM, 1 for Fluroscopy, 1 for CR etc etc. Many vendors then started selling some server space alongwith workstations----MiniPACS. Radiologists had to move from workstation to workstations if they wanted to report on digital images. Film packets were the only way of providing a full imaging history in one place, as modality workstations created imaging data silos.
DICOM as a standard changed the digital imaging world. It is a vendor neutral standard. All radiology images from any modality supplier can be stored on PACS due to adherence of DICOM standards. For those modalities that did not support DICOM send or DMWL, intermediary boxes were put in. Nowadays no modality vendor can sell a modality with adherence to DICOM.
PACS integrated the imaging history, thus replacing the film packets and we moved filmless.
For radiologists there was a remarkable change. We did not have to move from workstation to workstation to report. I can do all my reporting using PACS---including 3D etc etc. From a commercial perspective, modality vendors must have seen a fall in sales for modality workstations and their small servers.
Modality, DICOM and PACS analogy can be applied to Informations systems, XDS and EPR. Currently, Information systems (RIS, CIS, Ordercomms, Clinical letters system, Discahrge summary system, E-Prescribing etc) all hold digital information as data silos, due to lack of document standards. The only way clinicians can access full clinical history is by looking at paper notes, where the documents are printed and organised for a patient. XDS provides a document standard which will change the EPR world completely. Information systems (like X-ray modalities) will create the documents and send them off for staorage and display.
I think the next big change will be a PACS vendor who offers a "DICOM and XDS archive" and a "DICOM and XDS viewer"---Currently PACS vendors offer a DICOM archive and DICOM viewer. All major PACS vendors are aware of XDS. This leap of faith will offer customers an patient centric image and document viewing capabilities---an EPR!!!
Once suppliers are offering a system that stores both images and documents customers will prefer that over a system that only displays radiology images (analogy with a workstation that only displayed CT from a particular vendor).
Once XDS is realistically adopted, PACS will be a thing of the past (similar to modality workstations) and EPR will come about using XDS and DICOM as standards. Intermediary boxes will arrive to convert non-XDS information system to XDS.
The other big advantage will be that currently we struggle with old outdated information systems which are difficult to remove and replace. By adopting XDS standards, information systems will send all data to XDS repository and hence, one will find it as easy to replace an information system as it is to replace a CT scanner/MRI scanner.
Currently with a "connect all strategy" from the DOH/CFH, XDS provides a means of providing an EPR, and replacing the paper notes----in the same way that PACS replaced the film packet. XDS connects all information systems currently existing Information systems.
This is my predictions of the future. We will see what 2013 brings. If we have a competitive market for PACS, a supplier proving "DICOM and XDS archive" with DICOM and XDS viewer will definately have an advantage over a "traditional" PACS.
posted on Monday, February 22, 2010 - 08:35 am
An outstanding and visionary expression of where we should be in the 2013 contractual round. Are the DoH negotiators aware of this and does anyone know if this is being taken on board?
I do hope national lessons have been learnt with monopoly creation by CFH contracts, and the resulting huge costs to taxpayers. As far as EPR is concerned the CFH strategy has failed miserably. Many of us predicted that creation of monopolies was wrong, but we are, where we are. I do hope that those readers of this forum can share this vision, and in their various positions in DOH, CFH, Trusts, College etc can influence the direction of travel for the future. I also hope that PACS suppliers can also share this vision.
We just need 1 credible PACS supplier to provide a "XDS and DICOM archive" with "XDS and DICOM viewer" instead of a "traditional" PACS.
If you think about it the opportunity is here even today---Trusts are looking for "Cardiology PACS", "Breast Screening PACS"----some Trust maybe visionary enough to buy a "XDS and DICOM archive" and "XDS and DICOM viewer" rather than a "traditional" PACS which only deals with images. Once you buy such a system, it will be easy to simply migrate radiology to that system in 2013, when the current PACS contract comes to an end.
We do have some very high profile speakers at the 19th March meeting. Let us see what they have to say. XDS as a standard needs to be credible for Suppliers wanting to adopt this.
posted on Monday, February 22, 2010 - 10:46 am
The points made, and opinions offered, by Neelam are very relevant and provide options and solutions for addressing many of the real world challenges that the clinical community, both Radiologist and referring clinican,face today. However, I believe that the argument needs to be developed further.
Wider DICOM and XDS adoption by the vendor community, whilst addressing many of the issues faced today is not the total answer.
Many PACS vendors' database schemas store a significant amount of clinically relevant data in a proprietary format, GSPS for example.
Ideally data should be stored in a PACS or Vendor Neutral format. This is possible with software from a number of vendors that facilitate morphing and storage of propieatary DICOM tag information.
The data stored in such a repository should also be from a number of sources outside Radiology. For example, Cardiology, Dermatology, Oncology, Pathology etc.
The archive would of course store both DICOM and non DICOM image objects and must receive relevant HL7 messages from the departmental/enterprise imaging system for insertion of relevant patient demographic updates and merges.
Such a solution, incorporating a universal clinical viewer, will truly enable an Electronic Patient Record, providing benefits not just to the Radiologist but to the broader clinical community.
The field of Vendor Neutrality is gaining momentum in the US and internationally, as well as the debate that continues on this website.
To ensure that the nettle is grasped, and to tighten and eliminate issues related to proprietary data amongst others, a case can be made for developing a new standard. This topic was recently discussed on another forum. A well respected consultant in the US suggested that the IHE committee should define clearly what is meant by Vendor/PACS neutrality to avoid similar issues from the past with implementation of many different flavours of DICOM.
It is to be hoped that such solutions are in place before 2013, and the replacement of the current contracts. If there is no format for truly storing/migrating legacy data from the Cluster data stores, someone is going to be picking up very large bills for either custom migrations or extending the existing contracts.
As you will know I am all in favour of vendor neutrality. DICOM is a vendor neutral standard which allows modalities from multiple vendors send images to a Central PACS server using DICOM. This works well in the commercial world.
What you are suggesting is separating archiving and viewing. There is a problem there. When we move images from one PACS application through DICOM Q/R it is rather slow. Hence, I do not know of any vendor providing a "PACS viewing application only solution" which will display images stored in a vendor neutral DICOM archive, as this is not commercially viable. No customer will want to buy a PACS solution which takes 20-30 secs for images to load. A clinical user expects images to be loaded and viewable within 3-4 secs. I suspect this is why vendors store images in 2 formats (DICOM and proprietary). Proprietary formats allow them to display images in a timely manner I suppose. I am not a standards person or a technical person. However, I do know that DICOM Q/R is slow and would not work in a clinical environment. However, we have people like Martin Tiani and Dave Harvey who have both been involved in IHE and believe in a standards way forward speaking on the 19th March. Maybe they could give us some insight into the matter.
XDS is much talked about globally is the document standard for EPR/EHR---you can simply google it! The proof in the credibility of the standard I believe, is when a major PACS vendor will see it as way forward. I do believe that once an EPR (which has the ability to display both images and documents)comes in place (whether by adopting XDS/another standard), these current "traditional PACS" which only display images, will die a gradual death (similar to modality workstations).
I recently was speaking to my cardiology colleague. We store our Cardiac angios in our radiology PACS. However, the same old problem. Reports are not visible--they lie in Tomcat CIS. What the cardiologist friend said to me was that he would find it very useful to have access to ECGs alongwith imaging. This is where the XDS and DICOM archive is so powerful. Reports and ECGs could be stored as XDS documents and displayed alongwith angiograms for cardiologists.
Not trying to protect PACS suppliers, but I am not sure whether severing relationship between storage and display software is a realistic commercial and clinical option as yet. I do feel that PACS vendors can take advantage of the XDS Connect-all Strategy, if they felt that this was a serious option for survival and commercial gain. More discussions on 19th March.
Rest assured that the RCR ,CfH and IHE(uk) have been exploring the way forw= ard for XDSi based solutions, if you would like to hear some of the conclus= ions/join in the debate then join us at the next SIG meeting in March
posted on Tuesday, February 23, 2010 - 11:30 am
This does answer Ivan's question, is there somebody listening?
I think the key strategic direction is to bring back competition into the PACS Market. Competition brings innovation in the vendor community. The key reason for failure of the CFH is the creation of monopolies, which has come at a huge cost to the tax-payer.
There are many major PACS vendors wanting to enter the UK PACS market with good global products. If Trusts have a choice they this brings about consumer power. So far with the CFH-LSP strategy we have seen supplier power. I do hope lessons have been learnt.
DICOM proves that inter-operabilty standards do work. Imagine if a Trust had to buy all its modalities from the PACS supplier---yes there would be surcharge!!! As this would create supplier monopoly. If we did not have DICOM this is what we would have to do!!
National bodies like DOH should limit themselves to defining standards, and let competition drive innnovation.
I do believe that if PACS suppliers to find XDS a credible standard, we will find on offer "DICOM and XDS archive" and a DICOM and XDS viewer". This itself is a EPR which includes both images and documents, and we will see the gradual demise of the "traditional PACS" which is only capable of storing images. The question is who is going to the first major PACS vendor to tread in this direction.
posted on Wednesday, February 24, 2010 - 07:55 am
Sorry, but I need to reply here....there is absolutely NO reason why a competently written DICOM implementation should be any slower than a proprietary one! The PACS vendors keep on trotting out the lie that they NEED to use proprietary protocols to overcome the "slowness" of DICOM, when this is in fact complete garbage, designed purely to justify a commercial "lock-in" to their horrible proprietary alternatives. Some even seem to go as far as to make their DICOM deliberately slow (e.g. refusing to use even lossless compression!), simply so that it makes 3rd party DICOM workstations seem slow in comparison to their own.
Separation of archive and viewer is perfectly possible, if only users took the trouble to demand it at purchase time, and weren't taken in by slimy salesmen pretending that they need to be linked!
Gong back to the XDS question, you are though 100% right that XDS does provide both vendor neutrality AND cross-discipline multi-document type facilities, so we certainly don't need yet another standard to replace it!
posted on Wednesday, February 24, 2010 - 08:37 am
Whoopee for Dave telling it how it is as usual.
The proprietary scams that he describes need another one added: vendors who pretend that enhanced functionality can only be obtained if the buyer gets both modality and PACS from the same supplier!
This one takes us back about 15 years but is I hear becoming more common in sales pitches.
posted on Wednesday, February 24, 2010 - 03:11 pm
Good to see your posting on the forum!!!
However, the ground reality is that users can only ask for solutions that exist in marketplace. I have many a time heard that from CFH that "XDS" is only vapourware as no suppliers are offering it!
Vendor Neutral Archives are increasingly becoming available. However, I do not know of any supplier supplying a "DICOM or XDS viewer only" solution. If this does happen it would be great for the clinical community as Trusts could centralise their storage for images and documents (Trust EPR on a Vendor Neutral Archive) and we could a Radiology PACS viewer for us, Cardiology PACS viewer for cardiologists and so on, each with an appropriate set of tools to manipulate images and view documents. The thought of this possibilty is very exciting. Let us see some vendors developing viewing products which work with vendor neutral archives!!!
The ground reality with DICOM exists for us. We have Agfa Impax 6.2 with Terarecon as the 3D software with a DTI between them. If the Terarecon server does not have the images, Terarecon does a DICOM Q/R from Impax. It takes a significantly longer time to display if DICOM Q/R is required. Hence using that as an example, clinically it would be unviable to have a PACS storage from one vendor and display from another.
Whilst I am all for standards and vendor neutrality, we need solutions that work in the clinical world as well. Now adays XDS is a reality in the vendor world. At the last UKRC I saw the Forecare solution which took me by complete surprise. It suddenly dawned upon me that if a system could display images and documents from multiple sources --we have an EPR using vendor neutral standards.
However, we do need a movivation for suppliers to innovate. CFH-LSP contracts remove that motivation. We need the choice back in the market, and targets for departments/Trusts to go paperless. 1. Choice 2. Standards 3. Targets 4. Funds is what NHS needs. Good clinical IT is hugely important for increasing efficiency and reducing the cost of this tax funded service.
Just to note - the Irish National PACS formally signed off yesterday (still to hit the news yet tho) with XDS included. More as a future-proof than something specific but its there to be used now.
Until the Irish forum follows , I'll say here well done to the project team to get us so far under difficult circumstances. I know at least some of the guys follow this board.
On XDS, is it fair to say that XDS on its own doesn't entirely fix the problem? To quote the IHE wiki:
" In order to ensure the necessary interoperability between the document sources and the document consumers, the XDS Affinity Domain must adopt policies concerning document format, structure and content " note: "XDS Affinity Domain" = "organisations with common interest". Boy I wish they'd keep the language simple.
... i.e. XDS is format neutral - including proprietary formats (other than the registry meta-info).
And while I agree vendors should be encourage to innovate, that in itself means they will be at least putting open standards under tension, if not sitting entirely outside. As a result, the onus remains is on the users to ensure manners are maintain between vendors.
posted on Wednesday, February 24, 2010 - 05:19 pm
Possible naive question:
So XDS is a vendor neutral archive capable of displaying all sorts of documents. OK. But if this is to be the basis of an EPR, where do the docs (information) come from? Take A&E as an example. Acute trusts either have a seperate A&E solution, or something attached/incorporated within their PAS.
So do any of these current systems have an "output" that could be viewed in XDS?
At the moment XDS sounds like a pacs without any modalities attached.
posted on Wednesday, February 24, 2010 - 05:43 pm
The proof will be in the pudding! Has your PACS supplier just confirmed XDS compliance because it makes a good sales pitch, when we are all talking about XDS. Or is the XDS actually going to do something.
Is your supplier going to store radiology reports as XDS documents and display reports as XDS documents, or just going to use the HL7 feeds like the rest of us. Is your supplier going to store and display the ordercomms doc as a XDS doc or the usual HL7 feeds. Storing and displaying radiology images is easy as we use DICOM. What other documents will you be storing and displaying--pathology reports, lab results, clinic letters???? Distinction between DICOM and XDS largely around vendor neutral storage and display of documents.
I am not trying to undermine the Irish Project. I would say well done indeed. You are future proof. I think the Irish user community should be exploiting the use of XDS. You are in a very envious position.
posted on Wednesday, February 24, 2010 - 06:36 pm
I wouldn't actually disagree with that assessment - the situation with general clinical documents now is like it was for radiology in 1994 - there is an agreed standard (DICOM was published in 1993), but most equipment still relies on proprietary and non-interoperable standards. However, now that the standard is in place, and with a bit of confidence to push adoption there is no reason why it should not follow the same path, with initial "retro-fits" onto existing systems, followed within a few years by an expectation that any new systems would not be saleable without it. Retro-fitting is generally EASIER than it was for DICOM, and with any luck we should hear from Martin Tiani at the next PACS Group meeting how he has been doing exactly that in South Africa.
HSS have already retro-fitted onto their RIS, and the same for A&E or PAS systems should be equally easy.
posted on Thursday, February 25, 2010 - 09:18 am
To provide my very non-technical/clinical view of XDS repository and registry.
Let me make an example with a Clinical Letters system we have recently bought from Medisec/Integrated with Talking Point for DD/VR. The Medisec will take the demographics and ADT (patient location) messages from McKesson PAS. Clinics are booked on McKesson PAS so the clinic list required by Medisec is also got from PAS. Doctors will dictate clinic letters on Medise/TP. Secretaries will pick up dictated letters from Medisec and type it. Doctors will authorise letters using "authorisation worklist" on Medisec. These letters are then printed and 1 copy put in the paper notes, and one copy sent to GPs (we are looking at electronic delievry to GPs via Medisec). If we had an XDS based EPR, instead of printing a letter for notes you would "print to XDS". It is this letter which is required for sharing both externally and internally (via the Patient's paper notes). XDS EPR is a basically a replacement of paper notes. The systems responsible for creation of docuemnts will need to exists to continue to support workflows for document creation. This same analogy can be applied to A&E system. A patient discharged from A&E would have a letter from doctor to GP informing GP that the patient was seen in A&E. Same applies to patients discharged from Wards would have a discharge summary which is "shared" with GPs and stuck in the "patient's paper notes" for reference. The advantage of this approach is the abilty to electronically "stick" ECGs, medical photographs of a larngeal tumour etc which are images alongwith documents, in the same way as the paper notes. Similar analogy for Pathology systems, Lab systems will apply, where printed reports are stuck in notes. XDS EPR is an electronic replacement of paper notes. However, you do not need to replace your A&E system, Lab systems, Clinical letter sytem, Discharge summaries system, or any of the systems that are responsible for creating the clinical documents that are inserted in the "Patient's Paper notes". It provides a "connect all strategy" using global standards as a means of delivering this strategy.
The difference with Cerner EPR/Lorenzo has been that these followed a "rip and replace" startegy rather than "connect all" strategy.
PACS replaced the film packet. The film packet had 3 things within it. Images, reports, and request cards which need to stay together. Now we all know that reports and request cards are a problem with incorporation of PACS. In our Trust, Cardiac angio images go to Agfa PACS but report lies in within our CIS from Tomcat (which is a data silo). Request cards are no longer available with images within the enterprise. This is the backward step we have taken with DICOM--which relates to documents. Hence, the superiority of XDS. Currently we struggle with transfer of reports and requesting information between Trusts (DICOM push for image transfer--whether through IEP/bb-Rad etc is staright forward). This is where XDS supercedes DICOM as it defines a standard for ducuments and images. However, it also used the existing standards like DICOM and HL7, so it is not re-inventing the wheels.
XDS approach for EPR is a very simplistic only. Leave document and image creation to the "active systems" like RIS, CIS, A&E etc which create these (analogy of modalities which create the images). It provides a means of display, storage and cataloging (same as PACS is for images).
Dave can correct me if my very simplistic view of XDS is correct or not.