The following press release appeared a few days ago.
Medical Director and HealthLink announce secure messaging interoperability
Sydney, 14th October 2010
HCN, the developers of Medical Director, and HealthLink, two market leaders in the clinical IT industry have extended their service coverage by announcing secure messaging interoperability, which has today gone live in the ACT. Both vendors enjoy significant market share; Medical Director is used by more than 17,000 medical professionals and HealthLink is Australia’s largest health communication network with 5,300 practices, hospitals, laboratories and acute care facilities using their solution. This interconnection will enable any practitioner using Medical Director to send clinical information to any healthcare provider on the HealthLink network and it will allow any HealthLink subscriber to send information to any Medical Director user. The interoperability will enable a further 1,000 sites to be able to work with the HealthLink network.
The interoperability solution creates a message network interconnection, which facilitates the secure exchange of messages between users of MDExchange, the messaging component within Medical Director and HealthLink messaging clients. John Frost, CEO of HCN comments: "There is a very real requirement for information flowing securely between acute care and primary care. Medical professionals want to exchange reports, referrals, hospital discharge summaries and similar electronic messages today. Market leaders, Medical Director and HealthLink, have taken this important step towards widespread interoperability and have an operational and interoperable solution installed and live at ACT Health. This initiative will continue to evolve in order to adhere to the Australian secure messaging standards."
The joint eReferrals solution was first implemented by ACT Health, HCN, HealthLink and Orion Health.
"For GPs, the ability to send referrals by secure messaging direct from the patient's electronic medical record, is not only time and paper saving but allows the GP to receive acknowledgments that the referral has been received and to be informed in a timely and reliable way about scheduled appointments," said Dr Peggy Brown, ACT Health Chief Executive.
ACT Division of General Practice President Dr Rashmi Sharma said "connecting all health care providers and developing capacity to support team care and communications between providers will support a viable and accurate personal health record."
"By replacing paper based systems, patient care will be improved, ensure accurate and secure information transfer, supporting the transition when a patient changes or moves between health care providers".
"This initiative will further enhance the ACT Health eReferrals solution by increasing the number of general practitioners and specialists having access to timely and accurate information. It is another improvement to health interoperability between primary and secondary care providers." said Chris Stephens, Regional Director for Australia and Southeast Asia for Orion Health.
HCN has chosen HealthLink as their interconnect partner as both organisations share strong views on the integrity of messaging solutions. HealthLink General Manager, Geoffrey Sayer adds: "The initiative is designed to underpin a philosophy of total service quality for patients in their care as they move through the different parts of the healthcare system. The MDExchange-HealthLink interoperability capability is now available nationally."
The release is found here:
I see this as good news, in the sense that what we have here is really the service and software providers just moving on and doing their best to deliver what is needed in the absence of any real sense of urgency from NEHTA. Think what Medical Objects, Argus and others have done over the last few years.
An example of this slowness came into stark view just the other day:
Looking at the Business Specification for Discharge Summaries - an initial draft of this work was delivered in September 2008.
It has taken until 30 August 2010 to get a version 1.1 release out the door and it only appeared on the NEHTA website 8 October, 2010.
The document is here:
This timing is on page 3.
Just why is takes essentially 2 years to get a piece of work done of this sort, given the resources and workforce available to NEHTA amazes me. I guess I just don’t understand how complicated a discharge summary can be!
It is worth noting an Australian Standard for this was certainly created by 2004 and updated in 2007 - but clearly they must have been grossly inadequate. (I have a 2006 Australian Standard for HL7 V2.4 discharge summaries and referrals but this was later updated in minor ways in 2007)
Why this has taken so long I suspect is due to NEHTA’s attempts to pin down the details of every possible content data element and define it etc.
Of course having done that the issue is just how it will actually get implemented - compared with the rather simpler earlier approaches. Essentially they tend to over engineer and under deliver on what is a pretty consistent basis. All the e-communications projects have been core NEHTA business for ages and just how much has actually been implemented to date - not much I fear!
When we see this actually working in practice we will have our answer for discharge summaries I guess - I fear that will not be anytime soon with anything delivered by NEHTA!
David.
Does this mean that MD3 will be updated so it can easily receive a message with a payload including a portable document format (pdf) file, automatically associate it with the MD3 patient record as a report, and display it using the user's preferred pdf reader when they click on the relevant item in the reports section of MD3?
ReplyDeleteIf so, can the API for this be published so that others who wish to take advantage of this giant leap forward (into the 20th century) in GP desktop technology can do so?
Would be interesting to know the technologies used. If it's HL7 2.4 RSD messaging then, yes, this is a 20th Century Solution - but better a working solution than a more modern one (e.g. NEHTA's proposed use of HL7 v3 CDA for Discharge Summaries) that never gets past the design phase!
ReplyDeleteSince when has RSD been an Australian standard??? Its not!
ReplyDeleteMD3 HL7 is 2.3.1. Unfortunately it's not AHML compliant.
ReplyDelete@Anon the first - it's HCN/Primary don't hold your breathe.
Anon the second has missed the point.
ReplyDeleteThe transport is irrelevant providing the API is published. Of course if appropriate standards exist then they would be preferred, but frankly I don't care if they are flat file HL-7 v2.x or XML HL-7 V3.
The real question is what does the receiving application do with the information it receives? At present it is not possible to send a PDF to MD3 and have it do anything useful with it.
This is the real problem.
We should not even be thinking of sending PDFs in 2010. A PDF requires a human to read the file to extract the information. We should be using messages that have data that is computable. For instance AS4700.2 for pathology and AS4700.6 for referrals.
ReplyDeleteActually, it's a combination of the capabilities of the messaging standard AND the receiving PMS. However, if the messaging standard lacks certain features, there really isn't much that the PMS can do about it - so the standard is significant.
ReplyDeleteIn response to Anon 6, there are messaging standards that incorporate both human-readable text, documents, media files AND atomised (computable) data - e.g. HL7 v3 Clinical Document Architecture. Furthermore a lot of clinical information is held in document form (e.g. Referral Letters) which have to be transmitted and retained in a human-readable format.
Complaint HL7V2.3.1 can contain display PDF/html etc and atomic data with semantics, so there is no need to use CDA to get this capability.
ReplyDeleteWe do of course need the PMS applications to support it, which is the problem.
CDA documents are directly, human-readable - HL7 2x messages are not. Part of the CDA standard is an XML transform that can be used to convert any CDA document to an XMTHML representation suitable for display in any Browser. Try asking a Clinicial to read an HL7 v2.3.1 message!
ReplyDeleteBTW - HL7 v2.3.1 was approved in April 1999, the current release is version 2.6 (May 2007). Always good to follow the likes of the UK, USA, Canada and NZ who are adopting CDA for clincial reports such as discharge summaries!
CDA documents as xml documents and are not human readable!!!
ReplyDeleteTo suggest that the base level artifacts should be human readable is silly. The human readable form of CDA is produced by a software transform using xlst. The html display segment of a V2 display segment is also easily extracted for human use.
Dumbing down technical artifacts to make them readable by "Clinical Leads" is inappropriate. All formats including CDA need transformation to produce artifacts suitable for human readability. This is the role of software in the domain. The are mechanisms to produce human readable forms for both options and in reality the version 2 mechanism of extracting the html display segment is easier technically.
Humans are the ones providing the health care. They are the most important consumers of data by far, so we should design our systems - in particular our systems for sharing data between healthcare providers - for them.
ReplyDeleteThe humans involved in health care provision have so far shown a great reluctance to spend a lot of money on fancy IT systems - unlike the humans involved in bureaucracies who appear to love wasting money on such nonsense.
I have no problem with sending computable data as well when it is simple, available, and adds value. I would go so far as to say that in the case of pathology data, the time has come to apply some regulation to the "market" - and HL-7 v2.x is fine as far as I am concerned.
pdf is ubiquitous - anyone who can create any document at all these days can create a pdf. It will not require everyone who wishes to send a document to a GP or other healthcare provider (including potentially patients) to pay someone for a CDA capable system.
I think a very good business case for the required ubiquitous basic identity management infrastructure and authentication (what NeHTA call the IHI, HPII and HPIO and NASH) could be established on the basis of allowing the right human to read the right pdf at the right time. The business case would be even stronger if we could somehow ensure that similar simple options are available for the identity management services themselves.
And of course we need to make sure that every end point system deployed is capable of storing and displaying the documents. In this day and age, it is possible to send via email an arbitrary document that can be read using an appropriate reader selected by the user. The MIME approach used in email seems to work for this - we need not restrict ourselves to pdf. That way, if someone comes up with an HL-7 v2.x reader application or a CDA reader application then they can be activated from the desktop applications as well.
What is wrong with using the workable solutions that have evolved on the internet?
Valid CDA documents HAVE to contain a human-readable Text Sections. In total contrast there is nothing in any of the HL7 v2 messaging standards that requires any part of the message to be directly readable and any HTML that happens to be there is likely to related to an enclosed document, rather than the entire message.
ReplyDeleteXHTML is a workable solution that has evolved on the internet, HL7 2x is not.
Those really paying attention to what is going on in the Software Industry at large might have realised that HTML v5 is highly likely to become THE Presentation Layer standard - it is multi-media, cross-platform and non-proprietary. PDF is neither an open, or an internet, standard.
If the E-Health community in Australia really thinks that HL7 2.3.1 messages with embedded documents (PDF, RTF, XML, DOC, TXT, etc) is the way forward for E-Referral and E-Discharge Messages, then be prepared to be viewed as second-raters in this field.
Dear residential aged care facility,
ReplyDeleteWe have attached a PDF discharge summary from the recent visit of Mrs. Bloggs to our fine hospital.
She is doing well but you will see that we have significantly altered her medications. As this discharge is only readable by humans, we suggest you print it out onto a piece of paper. When the locum GP comes, he can hand transcribe the medication list onto a paper medication chart, which you can then fax to the pharmacy.
We have also sent this PDF document to her main GP who can also retype her medications into his system. We would suggest the use of cut & paste but of course most GP systems don't enter medications this way.
In the meantime, we hope none of your staff have been confused by the use of generic names in our human readable discharge summary, and that you have manually checked the discharge medications for duplicates, and for interactions against your more accurate list of allergies held in your clinical records. You will also note some of Mrs Bloggs important test results are included - we hope you can find the time to retype these into your clinical systems.
Sincerely
(Cheap) Hospital
Dear cheap hospital,
ReplyDeleteThanks you for sending us the document in electronic form, it is certainly more convenient than the faxes we were receiving last week.
Now that you have the ability and confidence to send us secure electronic formatted data could I direct you attention to an approach that may help both of us?
Providing you are willing to change your clinical systems, retrain your staff, take up the Snomed terminology and implement the appropriate codesets for medications (we currently use a home grown internal codeset that we are happy to share with you but are looking at a project to implement the Australia Medicines Terminology when we can find a donor willing to support the not insignificant cost of change) you could send us data using the HL-7 V3 CDA Discharge Summary standard and save us a lot of work.
We will leave it up to you to make the business case for this to your board of management.
Best regards, and congratulations on the progress to date,
residential aged care facility
Anonymous wrong said:
ReplyDelete"PDF is neither an open, or an internet, standard."
But....
"Originally a proprietary format, PDF was officially released as an open standard on July 1, 2008, and published by the International Organization for Standardization as ISO/IEC 32000-1:2008.[6][1]"
http://en.wikipedia.org/wiki/Portable_Document_Format
The "internet" has nothing to do with content standards.
Well actually, I am more interested in providing workable systems that are available right now at minimum cost - including the cost of change - than not being seen to be "second rate". In fact second rate would be an advance from where I am sitting. pdf is an effective standard (yes it does have a standards base, thanks for the pointer) that works very successfully right now for the purpose described - displaying information to a clinician or a patient. It is both more flexible and more broadly implemented than the RTF that is the current de-facto standard implemented within most GP desktop systems. It is more highly standardised as well. Ever tried to edit an MD3 template in Word? It is also a lot easier to implement right now than HL-7 V3. But anyway - why restrict ourselves to any particular format? A rich toolset for managing and displaying arbitrary documents using external viewers is built into most development environments.
ReplyDeleteWhen it comes to the presentation layer, "highly likely to become" does not cut it. Even so, why restrict ourselves to any particular format? The "reader" for HTMLv5 will be a web browser (some are already capable). The only restrictions are practical - if you are going to send someone some data then you should at least try and choose a format that they can assimilate and display - no matter what the "standards" say. This means that there should be a heavy bias towards ubiquitous formats such as pdf. In certain applications, such as path lab to GP, perhaps some additional content standards could be applicable. It would be desirable to encourage the development and deployment of content standards such as HL-7 V3 CDA Discharge Summaries, but we have to start somewhere.
Far more important is the ability to identify the people involved and securely transfer (I argue an arbitrary) blob of data with enough contextual information so that the end point application has some hints as to how to display it.
The argument of HL-7 V3 vs HL-7 v2 is completely moot until we can actually get data from A to B about C, knowing who A, B and C are with some confidence. We haven't even begun to talk about the other problems that need to be resolved such as agreed terminology - and don't say Snomed is the solution because I already know this. Try telling that to the developers of the end point software and to the governments who will suddenly be faced with demands for compensation for the costs involved in transitioning from where we are now to a standard terminology.
Let's take bite sized pieces. Being able to send, receive and display documents is a good starting point. Let's not try and boil the ocean. And while we are doing this, let's remember that the world is continually changing so we had better not settle on something that will tie us down into one particular approach. Let's look at the minimum required standards to get started, get the information flowing for the people who need to read it then let the various content standards fight it out in the real world rather than in the offices of bureaucrats and academics.
btw I do realise the massive investment and change that would be required to have hospitals send proper coded CDA discharge summaries. So if PDFs need to be the interim on the way to that then sure, lets be pragmatic. But I would be despondent if everyone thought that we could stop there because humans are the ones providing the care.
ReplyDeleteSure, they provide the care, but they will expect a basic level of computing functionality
to make their interactions with the computer
seamless (e.g. easily move medication data from one document into a medication chart, merge lists of allergies recorded at two different facilities etc) and sending ONLY human readable text cripples my ability as a computer programmer to provide that functionality.
So if the board of a hospital needs funding to implement CDA, or an RACF vendor needs funding to adopt the AMT - quite frankly I would prefer money be spent on that then pissed away on some dream for a PCEHR.
"So if the board of a hospital needs funding to implement CDA, or an RACF vendor needs funding to adopt the AMT - quite frankly I would prefer money be spent on that then pissed away on some dream for a PCEHR."
ReplyDeleteAmen to that!
David
But first, let's get something happening so we know more about the required architectures and document contents. At the moment we are guessing and I contend that real practical answers will only emerge once people are able to share human readable documents and identify the bits that they would like to not have to cut and paste. Of course, this is a gross simplification of the situation. Some of the answers are obvious and should be relatively straightforward with a little bit of regulation (like pathology) and some are clearly highly desirable but extremely difficult to achieve - like medications.
ReplyDeleteLet's put the building blocks in place - if the admittedly limited and limiting notion of a PCEHR will assist with this then I am all for it. I am still waiting to see what the process for implementing the PCEHR will look like so I cannot say whether it will help or hinder the overall effort.
I would not piss any money up against the wall on large scale rollouts of CDA until I am certain that I see a clear, concise and well resourced plan for rolling out the infrastructure required to share arbitrary data securely and reliably between A and B where A and B are practitioners and consumers - regardless of their locations and organisations. I take it as a given that we need to identify the subject of the data as well.
We have spent (and continue to spend) far too much time arguing over content standards and not enough on the fundamental enabling infrastructure.
The likes of Healthlink and Argus already provide the infrastucture to enable E-Referral and E-Discharge summaries to be sent to and from Primary and Secondary Care providers. The problem is that these private sector message providers are, quite understandably, more interested in increasing their ROI on outdated standards - such as HL7 2.3.1 - than implementing better ones.
ReplyDeleteI'm afraid Healthlink and Argus are taking advantage of the closed and outdated GP desktop systems. The "standard messages" they use are actually completely irrelevant if the information they are handling cannot be dealt with in any sensible way by the endpoint systems they are connecting. They would not be so attractive if these systems were open enough to allow document sending and receiving via a well described API and there was a universal web based infrastructure for identity management, security and authentication. For better or worse, GP systems (and all the other health related systems in existence) are part of the infrastructure that we all have to deal with. Adapters and middleware could add value by assisting us to deal with legacy systems, but only if they are adapting to some common shared infrastructure.
ReplyDeleteWe need open and transparent transport, security and identity management standards to be widely deployed using the internet and without transaction costs. This is technically trivial. We can do it with email for example. Security and authentication present an easily solved problem - it just requires someone to set the ground rules and decide on an appropriate standards based approach. The technologies are well understood and widely deployed in other domains.
Referring right back to first anonymous comment, we need the end point systems to start behaving like they are part of an ecosystem and at least (as a starting point) able to participate in the identity management services and to send, receive, and display documents in well understood and ubiquitously deployed formats such as pdf. Other formats would be welcome providing they actually add value and are not too expensive to implement. Argus and Healthlink do not provide an effective solution to this fundamental problem.
The assumption that HL7 V2 is "outdated" or that CDA is "better" needs to be challenged.
ReplyDeleteHL7 V2 is the mostly widely deployed eHealth standard in the world and it works. I struggle to find any evidence that CDA is better, it might be trendy but thats hardly a reason to choose it.
We need better support for HL7 v2 as the lab data is going to be in that format just about forever. Its hardly as if CDA is going to replace it in the lab arena. CDA itself is in transition to CDA R3 and there are new datatypes to come so why not wait until thats done and working.
Building on the base of HL7 v2 is so sensible that its unlikely Nehta would go down that path. Doing the opposite to what Nehta says is as good a path as any to follow, that should be our eHealth plan. Australia has a history of repeating the mistakes that the UK and US have just identified. "Fear of being seen to use an outdated Standard" is exactly the mentality that encourages us to repeat the stupid mistakes of others. Its time to adopt and enhance whats working while awaiting other things to mature to a point that they are clearly the way to go. Investment in our V2 infrastructure will not be wasted as Lab data will continue to use it.
"The likes of Healthlink and Argus already provide the infrastucture to enable E-Referral and E-Discharge summaries to be sent to and from Primary and Secondary Care providers. The problem is that these private sector message providers are, quite understandably, more interested in increasing their ROI on outdated standards - such as HL7 2.3.1 - than implementing better ones."
ReplyDeleteHold on there tiger.
Argus and Healthlink etc are message transporters. The content standards are a matter for the clinical systems at each end. The more involvement secure message transporters have in fiddling around with message content, the less motivation clinical software vendors have to get their stuff aligned with whatever standard you think is fit for purpose.
I also note both Healthlink and Argus and a stack of other vendors were actively involved in the development of the SMD specifications, despite not being remunerated in any way for their time or IP. As it turns out, all were lied to throughout the process about the status of NASH ...the 5 years in the making, multi-million dollar tender document (and still flawed!).
For their trouble, NEHTA leveraged the vendors' efforts and conspired with the NT Govt to eradicate Argus from the territory. And watch this space as folks in the NT have very sexy fingers it seems.
"I'm afraid Healthlink and Argus are taking advantage of the closed and outdated GP desktop systems."
ReplyDeleteI'm sorry but you're talking garbage.
All GP desktop software (as a minimum) utilise the perhaps primitive - but undeniably open - "drop box" method of importing clinical messages. They don't care how the messages get to the dropbox...just that they are there and in a format that the clinical software can interpret.
Up until the Healthlink/HCN collaboration, MD was the only product with any discernible market share that couldn't dump out a HL7 message.
By what measure are Australia's GP systems outdated?
"The "standard messages" they use are actually completely irrelevant if the information they are handling cannot be dealt with in any sensible way by the endpoint systems they are connecting."
Yeah, this is the crux of the issue - content creation and importation is currently deficient...secure message transport is pretty reliable in comparison.
"They would not be so attractive if these systems were open enough to allow document sending and receiving via a well described API and there was a universal web based infrastructure for identity management, security and authentication."
As above - drop boxes are the current API. The well defined part is "stick your message in this folder in a format we can understand". SMD could have tightened this up considerably, but NEHTA really screwed the pooch on this one with the NASH debacle.
To me they are closed and outdated if they do not support the workflows of their users effectively. If they cannot manage their own messaging - the technologies are mature and easy to implement and there are code libraries everywhere.
ReplyDeleteThey are closed and outdated if they do not provide well-documented facilities (i.e an API) that will allow arbitrary information from their database to be selected and incorporated into outgoing communications - with a default to allow creation and sending of text reports in pdf form and a programming interface to allow formatting into arbitrary message formats - either by the application itself or by helper applications.
They are closed and outdated if they cannot receive an arbitrary binary file wrapped in a minimal header containing identity information and payload content identification, and associate this with a record within their database. If they recognise a message format in the payload then they can parse it and incorporate it into their data and if they don't they save it, use the payload identification to associate the content with an appropriate reader application.
They are closed and outdated if they are not able to provide, as basic functionality, flexible and open tools for communication that GPs need in order to do their jobs effectively.
A good article on the advantages of CDA - for sending Pathology and Radiology Reports - by Graham Grieve (possibly Australia's foremost expert on HL7) can be found in last November's issue of Pluse+IT. I wouldn't be too surprised if HL7 2x does remain the message standard in this area for quite some time, after all it is a significant improvement on PIT, but I doubt many of those who have bothered to learn CDA will agree that HL7 2x is now the best choice.
ReplyDeleteSome of the above posters are rather naive about the role played by the message service providers. Both Argus and Healthlink parse, validate, and reject messages before transmission,which is really the job of the receiving PMS, and Argus do not transmit any HL7 v2x acknowledgement messages sent by a PMS - which is a complete nonsense.