This isn't upsetting, it is stating the obvious ... the radiology industry globally has failed to move beyond a very basic and primitive capability in regard to report workflow, authoring, encoding and interchange (much less structure).
I don't think radiology reporting is the "killer app" in terms of driving technology and infra-structure change; this is more a question of waiting and seeing what develops for the broader application of clinical "information" interchange.
Note that I did not say "documents".
Right now one can push around "information" about also sorts of things using HL7 V2, for example, and radiology reports come along for the ride.
When/if that infrastructure moves away from HL7 V2 to something else widely deployed, whether it be push or pull, XDS or XDR, document-oriented or message-oriented, loosely or tightly coupled, etc., or something not yet described, then, and only then, might there be added value beyond existing solutions. As a case in point, in the US, the ONC Health IT Standards Committee is pushing "DIRECT", which is secure email based (with a grudging acknowledgement of XDR as an alternative), for pushing stuff around; the rate adoption of this "competitor" remains to be seen.
Since the state of the art in layout of the report is relatively unformatted plain text with a few headings, for the radiologist to "author" more than that, in the absence of tools and incentives (such as a positive impact on patient outcomes), the "value" of any more sophisticated solution (than a string of ASCII characters) for encoding may not be there; i.e., the "features" of PDF, CDA, DICOM SR just aren't utilized, except in so far that the metadata encoded with or around those formats simplifies their exchange and management.
In short, I don't think this is a question of who to "blame", but rather that the added value of a more complex solution fails to manifest itself in the radiology reporting scenario.
I still think though, that where there is a very specific use-case, there is merit in exploring the definition of a new and very specific IHE profile to describe (one of many) potential solutions to the problem. In my earlier post I suggested that defining a "teleradiology profile" to meet your specific needs might be worthwhile. Arguably, such a profile might standardize several different transactions to implement it (perhaps as options of the profile), such as communication of a plain text report in various formats via various messaging mechanisms (HL7 V2.5 and XDR perhaps); that way you could standardize the interactions to include a set of alternative solutions, rather than a single one, such that you can hedge your bets in case one format or transfer mechanism fails to catch on. Or, you could just standardize on the one basic approach that is common right now using DICOM and HL7 V2, and defer XD* etc. for another day.
In my opinion, the value of such a profile would be in the sequence of operations and the expected behavior at each end and the management meta-information communicated, more than just the payload itself, which can be dealt with by adapters/converters as has been pointed out before.
It might need to be done as a UK-specific national project initially though, since it is hard to get the mainstream IHE radiology folks interested, since they are distracted by other report-related activities at the moment. In essence, that is what your draft document is the outline for, a "profile" that entails DICOM push of images, request and report outbound and HL7 push of a report back; you just need to spell out the details (and you really do, or it won't be interoperable).
Standardizing a teleradiology scenario where the immediate recipient of the returned report is the responsible enterprise (that generated the images and would otherwise have generated its own local report), avoids entirely the question of how it gets to GPs et al (in what form and by what mechanism), since it would be the same as however locally generated reports were distributed (i.e., converted by the local system as necessary), assuming that the "profile" requirement calls for the expected behavior on receiving the report to be to "import" it and make it available like a local report.
That way, you can mix-and-match teleradiology providers and vendor solutions and yet achieve the same workflow, without custom integration for each, which I presume is a desirable goal.
Thanks David. I think this is very re-assuring for me that experts like you are willing to consider a "teleradiology profile"
There is something I feel very strongly about. In the past radiology reports were simple one liners "Normal heart, lungs & mediastinum". Today with cross sectional imaging reports are complex. Hence, I really feel we need to move from a bland message format to a proper document format so that reports are readable for the recipient. When our reports are printed on paper they have a nice format & template & the same report going via HL7 v2 has a bland appearance on PACS.
With a national target requirement for Clinic consultation letters to reach GPs in 24-48hours, I was involved in the project in our Trust. One suggestion was to use the DTS/PMIP for transfer of clinical letters. Both the hospital doctors & GPs refused this, as due to loss of formatting & readibility of the letters sent via a messaging method of transport. We currently use a proprietary system from Medisec--which sends doc in MSword format electronically.
I was under the impression that XDR-I would allow for transport of images & documents together & would work as a "teleradiology profile" Am I wrong?
My interest in XDR is because it allows for transport of reports 1. RIS to RIS 2. RIS to GP systems 3. RIS to EPR etc XDR allows a consistent approach for all clinical documents. Radiology reports after all are documents. ITK in the NHS is also looking at CDA & XDR.
The stumbling block to use of XDR is a DICOM system--PACS which does not want to support document display. If PACS did support document display, we would not need a separate teleradiology profile we could simply use XDR-I. SEND from PACS to TELERADIOLOGY 1. Current image for reporting 2. Prior image 3. prior report 4. scanned request card/electronic request doc SEND from TELERADIOLOGY to PACS/RIS current report
I asked for Michel Pawlitz (Karos Health) a DICOM & CDA standards expert working with Canada Infoway project for his views on this. He has been a speaker at our meetings too. I am really re-assured by his response about the direction Canada is pursuing. I am hopeful that Canada will provide the leadership for the world for clinical document transfer using CDA. I do believe that NHS must adopt global standards (seeing the success of DICOM)
"I agree with the fact that DICOM has a particular focus on images and not the report, the ultimate result of the diagnostic imaging test. This has proven to be problematic as many image sharing implementations that ignore the need for report exchange along with the images. The report is the most important part to communicate within the health community and if there is interest to look at the images based on the report, images should be made accessible but that is only required as a second step. Vendors have followed the standards and have ignored to deal with the link between images and reports, even the SDO's and IHE Radiology have yet to address this and provide guidance. I share therefore the sentiment and the need for the international community to resolve this. The first part of this problem is agreeing on one report content format (which will be CDA) and the second part is to provide guidance how reports and images, both documents, can be linked to effectively to make then accessible and exchange them together."
In addition I have started to work on a Radiology Imaging Content Profile (based on CDA) and will propose this in IHE Radiology as a work item for the coming year. Hopefully this helps to promote the importance of DI Reports and provide guidance for exchange."
Dr. Clunie raised some concerns about use of CDA due to licensing issues by HL7 at the spring meeting. Michel has had discussions with HL7 International about CDA licensing and here is a Q&A doc. He has given me permission to post on the website.
I also asked Michel about whether we could use XDR-I, intead of creating yet a new profile with IHE. He said he would discuss with Chris Lindop who is writing the XDR-I profile(has also been a speaker at our meeting). It all looks very positive for the user community. I think we are having good dialogue with global standards experts.
Thanks David. I have read your blog. I do not understand the entire issue. However, I understand your concerns.
However, pragmatically, HL7 is a more ubiquitous standard then even DICOM. Any modern Healthcare IT system supports HL7 version2 (whilst majority do not support DICOM). All DICOM PACS suppliers HAVE to support HL7 to communicate with RIS for demographic updates & DMWL. Hence PACS cannot survive on DICOM alone. If there are licensing issues it will not only apply to CDA but apply to HL7v2 too from what I understand. I cannot see HL7 being replaced by another standard. It is like saying let us look at an alternative to DICOM.
Radiology CANNOT live in a DICOM cocoon. It MUST communicate with non-DICOM HL7 based systems--GP systems, Ordercomms, Results Reporting Systems, so called EPR etc etc. This is why IHE came about as all the answers did not lie to DICOM alone. Radiology report is a clinical document which needs to be well displayed & readable--it is not a message. It is not all about images in radiology.
I would like the DICOM & IHE standards body & PACS suppliers to work with HL7 and bring about a quick resolution to this issue.
CDA & XDR-I will mitigate the need for a separate tele-radiology profile & also allow a standardised methodology of transfer of clinical documents--whether radiology or non-radiology. I think the adoption is very much dependent on PACS vendors as it is the vendor community that brought about the success of DICOM.
I think you are again confusing payload with transport.
I don't think this has much to do with the relative prevalence of DICOM or HL7 V2 messaging of plain text reports (which is reasonably well established), and I am certainly NOT suggesting that DICOM be used for either transport or payload with respect to getting reports to GPs; I don't know why you keep restating this needs to be separate from DICOM in your responses, since that is a given and I am not suggesting otherwise (for GP delivery).
What I am saying is, given that there is not yet a widely implemented document format, and CDA has licensing issues, why not choose a different format that does not have licensing issues ?
After all, it is a no-brainer to create a radiology report in some XML or similar form, and the CDA additional material is of very little value, especially in a context where the relevant meta-data is defined (duplicated in the CDA case) in the transport mechanism meta data and does necessarily need to be replicated in the payload "header", such as is the case with XDR* or XDS* (there are both pros and cons to having it in the header too).
The fact that HL7 defined CDA, does not mean that it is anyway related to other parts of HL7 (like V2 messaging), or V3 (for which messaging is dead, and the information model is dubious, though applicable to the CDA meta-data, and the data types are in a state of flux).
So when you refer to "HL7 based GP systems", make sure you are being specific about what part of "HL7" you are referring to; HL7 V2 messaging and HL7 CDA documents are not really related to each other in anyway (except that have the same (apparently evil money-grubbing) parent organization).
Or in other words HL7 V2 messaging is indeed "ubiquitous", as you put it, certainly in the US, and certainly within enterprises. CDA is not (yet), and you should not assume that the success of V2 implies the success of CDA (look at the fiasco that is V3 for the counter-example).
If, and only if, CDA were to be freely implementable, then it would be an adequate (if somewhat overburdened) format for this and other documents; since it isn't, in my opinion it should be avoided (until it is), particularly by any one building an infrastructure that has not already spent money on it.
Frankly, just using PDF to distribute your "pretty" reports that contain some formatting would be quite adequate for the job (and yes, PDF is an open standard, despite the fact that it came from a commercial company), though for those who anticipate they will be authoring structured content (extractable codes and numbers, etc.), it has limitations compared to CDA, a CE 13606 extract, or some other hypothetical XML schema to encoded text + format + structure.
So, just because some authorities and vendors are encouraging CDA adoption, it seems largely with the hope that it will become a self-fulfilling prophesy; you certainly seem to be drinking their Kool-Aid as a case in point. So I don't think it is yet too late to turn away from CDA, which in my opinion is warranted if HL7 does not relax their membership fee constraints.
PS. I am also not quite sure why you keep bringing PACS vendors into the equation as having responsibility for reports, since reports are mainly the province of RIS and dedicated reporting system (and speech recognition) vendors, and the distribution is increasingly the province of the EHR vendors. That is the case in the UK, right? So I am not sure why you state "adoption is very much dependent on PACS vendors". This is one of the reasons why something like XDS-I or XDR-I with reports is challenging (as opposed to handling the reports with XDS or XDR completely separately from the images, like any other document), because responsibility is divided, in many deployments. This is one reason why IHE Radiology has not had much success in standardizing anything to do with reports, despite a decade of effort.
Just to be clear, David what you seem to be saying: 1. There is no licensing issues with HL7 v2 which is open. 2. HL7 is imposing licensing costs on CDA only 3. We could use pdf with XDR for report Transport
I dont have a problem with use of pdf or any other document standard. As a user, i simply am looking for a plug & play document standard to enable a teleradiology workflow-- without re-inventing the wheel. It will be easy for RIS suppliers to implement "print to pdf"
Yes, I do believe, PACS suppliers are key as they are going to be providing the teleradiology solutions too. They need to be able to link & store DICOM images with reports in document format. Increasingly PACS suppliers are taking on the reporting functionality from RIS-(leaving RIS with admin type functionality) to support a teleradiology workflow.
It will be the "report creator" which will also be responsible for report distribution to other clinical systems-GP systems. I think do think PACS companies need to think long & hard and realise that plug and play inter-operability for clinical documents is in their interest & work with IHE to find the right way forward.
No, HL7 imposes an organizational membership requirement on most of its stuff, including V2 messaging and CDA. I have no metrics on the extent to which this requirement has been ignored by HL7 V2 implementers.
But exchanging documents with XDR requires no "HL7 tax", so yes PDF by XDR would get the job done.
One should clearly distinguish between PACS "systems", as opposed to vendors who happen to sell both PACS and RIS (or for that matter the speech recognition systems that are the real "report creators"), and either integrate these systems or actually build one system to serve multiple functions. Workflow and charge management still need to be performed after all.
My understanding is that, globally at least, most deployments still keep PACS and RIS functionality separate, and report distribution is through the RIS (+/-EHR), and report creation is separate yet again, in terms of vendors and software. I am not well informed about the role and implementation of RIS in the UK though.
That separation does beg the question of which single "system" puts the image and reports together on CD, uploads them to a cloud sharing service, makes them available together via XDS-I, etc., of course, so I am not suggesting that the "PACS" is completely off the hook, just that is not the primary driver of payload and transport standard choices.
Hi David, HL7 is used by all Healthcare IT suppliers. I think it is important to get a clear position from them before we stop customers from supporting CDA & from suppliers developing CDA in their product. I will try & get someone from HL7 international to give a position on this issue at the Autumn Meeting.
From a user perspective CDA is a good document structure for medical documents. Canada infoway is planning to use it. I think it would be useful to have a global medical medical doc standard in the same way as DICOM is for images.
Let us wait till Autumn meeting before passing judgement on CDA.
All Suppliers I spoke to at UKRC (big or small) all are members of HL7, as they all are using HL7 v2 messaging. However, whether HL7 should be using membership for a licensing model needs clarification. I will try & get someone from HL7 to give us clarity.
Before adoption of CDA, PACS, VNA & RIS suppliers want to make sure that this will be the global standard for medical docs in the say way as DICOM is for images HL7 v2 is for messages I hope in Autumn Meeting we need a debate "should CDA (or pdf) be the medical doc standard for NHS?"
Regardless of whether some, most or all current suppliers are currently HL7 members or not, the fact remains that a closed standard choice may preclude some participation, especially by other than the "usual suspects" (with whom many of you are hardly enamored).
I need not restate the issues that have stimulated intensive debate at the European level as well as the current UK Government Consultation on Open Standards (which recently closed, on June 4th). It will be interesting to see what the Cabinet Office comes up with in the end, and what impact that has on your purchasing flexibility.
I suggest that it might also be interesting for the Autumn meeting to raise the question of the use of open or closed standards, issues of copyrights, patents and license fees, and invite some EU and/or UK software legal experts on both sides of the argument to debate the matter. Admittedly the subject is probably only of abstract interest to the attendees, since ultimately all you can buy is what the suppliers choose to sell.
PS. Note that I would not want to discourage anyone from joining a standards organization to contribute, be it HL7 or any other; what I am opposed to is compulsory membership (or a royalty or license fee in lieu of membership).
Thanks David. That is a very good suggestion about getting a discussion about definition of "open standards" from some global experts. I will touch base with you offline for speaker suggestions. Like you & Dave, I too believe in global standards. I see the success of DICOM & believe that we need something similar for medical documents. NHS ITK team, Sintero project, Canada Infoway, & I understand US standards bodies are looking at HL7 CDA as a credible document standard. Yes, we need clarity on licensing issues with HL7. But i accept we can use pdf as a pragmatic alternative. Pdf is particularly of use for use in scanned paper documents like request cards. All PACS & RIS vendors I visited at UKRC are listening intently at our debate. Most PACS vendors are capable of displaying a pdf/cda via their VNA viewer. However, some are also able to do a native pdf/cda display of reports & requests within PACS- to support a teleradiology workflow. VNA vendors with XDS registry & repository capabilities are confident about doing the XDR-I workflow to send scanned request card with current DICOM images (with relevant prior images & reports) to the Teleradiology solution. They are also confident about being an XDR recipient of the report. They will then send the report to RIS & hospital PACS. This could bring about plug & play integration between hospital VNA to teleradiology system to support a teleradiology workflow.
Plug& Play integration is key to ensuring that there is no vendor lock-in on either side-PACS/VNA or teleradiology solution.
posted on Thursday, July 05, 2012 - 10:07 pm
I have taken some time out to review this very interesting thread. With 35 quite detailed posts and associated documents it took over a day to understand the context! To get a grip of the views being expressed, I made a PowerPoint synopsis and visualisation of the posts - to avoid repetition it can be downloaded .
Being only a précis, the PowerPoint passes over some details in order to get to the essence of the discussion. The thread’s tensions are narrated in the slides: they (reasonably) divert the focus away from the original “collaborative” model proposal - towards barriers and issues such as cross-vendor commitment to candidate interoperability standards and profiles (and their attendant foibles ;-).
However, the following is trying to “separate the concerns” (in order to get back to the purpose, as that seems the right thing to do at this point).
From the thread I detected the following expressed (or implied) concerns:
C1: regional approaches to collaboration could lead to incompatibility [slide 2] C2: lack of systematic (agreed) transport methods [slide 4] C3: added repeat (bespoke) interfacing costs [slide 4] C4: potential multiplicity of standards options [slide 4] C5: charging ('tax') issues for using candidate standards [slide 5] C6: indecision re: a clinical document standard (a generic problem, not just Radiology) [slides 5, 9] C7: insufficient (detailed) system specification and standardisation [slides 5, 6] C8: no support for interoperable workflows e.g. in XDS/XDR [slides 5, 6] C9: VPN difficulties, giving way to professional-friendly cloud workflow [slides 7, 8] C10: inability to serve systematic information exchange due to lack of vendor uptake [slide 9] C11: lack of guidance on how documents/images are accessible in standardised ways [slide 9] C12: specifically prohibitive HL7 licensing/fees/compulsory memberships [slides 10, 11, 12, 13, 14] C13: data duplication overhead in CDA methodology [slide 12] C14: lack of CDA "ubiquity" [slide 13] C15: leadership vacuum on fully open standards [slide 14] C16: no cross-vendor ‘plug and play’ integration (in ways that prevent lock-in) [slide 14]
That’s quite a few concerns, and it is probably enough for one post just to list them!
It seems to me that one central issue is the way national clinical domains (like Radiology, but certainly not specific to it) “think-through” the whole landscape of community-collaborative information flow. There seems to be no consistent methodology, leading to fragmentation of requirements and purpose. The value of discussion threads like this is they can reveal where interdisciplinary gaps exist (case-in-point: to achieve pragmatic, cost-effective and scalable workflows). This is valuable because to be systematic some co-ordination of national stakeholder actions are required. Without that we get more of what we have now – fragmented standalone systems which (despite their individual merits) need increasing numbers of costly non-standard interfaces to be used at scale (i.e. "everywhere-to-everywhere").
The resolution of the concerns list clearly requires domain leadership to find neutral mechanisms where individual business models can co-operate to solve the “concerns” and thus deliver higher value.
With the aim of encouraging future intra- and inter-domain collaboration, I should mention my project Sintero (funded by the Wellcome Trust between 2009-2012). Sintero is referred to in the above post - in relation to use of HL7 CDA. Sintero stands for Simplifying INTEROperability: it has created an open commodity architecture for “vendor-neutral” information exchange in health care and secondary uses (incl. research). “Neutrality” is a point of principle. The framework only exists to simplify and support interoperability from a neutral (non-commercial) perspective between existing systems e.g. by specifying common metadata usage models, clinical document formats and (by means of a cross-vendor framework called miConsent, see ) patient-centred consent frameworks.
More information on Sintero will be published soon . In the meantime the “common metadata” aspect is documented  to be followed by CDA and cross-vendor consent specifications. This open framework expressly supports HL7 CDA and IHE XDS to help specify detailed interoperability constraints within clinical domains. All vendors or sites (who wish to interoperate) can use the standards as part of the project. The miConsent framework  only uses metadata that is available within the native XDS and CDA standards. This kind of standards-driven feature could be important for delivering high scalability at low cost. Adopting common metadata frameworks for simplifying interoperability is analogous to multilingual groups choosing one working language (to avoid multiple simultaneous translations).
Thanks Ed for a good analysis of the discussions. For those who do not know Ed, he is very highly regarded in the IHE-UK community. We have had many debates over the XD* metadata for UK--which has evolved in the Sintero spec.
SINTERO is an exciting project. "This open framework expressly supports HL7 CDA and IHE XDS to help specify detailed interoperability constraints within clinical domains." Canada is also using CDA.
The key point that Ed makes is "Adopting common metadata frameworks for simplifying interoperability is analogous to multilingual groups choosing one working language (to avoid multiple simultaneous translations). '
I think all the huge problems we have with healthcare communication can easily be resolved by using a common metadata framework in NHS--XD* metadata XDR--point to point transfer of health doc XDS--multivendor systems with a common registry within an organization XCA--patient centric view of data held in multiple organizations.
Ensure that VNA that are being bought with PACS replacements are XDS/XDR/XCA complaint to future proof investments in PACS replacements.
I think this will make an exciting discussion at the Autumn Meeting 1. Is HL7v2 & CDA an open standard by Cabinet Office Criteria? 2. CDA adoption by Canadian Infoway Project. 3. XDR with CDA/pdf for report transfer between hospitals & GP surgeries 4. Why an XDS/XDR/XCA compliant VNA is the future for NHS?
I would be grateful for readers to suggest any speakers on the above topics (vendors are welcome too). Vendors you have spoken at our meeting previously, know that we are keen to have new vendors speaking at our meeting & we have detailed discussions with vendors about neutrality of the content before they can speak at our meeting.
posted on Thursday, September 27, 2012 - 03:45 pm
Whilst, open & closed standard debate for HL7 is now resolved, we can concentrate on the plug & play standard for teleradiology. We will have a session dedicated this this. This are some slides I put together for the Manchester Conference.