e-Health in Australia – Time to actually move forward!

Well we have had the election and there is no clear winner but it appears that the Rudd/Gillard government is the loser. eHealth is up for some reassessment and it certainly needs some.

From all reports $5 Billion of taxpayers money has been spent over the last 10 years and we have little to show for it. 10 years is long enough for any reasonable plan to bear fruit and there is clearly some fundamental flaw in the methodology.

The decision to purchase a SNOMED-CT license, and a Certificate Authority  is the only positive I can find. We do have a Secure messaging standard, but it is flawed by the fact that it really depends on Nehta “NASH” service for suitable certificates rather than working with the existing Medicare certificates. (and NASH is vapour ware) Virtually every general practice has Medicare certificates as part of the PIP program and the reason that the secure messaging standard was not designed to work with them lies with the dysfunctional relationship between Nehta and Medicare.

Dysfunctional organisations seem to be at the heart of the matter. We have not had one organisation for 10 years, but about 4 or 5 each of which has been rebadged and restarted only to repeat the same mistakes. That mistake, or the core of it is the idea that they have to “solve” the problem and produce software. Government is hopeless at doing this, indeed most large organisations are hopeless at producing software and large projects tend to fail. What we need is government to provide governance to move the industry forward rather than trying to do the heavy lifting. After 10 years the things that were working at the start are still working and all the things that are working are based on consensus standards. What we need is governance to comply with those standards and progress the standards in an incremental way. Currently we see much talk of Nehta inventing standards and despite some very capable people inside Nehta this is doomed to failure. Standards have to be created by consensus, as then the industry will engage with the painful standards process in order to prevent silly ideas becoming a standard and to fix errors where they occur. They will only engage when they know they have a duty to comply with the standards and this is where the lack of governance is failing us.

The standards process has become orphaned because Nehta have said they will be dictating the path, and they have failed to produce any clear path. More recently they have tried to steam roll standards and this is also likely to fail as without adequate review the standards will be poor.

Out there is the real world, which is the world that Medical-Objects inhabits, we see significant advances in communication with the number one obstacle being poor standards compliance. Because of a lack of governance large vendors feel that they can flout the standard and dictate the formats though sheer market size. Because of a lack of compliance anything that does work is fragile because it is never quite right, but has to be wrong in exactly the right way in order for it to work.

The dreams of the connected health landscape are often formulated by people with no knowledge of the importance of the lower levels. We can connect to the whole world of internet services because of compliance with the invisible things like tcp/ip and http standards and not because some middle manager dreamed of the internet. The dreams of a connected eHealth world rely on applications supporting the creation and consumption of high quality, standards compliant messages and not on the glossy pdfs produced by Nehta.

I don’t think we need Nehta, the states are not the eHealth leaders in this country and Nehta was setup as an uneasy alliance of the states, many of whom ignore Nehta anyway. What we need is good governance and a focus of standards compliance of all the applications that make up the landscape. There does need to be funding of the standards process and there needs to be a mechanism for providers of healthcare to pay to buy standards compliant software, which if built properly, will be more expensive than they are paying now.  However, the money they are saving is working against the big picture of a connected landscape and this is where governance and some well directed funding could make a huge difference. If every health application was required to be standards compliant we would see an enormous spike in interest in the standards process and the consensus process could be resuscitated for its premature death and we could start moving forward one level at a time.

The big bang process has failed, as it was bound to do and we need a return to proven paths. The cost would be a fraction of what was planned and the results, though slow would be much more solid. The tortoise is still in the race, its time to stop trying to follow the scatterbrain hare!

Posted in EHR, HL7, MESSAGING, SNOMED, STANDARDS | 3 Comments »

HL7 V2 just keeps on keeping on

It is interesting that so many people are keen to rubbish the encoding of HL7 V2 data. “It old and outdated” is a common comment. After a serious amount of time playing with it and experimenting with many encodings I am now convinced its brilliant.

The “xml will solve everything” mantra is fading as people realise its inefficient, and bloated and in my experimentation it works, but really offers few advantages. I use and like JSON and this is a no brainer when working with javascript. I have recently also been playing with erlang term encoding. This is used heavily in some pretty impressive scalable applications.

I have now converted clinical data into all three formats and it has made me realise the absolute brilliance of HL7 V2 encoding. Bloat with xml is a scalability issue, and the DOM structure holds up processing data as a stream, although this is not a serious issue. The human readability aspects of it is a joke. If you are going to process medical data then having it humanly readable is the last priority, especially as humans are so fallible. It is also not backward or forward compatible and no easy mechanisms exist to overcome these issues. In contrast HL7 V2 encoding, when parsed according to the rules, allows  great flexibility. A field can be made repeating, or,  eg. expanded from a simple string (IS) to a coded value with good backward and forward compatibility. The lack of field names is not an issue as the computer knows where the data should be. It reduces bloat significantly.  It is also possible to process the data as a stream as you don’t have to wait for a closing tag. Absent values can just be omitted, further saving space. New values can be appended to the data types or segments without breaking parsers.

