The following very fresh little tit-bit has just darkened my door.
I am sure the cover page will be of interest.
Much more fun however is the Draft Concept of Operations Diagram.
Having a close look (click to enlarge) it is clear that the recent blogs have been pretty close to the mark.
As predicted we have an indexing service, and access control service and a presentation service.
What is also interesting are the areas marked Lead, Release 1(R1) and Release 2 (R2).
It becomes clear that by July, 2012 that the lead and R1 is hoped to be operational - just - and that R2 will follow a good deal later and incrementally.
It is worth noting the Personal Health Records don’t happen until R2 and that there will be precious little that most who register for a PCEHR will access for a good few years.
Also note that NEHTA, like a dog with a bone, still has a Shared EHR - despite all the issues we have explored regarding this recently.
For years after 2012 the act of registration will be just that and nothing more. This is just an enormous hoax being played on consumers under political pressure.
My view, discussions on all this should be happening in public and be exposed to decent scrutiny.
It is just astonishing that this 80 page document devotes only a page or two to international experiences in this area. They are really determined to replicate the mistakes the rest of the world has made it would seem!
David.
33 comments:
How many years, how many of my tax dollars, and how little accountability has it taken NEHTA to come up with this?
I have believed in eHealth in Australia. This leaves me devastated.
David,
Anyone looking to submit a lead implementation site proposal had to sign a secrecy agreement with the commonwealth in order to get access to this document. You can look at the lead implementation site grants documents to see how onerous those requirements were. The person who sent this to you could face legal sanctions.
Sadly, I think the main reason the secrecy agreement had to be signed was to prevent it ending up on your blog where it would likely lead to significant criticism. Justified criticism.
The approach envisaged in the concept of operations delivers zero value to patients - they will only be able to register for 'access' at some future time.
It delivers zero value for clinicians who will have to wait years for any meaningful data to trickle up past the layers of complexity that NEHTA is laying out.
It's a fantastical notion that's been tried and failed many times. One of the most striking contrasts at the event last week was this: We heard NEHTA, DOHA (along with Industry, Medical, Consumer and Health Informatics people, by the way - it's a collective delusion) people say how 'we can build it' in 18 months. Then we heard how in Hong Kong and Denmark (two of the leading sites for eHealth), it took more than 15 years to reach a stage that only roughly equates to where the NEHTA Concept of Operations says we will be in 18 months.
There are other approaches and ways to deliver real value but nobody is allowed to discuss it - that was apparent at the conference last week.
NEHTA is trying to build credibility by silencing comment. Fortunately, DOHA last week put NEHTA in it's place as merely a specification developer who will not have a role in building or operating the national program.
The question is what DOHA will do with this new courage? My concern is that they will continue the closed, introspective, selectively mute and deaf process that has characterised NEHTA for the past five years.
In my view, NEHTA is terminally incapable of navigating this problem. DOHA hopefully will find better advisors
"Anyone looking to submit a lead implementation site proposal had to sign a secrecy agreement with the commonwealth in order to get access to this document. You can look at the lead implementation site grants documents to see how onerous those requirements were. The person who sent this to you could face legal sanctions."
And anyone who believes they should behave like this as far as suppression of discussion and scrutiny please raise their hand!
This is our money they are spending in secret. Just dreadful as far as I am concerned!
David.
This is even more centralised that I feared.
This is even less centralised than I feared.
This is more confused than I had hoped. I'm starting to feel misled - perhaps the new Australian Consumer Law could help here?
Its interesting that they do not even mention HL7V2 but say pathology will be part of it. Its as if they can't utter those words despite the reality that there is no CDA in Australia and all the data is in HL7V2 format.
There are clearly ideology driven and there is not an ounce of pragmatism in NEHTA. Its time for the ivory tower architects to fall on their swords before they bring down the whole local industry. They are clueless and deluded and a danger to the health of the Australian IT industry.
To give these clueless people the money to force people into submission against their will is evil. The industry would be better off without this funding and NEHTA and would progress the cause more effectively on their own. This is a perfect example of the damage done by big government. Its worse than pink bats or school halls but because its IT its harder to see the waste or the fires, but should they be allowed to continue they will eventually become obvious!
Didn't I hear that they are defining their "own" CDA, and a series of unique Australian Standards?
Well I don't think this architecture carries many surprises. It is a typical Service Oriented Architecture that you'd find in many publications on distributed enterprise systems. Very ambitious for a national framework, and even more so in healthcare. It creates a new world by mainly ignoring the existing one. This is by far the biggest danger in the approach. The heterogeneity of existing systems, and the information in those existing systems is immense. I couldn't see this sort of infrastructure being in place on a national scale in less than 10 years. Who will make this happen? How much will it cost?
Is this really a service orientated architecture? It doesn't appear to conform to the principles of service orientated design (www.soaprinciples.com). If anything, this appears to be a messaging driven communications bus which enables interoperation and intercommunication between multiple distributed autonomous systems. As Eric says: there is immense heterogeneity of health IT systems - and enabling these to interoperate is an enormous undertaking. This architecture seems to ignore that, and makes a difficult job almost impossible.
The diagram describes a HOW, please will someone tell me WHAT we are trying to build here?
My understanding of a "Concept of Operations" is the IEEE Standard 1362 from 1998 which I contributed to. As defined the purpose of a CONOPS is: "... a user-oriented document that describes system characteristics for a proposed system from the users' viewpoint. The ConOps document is used to communicate the overall quantitative and qualitative system characteristics to the user, buyer, developer and other organisational elements (e.g. training, facilities, staffing and maintenance). It is used to describe the user organization(s), mission(s) and organizational objectives from an integrated systems point of view.".
David - does the document do that?
On what I have been told and browsed - not exactly!
David.
This famous quote from George Santayana sums up where we are:
"Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it."
NEHTA is and always has been in a state in infancy and can't progress because they have rejected what works without even bothering to understand it. If this is indicative of the state of our government in general we are in deep trouble!
"Vision without action is a daydream. Action without vision is a nightmare."
Japanese Proverb
Strange, how badly beaurocrats can get something wrong. Because of my background in pharmacy, computer science and general practice I have been tinkering with e-health for a decade.
In discussion with interested colleagues, I now download a complete history onto the patient's USB stick whenever they want. So they have their record and control over it as well.
I think this approach has benefit, because as the patient's GP I am a repository for the majority of their records, summaries, consultant opinions and investigation results.
It's cheap - $15.00 vs $20,000,000.00 .
And the patients retain control over who sees it.
The record is downloaded in html format and is viewed easily in any browser.
Are there any thoughts from this group of interested colleagues?
Thanks,
Dr Julian Fidge
GP
Wangaratta
Hi Julian,
having results in a digital display format is good, but those results cannot be imported into another system. eHealth is trying to allow free movement of data in a lossless way and this requires standards that support atomic data that is widely supported. Then the data can be merged into another system and updated.
I can export a patients results as HL7 to a USB, but in many cases the patient is not available to transport the results and people should be rightly concerned about plugging a unknown usb stick into their computer as it could have anything on it.
In the end we come back to standards and compliance with standards. We have standards but the compliance is poor and this is the big issue. The current plan involves throwing everything we have away and starting again from scratch when their is a 2 year timetable, which is a perplexing strategy.
Sadly, you don't know the half of it! We've been told to put our work on hold because NEHTA is building another more detailed architecture on the PCEHR that we'll have to fit into somehow, but that won't be available until the middle of next year.
Don't hold out much hope for the Politically Correct Electronic Health Record (PCEHR) from the Never Ever Have To deliver Anything(NEHTA) organisation
Maybe we need facebook to provide a health data repository, have a healthy privacy debate about how risky it is to have all your health data with one private entity, and motivate some open source wizards to come up with some self/friend hosted secure alternative like Diaspora.
Julian / Andrew -
Surely instead of HTML you could use XML, then you have a structured form which *could* be imported. Even better if it was an actual CDA underneath ;)
Hi Anonymous,
xml is a way of encoding data into text, but says nothing about the structure of the data. To allow data to be fluid you have to define the structure which is what HL7 is all about. HL7v2 can be encoded in xml and CDA generally is. Attempts to come up with a simple schema work for simple things but fail with real world use cases and you end up re-inventing HL7.
The reality is that HL7V2 can handle the use cases and is implemented widely and building on what we have is the smart way to progress. Unfortunately we don't seem to have done anything the smart way for the last 10 years and there has been no progress. This urge to start from scratch keeps popping up, but has clearly failed again and again. The merry-go round is clearly still spinning however.
.. and in Aus we do have v2.5XML don't we?
Yes we can have v2.5xml but despite supporting it I have never seen a HL7V2 xml message used in the wild.
The classic vertical bar encoding is everywhere and is very compact and efficient and is what is used.
"Anyone looking to submit a lead implementation site proposal had to sign a secrecy agreement with the commonwealth in order to get access to this document. You can look at the lead implementation site grants documents to see how onerous those requirements were."
The "DRAFT Tripartite Funding Agreement" reads like a document that is focussed on assuring that any sort of progress will be hindered! Despite the fact that it runs to 49 pages it is further complicated by trying to write in NeHTA involvement and the oversight of the Commonwealth.
Any suggestions on how to sensibly navigate and/or re-negotiate the "Deed of Agreement"?
Sorry, its 'Guvmint'! They just love this stuff to maximise your risk and minimise theirs. Anyone who bothers responding to this I can assure you will regret it.
As the saying goes 'the only thing worse than loosing a government contract is winning it!'
This could be a career ending and company destroying experience for many. Think carefully if it is a risk worth taking - any yes I know the carrot is huge!
David.
Thank you for the learned comments. Pearls, all of them.
If we were to take one issue at a time -
I understand the USB stick (or whatever medium) poses a risk or carrying a virus, etc. But in order to tranfer data electronically we have to let that data in anyway, so why is a USB or CD or DVD more risky than any other method of importing data?
I already load CDs from radiologists quite cheerfully, if naively, and haven't come to any harm yet.
And couldn't the risk posed by having a patient carry their own health record be mitigated with virus-checking software?
My second point - that of patient control over their own record by handling their own USB or CD or DVD - did not appear to cop to much flak.
Observers made it clear that my third point, - the use of html to store the record - stops the record being imported. It is basically an electronic hard copy. I have the facility in MD to export in xml format, which can be imported by other MD users and anyone who has written a tool for it. But it was clear that HL7 is the way to go for such a health record to be of use universally.
It seems to me then the USB/CD/DVD given to the patient is still viable. We just have to tweak existing software to import and export HL7 so the health record in the patient's control is universally accessible.
When the patient is not available to transport, we could presumably send the exported HL7 file as an attachment via email or secure messaging.
Can we get the feds to pay the software providers to write a tool or change their programs so that the record is stored and exported in HL7 format?
If so, will that provide a workable solution?
It is very refreshing to read an informed discussion.
Julian
Julian,
I know this is diverging somewhat from the topic of the post, but it is a really, really important issue that you raise. Unfortunately, it is far more likely that health records exported in XML from Medical Director or from other GP practice software in their own proprietary XML formats are far more likely to be successfully and more easily imported into other systems than if they were translated into HL7, either version 2 or version 3 based HL7.
At this point in time, we have no standardised way in HL7 to represent the content of electronic health records. In fact, it is not yet even possible to provide developers of clinical information systems of any kind a standardised way in, either HL7 v2 or HL7 v3, to represent fundamental concepts such as blood pressure (systolic and diastolic) values.
This may seem surprising to you, and perhaps other readers of this blog. But it is a sad fact of life. I wish it were not the case. Health information interchange of the type you propose may be feasible sometime in the distant future, but certainly not today.
It is also very unfortunate, as David continues to point out, that the Australian government hopes to build a sophisticated PCEHR system in 18 months based on infrastructure we simply can't yet provide.
hmm. $466m 466 hospital beds, fully funded for 12 months. Surely, money spent on the provision of clinical services now for the public good, has to be better than all this futuristic fantasy? Is there any evidence that throwing buucket loads of money at implementing IT (not to mention the $$$ spent testing and refining and retraining of workflows) will result in any MEASURABLE improvements in the delivery of safe, affordable, efficient health-care?
That may be $466 million this year, but next year? And the year after? And the year after that?
Yes, the PCEHR as it was originally announced will never happen, but at least the funding being splashed around will result in some identifiable code and change management malarkey that will deliver efficiency benefits across the health system. The payoff, for example, for improvements in to the way clinical documents are handled will accrue over literally decades...the sooner it happens the sooner the benefits realisation phase (to use some wanky vernacular that must have rubbed off reading recent govt. tenders) will commence.
I had heard that a quick calculation of how much has been spent by NEHTA internally since their inception would have funded two inpatient hospital wards for the same period. I would suggest that this would have caused much better patient outcomes than anything else they have done... which arguably will never help any of my patients.
This is an interesting thread, and Andrew, Hercules, Eric, all excellent comments.
Andrew as an Enterprise Integration Architect of almost 20 years I can see your understanding of XLS / HL7 are spot on.
However I am amazed that the Healthcare world has not come up with a solution based on these technolgies as has Shipping/Logistics. Banking/Finance etc.
Is the latest HL7 using XML/CDA?
How about openEHR?
Can you point me to the latest advances in moving eHealth towards a standard for EHR interoperability?
I would then like to register and try to contribute as much as I can, as My BG is in just this - Integration, Message Brokers, Decentralised Hubs, and SOA's.
While it is common for people from other parts of the IT industry to look for an xml solution I am not sure that xml solves much.
HL7V2 predates xml and its very terse and efficient and this can be an advantage wrt storage and latency and the data is much better being machine readable rather than human readable. HL7V2 is at least text and can be read by humans but I almost never do that.
The bigger problem is the modelling required once the encoding issue is dealt with and in reality this is 99% of the problem. HL7V3 was started in 1992 and HL7V3 messaging would have to be called a failure after 18 years of effort with no results. However HL7V2 continues to grow and prosper and can be enhanced to carry high level semantics in a backward compatible way and this is the path I still think is the most likely to succeed.
CDA is xml but offers little advantage over good HL7V2. You may not need to write a xml parser but the advantages mostly finish there and you just get a document and no messaging semantics, so it cannot replace V2 alone!!!
There is nothing that can't be done with HL7V2 done well and I think it’s the tortoise in this race. Its functionality is quite mature in many areas and combining it with Standards based Archetypes leads to a very solid solution that is backward compatible. The issue is that new people tend to read the V3 specs and ignore V2, and then deride it out of ignorance. It’s a solution that keeps growing while V3 is the playground of Ivory Tower Architects with virtually no implementations of V3 messaging that actually work on any scale.
What very very interesting comments by Andrew McIntyre said... Tuesday, December 28, 2010 12:35:00 PM.
Hopefully they will be widely read and hopefully others equally well informed will support or counter these views.
I am not deeply enough involved in the issue to enter the argument but as a senior manager in health and heavily involved in setting directions and strategies for eHealth nationally I have to make my judgment calls on the advice of my 'techo' experts who each have their own biases and differences of opinion.
Having said that as I contemplate Andrew's comments I ask myself (a) will we ever get 'there'? (b) why aren't we drawing more on the expertise of people like Andrew with years of experience at the coalface? (c) how can I rely on the advice I am given by so-called 'experts' in my organisation who are relatively new to the field? (d) how can I better direct the large sums of money available to get better results and outcomes and working interoperable systems in the field?
Questions like these are at the forefront of my mind every day of the week - in short - are we approaching the problem the right way or should we be doing things differently and in what way?
Thank you Andrew for your very interesting comments.
Anonymous of Friday, December 31 2010 9:12am asks a number of good questions at the forefront of his/her mind every day of the week.
If similar questions are reflective of the e-health management community more broadly, then I would contend that we have the wrong people making such decisions. Such decisions require a deep technical knowledge and considerable engineering knowledge and experience.
I think the principal reason why more isn't made of the experiences and knowledge of the likes of Andrew McIntyre is due to the closed nature of NEHTA. Instead of providing a forum where important technical approaches could be debated and evolve, we have had a situation, initiated under Reinecke, but continued under the present regime, whereby parts of the e-health infrastructure are developed behind closed doors and announced by decree, in the absence of a comprehensive and coherent strategy that can address all the missing pieces. And without a realistic timeframe and strategy for adoption.
There is clearly a shortage of technical skills in e-health in Australia and very little money is going into addressing this skills shortage.
As to the specific issue Andrew raises in support of HL7 v2, I would contend that both v2 and v3 have fundamental shortcomings that inhibit interoperability. In both cases, they rely extensively on external vocabularies to label nearly every data node in message or document. In the Australian messaging standards that have been produced to date, the vocabularies have not been satisfactorily agreed; the vocabularies that have been mandated (e.g. LOINC and SNOMED CT) have major shortcomings; there has been no adequate distribution mechanism established for incorporating and updating these in clinical systems; there has been no adequate conformance and accreditation regime put in place; very little attention has been given to developing agreed clinical models, to the point that there is NO STANDARD way of even representing blood pressure in HL7 v2 or V3.
In short, I think we should be doing things differently. And I, too, would welcome further views on the issues Andrew raises.
HL7 V2 and HL7 V3 are both open to significant interpretation as evidenced by hospitals representing the same information in different ways depending upon local systems and practices. IHE have made an attempt to restrict the possible ways of representing information in HL7 and to standardise message exchanges by publishing technical profiles. Not there yet but a step in the right direction.
The holy grail of all this is for software vendors to agree on a universal standard which will greatly reduce the interoperability challenges.
Post a Comment