March 30th, 2010 andrew
National Health IT programs do not have a good record of success in general, and Australia has been a good example of that to date. I don’t think anything is about to change.
The reasons for this will no doubt be well understood in time, as history looks back and shakes its head in dismay at the wasted resources and opportunities. Its hard to pinpoint the reasons for failure until you have success to contrast it with. I think a large part of the problem is the top down approach to a problem that can only be solved bottom up. By many measures Australia has been a leader in eHealth to date, but I don’t think any of that can be attributed to government policy or support as its mostly been bottom up. Certainly the National eHealth Programs of the past have failed to progress the situation and have in many ways just distorted the market for the worse.
While some will say the issue is “Change Management”, I think this is wrong. To have change management you need to have a change worth implementing and to date the quality has not been there to justify change. The quality needs to be in the software and eHealth is a complex beast to tame. To progress it we need to have the foundations to build on and currently they are sitting on swamp. Netha appears determined to adopt the tunnel vision of its “Stakeholders” ie. The state health departments and ignore the bigger picture of the international markets and standards bodies. Despite ample evidence that the existing infrastructure is cobbled together and working in the most fragile manner conceivable they want to march on and implement national programs without any compliance agenda on the horizon for at least 2 years. Building anything on the current infrastructure without a resolute compliance program is a recipe for disaster.
Australia currently has good penetration of HL7 V2 messaging, but the quality is patchy and the interoperability extremely fragile. Any change to messages results in failures and in effect we are locked into a situation where only a few systems can handle compliant data. This is interconnectivity and is a long way from interoperability, its a road to nowhere and in reality the known errors in existing lab messages cannot be corrected because of the fear of breaking existing systems. Despite Australia having compliance testing available there appears to be a complete lack of understanding of its importance by Nehta. Rather than underpin the cracking foundations before trying to renovate the building Nehta is determined to add another 3 stories to the building. The earthquake in Haiti demonstrated the dangers of a city built without adequate building regulation. Nehta’s plans will result in major loss of life at the first sign of a tremor, even if they manage to build something (which they have failed to do to date).
Interconnectivity without interoperability is a recipe for disaster and this appears to be the agenda. Delivery at all costs appears to be the political motivation and I think its time to reject the short term political goals and try and attack basic compliance and quality now. The software term “Design by Contract” was never meant to mean a business contract, but a compliance contract. Nehta appears not to get this and wants to substitute “contracts to deliver a business plan” for “contracts to comply with standards”. Computers are quite bad at being politically correct and will reject business plans that lack credibility at the binary level.
The real issue in eHealth is a lack of quality, and subsequently a lack of interoperability and safety. There are fundamental engineering deficiencies in the real world and a lack of realization that only standards, and good compliance with standards can fix the flawed foundations. Foundations are not sexy, but getting the structure out of the ground is always the biggest hurdle on a building project. To improve the situation we need a focus on good software engineering practices and in the world of complex systems that means testing and more testing. The reality is that HL7 V2 is going to be around for many years to come and rather that march on with grand plans the priority needs to be getting a compliance program for existing standards up and running now. Moving to something new is an expensive diversion that will make the problem worse, not better. Someone needs to stand up and stop claiming they will deliver the 10 story masterpiece “next year” and start work on a compliance program for what is already in use. We need some solid foundations or the Haiti style devastation of eHealth will surely descend upon us within a few years.
The Nehta plan, as it stands will deliver fragile single purpose interconnectivity with little or no interoperability. Its time we turned our existing interconnectivity into interoperability by a deliberate compliance agenda. Once thats done we will be out of the ground and ready to do some real work. As it stands they are on a road to nowhere. We have been down that road and we know where it leads.
Posted in DECISION SUPPORT, EHR, HL7, MESSAGING, STANDARDS | No Comments »
December 28th, 2008 andrew
Every now and again someone decides that health IT is obviously doing something wrong and they are going to fix it. This is a familiar call, often made by well meaning bureaucracy and its part of the problem and not part of the solution.
Health IT is hard and its become much harder with the involvement of well meaning bureaucracy. They often regard (and even refer to!) health it people as a bunch of “nerds”. If only there were more nerds and less bureaucracy we may be further ahead. Yes it is possible for the banks to have ATM machines working in a global sense and interoperating but they are only adding and subtracting figures from a balance and tolerate a fair bit of fraud as part of the cost. I am sure it all we wanted to do was maintain long term records of patients blood pressure and have this interoperate, with low levels of security it could be done quite easily. If we did this for the same transaction fees as the banks charge for ATM transfers there would also be a funding model!
Health IT is hard because the problem that we are trying to solve is huge, changes rapidly and cannot be modelled completely at any one point in time. It also rightly needs to be done with a very high level of security and even low levels of fraud and security breaches are intolerable and cannot be assigned to an “acceptable level of fraud” – which is what happens in the banking industry. It is also either starved of funds or funds are wasted in large treasure chest sized amounts by giving it to the large corporate software pirates who conduct yet another study or review the “state of the art” and sail on to their next victim.
Meanwhile standards bodies try and pull together workable standards with volunteer labour and laughable budgets. The standards meeting have also been invaded by bureaucracy and modellers with the “nerds” having been left at home.
What health IT needs is an army of smart technical people (ie nerds) and smart clinical people who can get together and actually try and pull together the technologies needed to make it work in the real world.
As the guardian of a million lines of very technical HL7 orientated source code I am acutely aware of the difficulty of the problem. Medical-Objects has some top class technical brains at its disposal but you know that even with someone who is exceptional you have to try and partition their problem space off to a small subsection and do a lot of hand holding if you want any useful work done. It takes years to get a top class technical person to see the whole picture as it’s all interlinked. They may be a database/internet/user interface guru but to make it work together a lot of balls need to be in the air and aligned at the same time. Any model needs to be serialiseable in HL7, security and digital signatures/authorisation appear at all sorts of levels. The model has to support not only the HL7 model but also the Snomed-CT model and this model has to be addressable by the GELLO code in a standard way. In many cases the number of patient/records may be huge so performance issues are critical and it has to operate in a secure distributed fashion in software environments that are totally uncontrolled and often unreliable. No matter how well you model it it will have to go to systems that are quite basic so it needs to gracefully downgrade to a simple text document on demand. At some point a dicom image might appear so this needs to be supported as well. Finding people who can function over a landscape dotted with landmarks like HL7, Dicom, PKI, GELLO, SQL, XML, XML-Schema, SOAP, HTTP, HTML, RTF, SNOMED-CT, Archetypes, BNF, RDF etc is no small task. Then of course you have the clinical knowledge that is so vital to build systems that are actually useful. This clinical knowledge is changing and variable, and sometimes contradictory between institutions.
Meanwhile the bureaucracy is being wined and dined by the salesmen of the latest wizz bang technology and engaging well dressed consultants to come up with a plan… Working proven scalable technologies must be replaced by new unproven and less scalable technologies… Of course these plans fail, and the whole process restarts with a new bureaucracy who go through the same process yet another time.
Its time they actually looked at working Health IT technologies and tried to emulate them. Pathology has been delivering electronic results for over 10 years. The system would not cope if they did not. The quality is patchy but it works and there is lots of room for enhancements. This has been done without any significant government handouts. Australia has standards in place that could be enforced, but no one seems to have the balls to do it. If the government wants to throw money at it then they could reward the use of standards, standards that we know work and not some “almost ready” latest greatest thing that is unproven. It is impossible for the government bureaucracy to come up with their own new “standard” and possibly have it work, its just to hard to get it right until you have been doing it for 10 years and even then you get it right a little bit at a time. Organisations such as NEHTA need about 10 years to actually get their finger on the pulse and government can’t see that far ahead. They also need 10 years of actually trying to make it work rather than 10 years of whiteboard scribbling. They need to be highly concerned when “nerds” who are making some things work actually disagree with their plans and alas this is not the case! NEHTA needs to become a promoter and enabler of proven standards and a funder of standards work and true R&D, it cannot “solve” the problem on its own and unless they feel totally across all the acronyms above they should not be trying.
Posted in DECISION SUPPORT, EHR, GELLO, STANDARDS | No Comments »
February 17th, 2008 andrew
It seems that after spending over $300M trying to kick start eHeath we are going to have an eHeath plan! Seems to me like that is a very good idea and the question is why don’t we have one already and what should be in “it”.
It’s an eHeath plan drafted in 3 months and will last 5-10 years! Still doesn’t sound quite right to me but any plan is better than no plan. Unless something major is changed its likely to be formulated by people with more political clout than technical expertise so maybe some ideas from the trenches would help.
Firstly, we don’t want a grand plan as they usually fail. We want to put in place measures that get us to a point that a grand plan is a possibility. A grand centralised EHR will not work unless everyone is using standards for their every day eHeath dabblings. That’s where the plan should focus. Australia has widespread usage of HL7 V2 and thats what we should aim for, but at a better level of quality. HL7 V3 has some nice modelling but is is not ready for widespread usage yet and the NHS in the UK is pouring buckets of money into that pond so we should swim in the functioning pool. CDA is not really any advance on good V2 and while the xml might be easier to parse it has no support in the current primary care applications and should not be an immediate target because of this.
What we don’t have is good quality HL7. The labs produce it but the receivers are fragile and the lowest common denominator is limiting what we can do. We need to have certification of the HL7 produced and certification of the applications ability to consume it. If this was done correctly then the reliability and quality of our clinical messaging would soar. We already have AHML able to certify HL7 produced and test message sets to test on applications so its easily organised! The State Heath Departments should be forced to only spit out 100% pure AHML accredited HL7, its not safe to do anything else and I am sure it could be done give enough push.
We do need provider directories, but almost all the lab messaging uses Medicare provider numbers for this and it works well. The grand all singing and dancing provider directory is a way off so why not use something that just works. Medicare Australia need to loosen their grip on the monthly lists of provider numbers for this to work but I am sure this could happen with only a modicum of counselling.
We need standards that allow you to send an entire patient history in HL7 V2 including SNOMED-CT encoded concepts. The archetypes in V2 project has the ability to allow this but this project has been running on a shoestring. Standards Australia needs to have its eHealth budget lifted by about 10 times. Currently there is one 1/2 time person for all the eHeath standards! Projects like this should have a full time person on them. It can take 2 months to get a document edited. This is not a Standards Australia problem, but a lack of funding support issue and it needs to be fixed ASAP. Someone, who can read and write HL7 in their sleep needs to be employed full time doing examples and testing concepts. Currently this is done by volunteers at midnight the night before the meeting.
We do also need messaging of course, but we need good quality messages before this is actually useful. The most useful option here would be to produce a standard and mandate its use. Even producing a standard would help as at the moment the “Use WS-Security” is nowhere near enough detail! How could this be done, this one would take some bravery but throwing together 10 technical (Not political) experts from the companies involved for a week with the expectation of a draft standard at the end of a week is probably the best option. Once that is done you could legislate that the receivers paid for the service if you were really brave. Next issue a directive to HESA (Now inside Medicare) to issue a site certificate and Individual certificate to everyone with a provider number and do it every time a new number is issued. You would also insist on a certificate signing service so certificates could be generated onsite, maybe using a valid individual key to upload it for signing.
Now drugs, we need SNOMED-CT codes and they need to be in the PBS by the end of the year. They also need to be integrated into the SNOMED-CT hierarchy so we can use them for decision support. A ministerial to advise that this must be done by the end of 2008 is what’s required here. SNOMED-CT may not be perfect but expecting clinicians to take responsibility for patients with no viable decision support is just not fair. When we have this we can look at scripts as they are just HL7 orders.
Next we need some money for all this, Standards Australia just need a one line budget, but perhaps we could add a”e” in front of every consultation/script that was messaged using AHML accredited HL7 and Medicare could pay the doctor/lab/pharmacy a premium and link all future rebate increases to this. That would certainly make it happen and you would only pay for performance. Its pointless paying vendors big $ to implement “X” – it has not worked. Reward some rubber on the road.
Ok, there it is, a 30 minute eHeath plan. All it does is put some onus on people to do what they should have already done and throw away the idea of expensive central systems and replace that with some good solid tested code in the trenches. That’s what we need.
Posted in DECISION SUPPORT, EHR, HL7, MESSAGING, SNOMED, STANDARDS, Uncategorized | No Comments »
January 19th, 2008 andrew
Medical-Objects has spent the last 12 months refining its realtime HL7 messaging client. It has been an enormous effort to get this working smoothly when the environments it has to run in are so varied and often not well resourced with anyone with IT knowledge.
More recently we have been completing the Linux/OSX port of the client. We now know the differences in the threading and synchronization primates between Windows and these operating systems!
In the end however it will be worth it as it opens the door to a new type of eHealth where messaging becomes infrastructure and we start to see some real benefits for the effort. Most providers are impatient, usually for good reasons, and if you can’t match the fax for speed then its doesn’t work. When they have 30 minutes to sort out a complex patient and they need that X-ray report now and 30 minute store and forward delivery cycle just doesn’t cut it.
The other area is of course services. Once the messaging is in place queries for appointments and patient status updates become possible. The vast knowledge base that is out there also become reachable in an automated way. Software can act as an agent seeking out information without someone having to load up a browser, login and manually search. A world where machine readable decision support encoded with eg GLIF and GELLO is available on demand goes from science fiction to a matter of developing content. The use of message level encryption allows a level of authentication that we have not previously had and has the potential to cut red tape. Why can’t the software validate the patients authority script, download the latest guidelines and check on the patients address details in the background, while in another thread of execution it requests that patients past lab tests and X-ray reports. With real time messaging and good authentication it can, and it will.
Standards will play a bit role in this and at this point in Australia that means Certified HL7V2 messages, functioning as they were intended, as a messaging format. Other pieces we are using include the GELLO and GLIF specs along with Archetypes and this is built on top of some very simple REST methods.
Pulling it all together remains a challenge, but we are at the point where we know it works. Hopefully by the end of 2008 we will see some standardised messaging specs to create a level playing field in the messaging space, as the real value lies in what is built on top of this infrastructure.
Posted in DECISION SUPPORT, EHR, GELLO, GLIF, HL7 | No Comments »
March 11th, 2007 andrew
Archetypes – SNOMED-CT – HL7 – GELLO – GLIF
What are the boundaries between these important concepts and where and how do they fit together.
This is an important question, one we have been expending a lot of energy on and we have ended up with some ideas that we would like to share. We also have firm opinions!
Really the problem is that there is overlap, or in some cases “underlap”
HL7 V3 has terminology properties that conflict and create mismatch with SNOMED-CT. Its also very verbose and overloaded by Modelling, complexity and infrastructure issues. HL7 V2 in general does not, as apart from medications it has not really invaded the clinical data relationship space as yet. Its a blank slate with respect to clinical modelling, but quite a well proven and efficient blank slate!
Archetypes as pioneered by OpenEHR has conflict with SNOMED-CT – they try to be terminology neutral and in effect often also invade the Terminology space – as simple terminologies are semantically deficient and need their help. In reality SNOMED-CT relationships and grammar and Archetypes are in the same space and we would view them this way. Ideally the terminology should be able to create the relationships between data items that the archetypes currently create and in many areas SNOMED-CT already does this very well. Our somewhat provocative view is that Archetypes fill the gaps where the terminology is deficient, and with time will gradually fade as the relationships in SNOMED-CT become richer.
Archetypes also conflict with GELLO. Data validation and calculated values should be handled by a constraint language, and GELLO as a direct descendant of OCL fits this bill well. Having a specific “COUNT” node in an archetype should be replaced by some GELLO that can do basic addition.
What about high level decision support? To clinicians this is flow charts. Not dumb ones, but really smart flow charts that already knows whats excluded and whats contraindicated. Not that they can have the final say. Rules are made to be broken and often are for good reasons. GLIF (Guideline Interchange Format) does fit the bill well here – it represents decisions and flow charts very well and is designed to defer to GELLO for the actual computation.
What about the “Big” model – The HL7 V3 model at a high level is quite true to Medical Practice. Medical records really are a collection of observations about a Patient, some right some wrong, some in conflict with each other, that’s the real world.
So where do we see this fitting together now….
HL7 V2 is very efficient and fast and widely implemented. An implementation of the HL7 V3 model over V2 messaging using Archetypes to plaster over the cracks left by SNOMED-CT, complemented by GELLO working on the HL7 V3 Model (represented in the HL7 v2 data) with GLIF for high level decision support. Thats where we see the potential for success and a possibility for some sort of transition from where we are now to a exciting semantically interoperable future.
Is it possible… Its not easy, but it is possible. We have done enough work now to be sure of that.
Posted in DECISION SUPPORT, EHR, GELLO, GLIF, HL7 | No Comments »
December 21st, 2006 andrew
It’s and awesome combination. Thats the feeling we have after completing the first round of integration between our GELLO interpreter and our SNOMED-CT server.
One simple Method “.implies” has some much power in a multiple inheritance hierarchy like SNOMED-CT.
For instance:
This is a Laparoscopic appendix in SNOMED-CT
let Chole:SD = Factory.SnomedUtterance(”602280XX|Cholecystectomy, exploration of duct and cholangiogram|”)
Now what can the computer tell about this surgery? Well quite a lot really!
It has a parent of Cholangiogram so you can ask if a cholangiogram was done like this:
let CholangiogramDone: Boolean = Chole.implies(Factory.SnomedUtterance(”283670XX|Cholangiogram|”))
Now was this an open procedure or a laparoscopic one?
let Laparoscopic: SD = Factory.SnomedUtterance(”736320XX|Laparoscopic Procedure|”)
let isLaparoscopic: Boolean = Chole.implies(Laparoscopic)
This sort if information gathering is very useful in clinical decision support and GELLO is the perfect language to write the logic in.
At last we have a path to computable medical records!
Posted in DECISION SUPPORT, EHR, GELLO, SNOMED, STANDARDS | No Comments »
August 26th, 2006 andrew
Gello Lives!
Gello, a decision support programming language, has been declared an ANSI standard without any actual implementations, that is up until now.
Over the last few months Medical-Objects has been busy implementing a Gello interpreter and this was recently demonstrated at the Australian HIC 2006 conference.
This allows level 4 decision support and represents the first Gello implementation anywhere in the World. Gello is a relative of OCL (Object Constraint Language) and opens up many exciting decision support options, as the full array of atomic patient data is now available to assist in better, safer medical decision making by clinicians. In fact it empowers clinicians to customize their own systems to assist them in very specialty specific ways.
Posted in DECISION SUPPORT, EHR, GELLO, GLIF, HL7 | No Comments »
June 1st, 2005 andrew
The real jewel in the e-Health crown is computers that meticulously check everything in a way that no human can hope to match.
Using a modern PC to produce a text based letter is like calling in NASA for the launch of a paper plane. Our computers should be checking everything based on a set of rules we give them, not simple rules but easily customised rules that clinicians can enter and then ask our PCs to execute.
And, your PC could triage your in-tray
The medical day includes a lot of juggling of priorities, and ideally we want to be able to triage the in tray.
I want the abnormal result that is a surprise, to jump out at me, the referral for the deeply jaundiced patient to float to the top of the pile of requests. The patient who is on Warfarin that is booked for a procedure should generate an alert about the Warfarin. The follow up system should know that the patient actually has been followed up.
Medical-Objects has been delving into Snomed-CT for 12 months, and we are hooked.
It’s so beautifully simple and yet so powerful. Snomed-CT is very user friendly, to a clinician it has the richness to actually find most things you normally say, and if it doesn’t you can combine concepts to say it.
From a computer science point of view it has intelligence about medical concepts that take years for clinicians to acquire, and its all there for the taking.
Questions like “Was the procedure done laparoscopically” can be answered in a flash. You can compare different ways of saying the same thing for equivalence and it works, or at least for now it works pretty well.
The beauty of its structure is that it can get better at this and drag all the existing data up to new higher level.
Australia has been evaluating its options, but there is a cost in the delay.
The US and UK have made Snomed the national terminology, freely available for any clinician to use.
Even if we do not use the full power of something like snomed-CT we need to make a start, try and allow patient health records to be coded into some way, even at a basic level, as this can be leveraged in the future.
A simple system might look attractive, both financially and technically to “get things going”, but it won’t cut it in the long run, we sacrifice the future to make the balance sheet look good now.
The lack of a national terminology is a huge roadblock.
The ability to communicate medical data electronically is highly dependant on a good terminology.
Most packages have the ability to import HL7 automatically, which is a very big advantage over manually pasting text into the practice software, and places it well ahead of unstructured messages, but it’s the potential to really understand what is in the content that’s the real prize.
There have been many calls for simple transfer formats, to get “things happening”, but in reality its the communications and PKI infrastructure that is holding this up rather than the structure of messages.
Once the ability to cope with the communications and security issues becomes widespread, which it will, the focus will turn to content.
Transport of unstructured content will increase the speed of delivery and availability of patient notes when they are needed, but that’s just replacing paper.
While that is a worthwhile outcome and a very solid first step, it fails to capitalise on the advantages of atomic health data in a standard format.
Posted in DECISION SUPPORT, EHR, GELLO, GLIF, HL7, SNOMED | No Comments »