JSON is much better than xml, but still bloats because of field names and changing a string into an object causes significant issues. Erlang terms omit the field names, but require absent values to be encoded as blank and are inflexible when new fields are appended, making backward and forward compatibility problematic.

While free of off the shelf parsers are available for the other formats I think this up front advantage quickly fades once the other issues appear. HL7 V2 encoding does at first seem old hat, but it was developed in an age when most people in the industry were computer science gurus as the resources available were so limited, and things had to be efficient to actually run. After actually implementing transforms into the common alternatives and realising that these formats are likely to cause problems when version changes appear I have a new respect for the HL7 V2 encoding. I suspect the critics have not really used it in anger, as it just keeps on keeping on.  xml might be great for a quick and dirty data exchange format where efficiency is not high on the list. Its also essential when astronaut architects are at the helm!  JSON is very efficient talking to a html/javascript front end. However for the core backbone of health messaging that has to cope with multiple version of data and be efficient and not consume vast quantities of disc space I still think that well implemented HL7 V2 is simply brilliant. Despite being the poor cousin of the modern formats, its position as the most used medical messaging format does not surprise me. The tortoise might yet win the race!

Posted in EHR, HL7, MESSAGING, STANDARDS | 1 Comment »

eHealth – What is going wrong?

Its clear that I am not a fan of Australia’s attempts to progress eHealth. Its probably time to look at some details. The devil is in the details after all.

The first basic error of HealthConnect and NEHTA Mark 1 & 2 is a violation of a principle that I think is very important in this field. This comment from “Joel on Software” relates to Netscape’s decision to rewrite Netscape Navigator from scratch. The full post is worth a read and is available here

“making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.”

This error has been repeated again and again by every NEHTA clone in the last 10 years. Despite declarations that Australia has decided on using HL7 V2 on several occasions, attempts have been made to “roll our own” standard. This has of course failed again and again but this lesson is continually forgotten. Even the UK NHS backed up with 30 Billion pounds and a draft HL7 V3 standard has failed dismally to achieve this and its time we decided to use whats in place, proven and tried to improve the quality of implementations rather than somehow develop something new.

The fact is the HL7 V2 standards have been proven to work for a large variety of the indications we desperately need and there is actual support out there in existing local and international applications. The support may not be perfect but its a base to build on. The fact that its 20+ years old is often used against it, but code does not rust in my experience and something thats been refined over 20 years is likely to be a far better bet than something shiny and new that has never been proven to work. Its ugly in places and has all the warts and battle scars of a standard that was, and never will be perfect, but has been proven in battle. This same idea of avoiding a rewrite from scratch is a lesson that HL7 has learned the hard way with HL7 V3, which despite good intentions and much work fails to be a viable replacement for HL7 V2 after 10+ years of work.

NEHTA, not having any real expertise in HL7 V2, have a blind spot to what is actually working in the landscape and how it works and treat the existing messages as some sort of “blob” and as a result fail to understand that the important business processes of healthcare are deeply embedded and supported in HL7 V2. Ignorant of this they have wasted precious resources in re-engineering the business processes in services that have come and gone and never been used in anger. These services were to use HL7 V2 but the details of this “blob” content was never understood and the defense was that the people they talk to didn’t want to use HL7 as they did not understand it. I assert that this is the problem. HL7 V2  supports the business processes in a proven manner, often in far more detail than these first draft services could ever hope to achieve. Overlaying 20 year old proven HL7 V2 services with naive first draft services that often conflict and overlap with the actual message is not a recipe for success. HL7 V2 needs only one service, and thats a security wrapper to allow secure authenticated transmission. Duplicating a small percentage of the richness in the service only creates confusion. What do you believe the payload or the wrapper? The payload has been refined in over 20 years of real use and lack of understanding of the payload is not an adequate defense for producing a pale imitation of it.

Its this blindness to the ecology of healthcare IT that results in the unforgivable lack of push for compliance testing of existing HL7 V2 implementations. Its hard to be critical of the quality of messages you don’t understand yourself and you simply nod and say “it looks like HL7 to me, but it does not work. I have no idea why, lets build our own standard”. It will never work and the half a billion dollars proposed for ehealth in the recent Budget is a waste, just like the Billion $ wasted over the last 10 years. Nothing, not even identifiers, has any value until quality issues are addressed in the current environment.

There are certainly deficiencies in HL7 V2, mostly because it has been neglected because of the focus on HL7 V3. These deficiencies can be addressed, but only when basic quality checks are in place. To try and improve semantics without addressing the basics is misguided. One basic functionality we could have is allergy checking. That is assuming we had some building blocks that worked.

