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 »
February 17th, 2008 andrew
Our initial cross platform porting efforts were directed at OSX, but given its heritage we knew that linux would be close. It was quite easy in fact in the end and was running within a few hours. The yahoo user interface toolkit has been chosen for the UI and its certainly impressive. As capricorn is mainly a client for secure messaging it doesn’t not need much of a UI, but much could be done in a browser when combined with JSON and rest methods. Pictured is a form to send simple secure clinical messages directly from Firefox. Its useful to send quick notes but usually capricorn would integrate directly with other software.
Posted in HL7, LINUX, MESSAGING, SOAP, Uncategorized | No Comments »
February 2nd, 2008 andrew
This is the challenge of health IT at the primary care level. Most of the medical-objects destinations are Australian general practices which while computerised, are only just computerised and the stability and management of their systems is well… poor in general.
On top of this we run real time messaging using full PKI security for privacy and authentication. It is a challenge at times and we are continuing to learn, sometimes the hard way. The average life of a client install is < 12 months and often no one in the practice knows which computer is on, and frequently that computer disappears as part of an upgrade or reshuffle.
Managing this over thousands of sites is something we are trying to perfect. The first lesson we learnt was to get the content of the messages standards compliant. This has been vital as when we know that the payload meets Australian standards we can safely tweak the envelope to suite to recipients software, which often can’t handle compliant HL7. Compliant messages have allowed us to develop a large number of message modifiers or decorators which can be chained together in a huge number of ways to achieve a message that can be consumed. Even with a huge array of standard modifiers we still run into problems. Corporate systems are virtually impossible to tweak and the fact that they read to report date from the wrong place is something that you sometimes just have to accept. So the next element that makes it work is scriptable modifiers. We have a pascal script interface into our hl7 and xml parser that allow virtually any modification to be made. This is less routine and scalable that the canned modifiers, but is something you just need to have.
The other area that has proved vital is ongoing monitoring of server uptime. This allows us to detect clients with problems before someone notices that there have been no results for a while. Installation of new anti-virus software or changes to authentication parameters commonly cause this. We have also found sever instances of ISP misconfiguration of routers that block traffic between 2 clients.
Forwarding of errors in sending to support is another vital health monitor. Analysis of this is still not to the stage we would like it as many clients are disconnected after hours and weekends and the monitoring has to try and take this into account. Automating analysis of the problem is also an area we can improve on. We have started to identify patterns in the errors that mean something but the analysis is quite complex. We are considering using GELLO (Clinical decision support Language) to try and recognise these patterns in an automated way.
Double checking of new user and upgrade configuration is now much enhanced also. Users are good at finding shortcuts and at one stage we found support found a way to copy installation setups, followed by a few modifications. This made their setup much quicker but they did not change the GUID that is used for the URL on the proxy server…. The pleasing thing was that the PKI infrastructure prevented breaches of privacy as a wrong recipient could not decrypt the data but it had us scratching our heads. The sender and recipient both had each others keys and they were signed and correct but still we were getting errors in both authentication and decryption. In the end several clients were randomly getting each others messages so it would fail commonly, but if the correct client eventually received the message it would work. It was only when we noticed no hits in the client log despite a failed transmission that we tweaked to this one. The servers now avidly check all setups to prevent this happening.
The process has also made us aware of the difficulties in testing distributed systems. We have complex test setups but trying to simulate the real world of a distrubuted messaging system is also impossible. You have to try but the ongoing monitoring of connectivity and errors is something you have to have and the real world will always throw up surprises.
However we are excited about how well it works and how fast distributed systems are. The real world works quicker than any test setup and the message processing is done on different machines. In a test setup on a few machines you can almost follow it by looking at logging windows. In the real world it moves so fast that you have no hope of following it. Now to build something useful on top of it, after all that’s why we built it!
Posted in GELLO, HL7, MESSAGING, STANDARDS, Uncategorized | No Comments »
January 23rd, 2008 andrew
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 »
January 19th, 2008 andrew
This was the title of a recent article in the Australian.
There is no doubt it true and the suggestion was the bypass NEHTA to change it?
There is a trend that keeps repeating here, every version of Health connect survived for a few years and then was axed because of lack of progress. Sometimes the baby gets thrown out with the bathwater. We have had several declarations that HL7 V2 is going to be the messaging standard that Australia will use, but every new iteration says – No we will look at the situation and decide and everything goes to sleep yet again. NEHTA has at least realised that the only sensible way forward in Australia is with HL7 V2. They are probably in the mood to listen to industry and be more enablers than standard creators and perhaps disbanding NEHTA is not the best way forward.
There are a few things that we clearly need:
Resourcing of Standards Australia – Currently run on a shoestring
Involvement of Technical People – Almost absent from the process – probably through frustration
Compliance with Standards – Ideally this would start with the state health departments!
Certification of Software – we don’t use untested Medication! so why is software not tested?
Support of R&D – eHeath requires this as there is so much yet to be discovered
Somehow the industry needs to get back a solid direction so that we can start some incremental improvements towards a common goal. At the moment there is a complete lack of technical direction.
Posted in EHR, HL7, STANDARDS | 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 »
February 18th, 2007 andrew
Thats what Medical-Objects is working on at the moment? Our realtime clients are now starting to be more routinely deployed to receive data and increasingly to send data.
These clients live behind firewalls but have a public web based interface that supports SOAP and Http interfaces.
They exist in environments that could not and should not be opening listening ports because of lack of IT support. How is this done – by applying the “Proxy Pattern” Medical-Objects are now running a suite of proxy servers who will hand encrypted data to the waiting clients and then forward the response back to the sender in realtime. This is not store and forward, but realtime connectivity. All HL7 processing is done at the client.
This means you can deliver results directly to GPs desktops and know that it got there (or did not) in realtime. Combine this with an mind boggling array of prebuilt and tested message transforms and you have a distributed flexible realtime secure network. Clients can even run off multiple proxies to reduce to potential for a single point of failure and all messaging is point to point.
Obviously this model needs services, we have well tested routing directory and provider directory services to support this and the overhead is small. We estimate that that a single appserver could proxy 2000-4000 practices in this way.
Realtime messaging opens many doors for the provision of services and we are excited about the future of this technology. It makes EMail messaging look like the telephony equivalent of a telegram.
Posted in Uncategorized | No Comments »
February 18th, 2007 andrew
An observation, that has become more marked with time is the lack of technical people at HL7 meetings and Standards related activities.
This is a concern and most likely part of the eHealth “Problems”
This is matched by an increase in managers and bureaucrats in the same meetings. While certainly not confined to the health arena the lack of technical knowledge can make progress difficult. eHealth is in some ways similar to Health in the way it works. In health senior doctors do not progress into administration as their experience increases, but continue to apply their skills to patients and teach more junior doctors. A move into administration is regarded as a backward career step by most doctors.
In IT similar forces are at play. Without in depth knowledge and experience its hard to pick to glossy marketing from the innovative and solid solutions. Senior IT people, who still are active in development are a key resource to guide direction and teach junior IT graduates and many of the IT gurus of the past are respected as teachers and luminaries for their IT knowledge and not for their move into management.
Solid solutions that work are easily overlooked by non technical eHealth players and the sexy new “xyz” is “the way to go” even before a single working implementation is done.
Solutions that solve important problems well and reliably are ignored in favor of the latest solution, often because it done in “xml”
In Australia Pathology labs have been reliably producing and distributing quality V2 HL7 for nearly a decade now but somehow this is regarded as insignificant and too hard to apply more generally. Similarly encryption standards that just work are rejected for XML Encryption and digital signature. Its not that the new options are bad, its just that they are immature and largely untested in wide usage. Whats wrong with working reliable CMS/SMIME encryption standards that we know can work?. (and this is just one small example)
There is no doubt that eHealth is hard to get right, but it will never happen until we involve technical people as a core part of the process. Any new standard should have example implementations that we know work well and scale before we start rejecting technology that is known to work. I wonder how many members of the technical committees could actually look at a HL7 message and have any idea what it all means? Until the answer to that question is > 90% of the Committee we have a problem!
Its time we involved Technical People in the Technical Committees!
Posted in EHR, HL7, STANDARDS | 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 »