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 »
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 »