The “Simple” task of allergy checking is in fact not at all easy. A patient may have a penicillin allergy recorded, but patients are not prescribed “penicillin” these days. They are prescribed Augmentin, or Timentum etc These drugs contain a penicillin derivative, and should not be used but we need to know that they are children of penicillin and this is where a medication terminology is supposed to step in. The “AMT” or “Australian Medication Terminology” was supposed to fill this gap and has had 50 people working on it for 4 years or so. Surely this can be used for this basic task? The answer is no…. It fails to provide any mechanism to identify that Augment contains penicillin!! SNOMED-CT – the terminology its based on certainly does but the AMT is isolated from SNOMED-CT and cannot do this. You would have to manually go through it and pick out every drug containing penicillin, using some sort of external data source. This is the exact role a medications terminology is supposed to fulfill and while it might look like a medications terminology its just a big dumb pick list.

To progress eHealth we need an organisation that uses existing standards, potentially tries to improve existing standards and understands in a very low level way how those standards could be used to achieve the things that eHealth promises. Ideally it would test those things and provide expertise and workers for standards bodies. NEHTA as it stands is a political organisation mainly that produces very nice visions and glossy brochures. It also has some very talented super specialists who know nothing of the big picture and is lacking in individuals (or not empowering them) who can see a path to evolve the current landscape into one that really works reliably and safely and can contribute to the process in a positive way.

The examples of the lack of low level understanding of the technical details and true state of the current landscape or abilities of the current standards are virtually endless. I have presented some personal views on a couple of them. There is no forum for this type of discussion in the current environment and everything is done at a level where the technical details are out of scope. This really makes success out of scope and value for money ($500,000,000 in fact) out of scope. Health IT needs to get into the technical details, managements role is to make this easy for the people involved and shield them from the political process. Its the equivalent of a hospital staffed only by administrators and quality control consultants, but no nurses or doctors.  From memory that hospital won the “Florence Nightingail Award” for cleanliness in Yes Minister. Patients are unlikely to benefit.

Posted in EHR, HL7, STANDARDS, Uncategorized | 4 Comments »

eHealth – Where is the duty of care?

After watching the failure of the Government Home Insulation Scheme and the Payroll issues with Queensland Health unfold its clear that the eHealth issues in Australia are part of a much bigger problem.

There is enormous potential for eHealth to cause damage and there is a duty of care to make sure the risks are minimised. Currently the push to roll out parts of the eHealth agenda is just as flawed as the home insulation scheme and the payroll system. We need to get some basic quality controls in place first or the consequences will be worse than what we have seen with these programs. Poor, missing or incorrect patient data  can be just as deadly as Foil insulation in the hands of untrained installers.

Nehta, I am sure, has some great talent in its ranks, but I don’t see anyone with an overall understanding of the issues that face eHealth or how to fix them. They are unwilling to listen to the practical concerns of people with experience and now it seems they are under political pressure to deliver and just like these other rushed programs the risks are very high.

I have multiple levels of concern, but chief amongst them is to try and steamroll connectivity in a physical sense when in a practical sense it is badly broken. The quality of the data being moved is low and very non-compliant with standards and this is well known. There appears to be a block on the idea of a quality program for the messages, despite the machinery to do this at a basic level existing for over 5 years. Applications fall over importing good data and often fail to display it correctly and in many cases can’t support HL7 (Health Level 7) at all. Blindly sending data around, even with shiny New Health Care identifiers is a recipe for disaster.

We need to get some compliance programs going for existing health data and once that is done it is possible to try and move to the next level. No matter how much political pressure you apply computers are very stubborn when the bits and bytes are in the wrong place and will not budge. It seems that politicians NEHTA and the public service are yet to learn this. Failure to do this will expose us to the first big eHealth Train wreck, that is clear.  Large applications are built from components and to make something big work you have to have confidence that the components work reliably, currently they do not. We don’t need radical change, we need an expectation of quality and a requirement for quality, backed with testing. I am sure the underlying intentions of the Home Insulation scheme and a New Payroll for Q Health were sound. They both failed because of a lack of compliance testing on the components.  At the moment Nehta is heading down the same track and the bridge is out just around the bend.

Posted in EHR, STANDARDS | 1 Comment »

NEHTA – On the road to nowhere?

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 »

Detailed Clinical Models (DCM) – Only Standards offer a way forward

There appears to be a mood of desperation in some areas of the eHealth brigade and even suggestions that we move forward with proprietary formats. This would be a huge mistake. The best example at the moment is attempts, in Australia, to push openEHR formats over the EN-13606 standards. EN 13606 is certainly based, at least to a large extent on the work of openEHR, however openEHR say “they have moved on” and have been busy “extending” and “enhancing” the standard.  openEHR is in fact an application architecture rather than a data exchange standard and most of the changes make archetypes created with the openEHR tools very specific to the openEHR environment.

