August 22nd, 2010 andrew
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 »
February 29th, 2008 andrew
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 »
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 »
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 »
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 »