June 8th, 2006 andrew
As part of monitoring our new realtime GP SOAP clients we are closely monitoring uptime (every 5 minutes). One practice was experiencing poor uptime and we had narrowed it down to a problem were a http connection to the Medical-Objects HL7 Proxy server was hanging and never returning. No errors occured, but the connection had to forcably be closed to allow the client to continue to function.
After narrowing the problem and coming up with the workaround to allow some function (as the http call progressed normally often) we were unable to see any obvious coding issue. Then one day everything started to work and the errors were gone!
An email revealed that the “Cheap” ADSL router had been replaced by a Cisco router. We can only attribute the previous problems to firmware bugs in old ADSL router. This is not the first time we have seen this, but the graphic provides dramatic evidence of the value of a good quality router.
Each horizontal line is one day with total uptime as percent on the left.
Posted in HL7, SOAP | No Comments »
June 8th, 2006 andrew
HL7 Australia have established a new wiki site to encourage discussion on messaging and web services in the Australian setting.
Medical Objects will be gradually documenting our Interfaces on this site over the next few weeks. The first section is on The Provider directory interface and can be found here
Posted in Uncategorized | No Comments »
June 3rd, 2006 andrew
We often hear the comment that there is a problem with HL7 because it doesn’t interoperate (with “my” messages).
Almost invariably a close look at the message will reveal basic errors that are the cause of the problem. Errors like segments out of order, a lack of unique identifiers, or no result identifiers at all. Even incorrect codes for the message type.
The problem is Poor Implementations rather than a problem with HL7. Take any one of these messages and run them through the free AHML testing engine and the problems will be obvious. But this is not happening – why not?
It seems that in the medical world you have some very obvious paradoxes – I have to send the laundry to an accredited laundry to be washed but I can send or receive vital medical data in hacked together incorrect HL7? The nature of some of the data is absolutely critical to patient care and errors literally can make a life or death difference, but still no accreditation, or even attempts at it?
We have heard comments to the effect that “My messages are correct, you are wrong”, without any testing of the messages, and at times an assertion that the testing is wrong. Now we have found some edge issues with the testing, all of which were rapidly fixed, but I doubt these assertions are correct. The nature of accreditation is that unless you can convince the accreditor that you ARE correct you are wrong.
There are also problems with applications processing compliant messages. They have adapted to errors in fixed ways and when faced with a correct message cannot handle it. Consumers of messages need to be sure they can process correct data as well. A standard test message set that was checked (by a human) for adequate display would be a good start.
We dream of “semantic interoperability” but this is a pipe dream unless the basics are solid. Semantic interoperability is putting more meaningful content inside the messages. If the container is broken what chance do be have of safely transporting the fragile content?
Its time the “Authorities” showed some leadership on this. Accreditation has reached ridiculous proportions in other areas of healthcare and yet is curiously ignored in the one area where it’s so badly needed.
Posted in EHR, HL7, STANDARDS | No Comments »
June 3rd, 2006 andrew
SOA is the latest buzz word. Its probably inappropriate to dismiss it as the basic principles are quite sound, but its not a new idea.
Medical-Objects fully supports “Service Orientated Architecture” and in fact has had just that architecture from the start. What is annoying is the idea that SOA means XML and SOAP. By definition it does not, but if your sole source of information is marketing material you may think so.
HL7 V2 supports a SOA model quite well. It supports the concept of applications handling a subset of functionality and other applications using that functionality via HL7 Messaging. ADT and master files are good examples of this. The critics would say its not constrained enough to call it SOA, but they presume that its easy to write highly constrained wsdl that the whole world will think is fine to use unchanged, and this is a pipe dream. Its a pipe dream that the original inventors of HL7 understood and made allowances for. You may have to negotiate parameters a little but the structure will support virtually any parameter you want.
SOA is a Pattern to allow distributed applications to be designed using the same sound principles of software design that have been known (and often ignored) for years. To quote “Elements of Reusable Object-Orientated Software”, the bible of software design by the GOF: the most important principle is “Programming to an Interface, not an Implementation” SOA does not replace Object Orientated software design, as I have heard some people suggest, it simply moves it to a distributed networkable component model. It has nothing to do with XML or SOAP primarily, they are just one implementation of the pattern, HL7 V2 is another.
Posted in HL7, SOAP | No Comments »