This poses an unacceptable risk on others using those tools, as openEHR can evolve the specification in any direction they please with no recourse.  While standards development is a painful process it does generally provide for a balanced view of the world, or at least tries to achieve this. Vendors can develop against a standard and use it in innovative ways that the makers may have not even considered. A specification under the control on a small group provides no protection and should not be used for interoperability. 

We need to hold the line on the use of standards and avoid the temptation to take shortcuts, as in the long run those shortcuts will backfire and give control to a small group. The later openEHR ADL versions are not backward compatible and include many internal openEHR codes and information that is highly specific to the openEHR model. EN 13606 is agnostic to the final implementation technology and a stable specification and should be used for any public projects in Australia.

Posted in EHR, STANDARDS, Uncategorized | No Comments »

Why is Health IT so hard?

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 »

xHTML, Microformats, SNOMED-CT and Medical Records

We know we want good semantics in messages and the best way to get that is atomic data in a standards based format. However the roadblock we run up against is that its not sexy enough!

The availability of computers rather than typewriters for Medical Notes means that the visual presentation of a clinic report or letter has become important to many and when you suggest that readers are really interested in the content rather than the presentation you often get that sinking feeling that you have just lost them.

So it seems to keep everyone happy we need both. However that sexy display needs to be portable and ideally standards based. It is also desirable to have some semantics in the display so a consumer of the report can eg. Click on a drug or diagnosis to drill down for more information. Ideally combining the atomic data in the HL7, which for example include images, with a standards based display format using xHTML and CSS, would fit the bill. Using Microformats it would also be possible to mark up diagnoses and drugs with there SNOMED-CT representation.

eg. Say you wanted to say the patient Had “Large B-Cell Lymphoma” – as Text this is not something you can reliably parse out, however if you used Microformats in xHTML you could represent it as:

<span title=”64572001|Disease| : 116676008 = 46732000|Malignant Lymphoma, large B-cell diffuse|”>Large B-Cell Lymphoma</span>

Or for usual more compact usage you could just use the SNOMED-CT codes alone:

<span title=”64572001 : 116676008 = 46732000″>Large B-Cell Lymphoma</span>

Now this embedded in the display text has real meaning and could be used as a link for disease information for example. The Australian HL7 V2 standard defines a html display segment, as the last OBX in a message and by transmitting the atomic data in the preceding OBX segments for machine usage and including a xHTML display segment you get the best of both worlds, atomic data and sexy display. If you add microformats to the xHTML then the display still has semantics that are safely extracted. The SNOMED-CT grammar can also go further and define such information as “This is a past history or Family History of a disease” which extends the semantics further.

Currently HL7 Freetext is used for display, and the only real formatting available is bold. This is causing some user pushback and a move to xhtml and CSS (probably with no javascript and inline CSS) would allow the embedding of good display into messages containing atomic data. HL7 CDA – Clinical Document Architecture allows to a html display segment as well so the concept is usable here as well. The alternatives would be rtf display, but xhtml is far more semantic and standard and is likely to be more inter-operable. There are free xhtml validators on the web and some form of view control is installed in virtually every OS available, which increases the attractiveness of xhtml.

It is an idea we are exploring at this time.

Posted in EHR, HL7, MESSAGING, SNOMED, STANDARDS, XHTML | No Comments »

Australia’s eHealth plan

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 »

Medical-Objects cross platform sneak preview

Its taken an enormous effort, but we are finally close to having the same code base compile on Windows, OSX and Linux.

The core HL7 code was not difficult but in the end we have implemented at lot of the threading and synchronisation calls that are in windows, but not in *nix. It have also meant implementing many complex routines in pure pascal. This has included a HTTP server, RSA/IDEA encryption and JSON and XML parsers! It has also driven us to the Web 2.0 world, which has been a pleasant drive!

Credit must be given to the amazing ability of Peter Tattam, who has been slaving away at this task on and off for the last few months on and off. His ability to work with low level code is second to none.

So where are we up to – we have a native pascal version of Capricorn, running and working well on OSX with the same source code base as the windows version. At this stage its not using any special libraries and is a single executable. We have dissected out or implemented all the windows specific code and are close to doing some beta testing. The scary bit is that in its current form its 300K lines of object pascal code… Luckily its mostly code that has been under extensive use in the Windows world for quite a while.

So here is a very raw low res sneak peak of Capricorn running as a Native OSX appication. It really isn’t much to look at as this is pure messaging infrastructure, but its important vital infrastructure if we are going to move into a world of real time standards based HL7 messaging!

Posted in EHR, HL7, MESSAGING | No Comments »