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 »