Andrew McIntyre wrote: > Hello Tim, > > What you describe is what Medical-Objects provides now.
Yeah, and I note just that when I asked Tom Bowden for details of his company's deployed Web services stuff. > Checking if the interface is up is lower overhead than polling and > allows for realtime messaging. We can run servers in the manner and > push realtime HL7 Queries via the proxy. There is never any doubt > about the delivery as its peer to peer. Yup. > You do need someone to run the proxy however, and the proxy cops the > traffic, so it cannot be totally free and its silly to suggest to > should be. Its hard to compare this to google.... do you want us to > allow Drug companies to send you adds, as a way to pay for the > service, surely we don't want to repeat that mistake? I never mentioned business models for operating Web service servers, just the desirability of open source reference implementations. Open source does not equal free, it just means that there is no monopoly rent on the code. There are still costs involved in configuring, running and troubleshooting installations of any software, and yes, someone has to pay for those costs (and be paid to do the work, provide the bandwidth etc etc). If practices wish to pay someone else (like medical Objects) to act as a Web service proxy for them, then that's fine. But there must not be anything built into the adopted model which entrenches such arrangements - if practices wish to run their own Web services using packaged open source or closed source code, then they must be free to do so. Of if they wish their local Dvision to contract out running such services to someone like Peter Machell, then that must also be possible. > These interfaces are open and available now and support HIC PKI, PGP > and PKI encryption. Because of HIC LDAP support no pre-registration is > required for PKI keys. > > To make this work you need provider directories and a sort of "Medical > DNS", which we provide - Our "Routing Information Services" server and > "Provider Directory Server", which use realtime HL7. You can it > manually without these but its hard to automate it. Yes. The "medical DNS" needs to be a replicated national service, and because it is a key bit of infrastructure, not allowed to be controlled by a single company. However I understand why Medical Objects had to set up its own while it waits for everyone else to catch up. > We also offer the same webservices via HTTP and HL7 Lower level > protocol and can interoperate with argus and eClinic. In fact we > already have gateways to Argus, eClinic, Promedicus, PGP, Email and > IBM MQ series clients, in fact they have been running for over 6 > months. > > Because of dialup users store and forward is still needed and we > support this method as well. (And SMIME, PGP and GNUPG Email if you > want it) > > However SOAP interoperability is overrated as trying to get wsdl to > smoothly import across Java/.Net/Delphi/Phython etc is not as smooth > as everyone seems to assume it is. Getting the HL7 V2.x to work is > usually easier! > > While its easy to malign HL7 V2, it is a technology proven and refined > over 20 years of use and the majority of pathology data successfully > delivered every day across the country uses HL7V2.x In our experience > the problem is almost always implementation errors and AHML > certification for all vendors would fix most of those errors overnight > (After certification that is). Getting full semantic interoperability > is harder, but relies heavily on good underlying HL7 so certification > is the first step. > > I think NEHTA should be working to offer a similar HL7 based > webservice for authorities now, surely government should be leading > the way? A few less "Z" segments would be nice, the axed Better > Medication Management system only had one. > > I also favour the point to point realtime messaging over the IHE XDS > or "Cross Document Sharing" model. Delivering documents from provider > to provider, as we do now with paper, also overcomes privacy concerns > over "Document Repositories" OK, thanks for that information, Andrew. I agree that HL7 2.x can be made to work but that doesn't stop me from wishing for something better. Regardless, it seems clear that point-to-point Web services with no middle-man are the future, interoperability problems notwithstanding. Which is why open sourced reference implementations of the key parts are so important. Tim C > Saturday, April 29, 2006, 12:25:10 PM, you wrote: > > TC> Tom Bowden wrote: >>> >>> >>> 1. PMS Requirements v1.3 :- >>> >>> http://www.healthlink.net/Special_Authorities/SA-PMSReq13.pdf > > TC> OK, thanks Tom. An interesting document - it details a Web service > TC> through which a GP PMS (practice management system) is able to request > TC> approvals for special authority drugs - an approach which is MUCH better > TC> than having to fill in an HTML form, as it allows fairly tight > TC> integration with the clinical software system in each practice, avoiding > TC> the need for rekeying or cutting-and-pasting data. > > TC> If I understand it correctly, HealthPAC, which is the NZ govt authority > TC> responsible for regulating and approving authority drugs (I think) > TC> issues a monthly list of authority drugs and an associated set of > TC> criteria, as an XML file. Each PMS must import this list and process it > TC> so that when prescribed by the GP, the PMS recognises that an authority > TC> to prescribed is required and it displays an HTML form asking the > TC> relevant criteria questions for that particular drug. HealthPAC provides > TC> an XSL stylesheet which converts their criteria XML into an HTML form to > TC> be rendered by the PMS in order to collect the necessary criteria > TC> information from the harried GP. The PMS then generates the appropriate > TC> HL7-in-XML document, digitally signs it, encrypts it using HealthPAC's > TC> public key and wraps it in a SOAP wrapper. The PMS then contacts the > TC> Special Authority Web service and synchronously sends the authority > TC> application and waits, still connected to the Web service, for a reply. > TC> If no reply, it just retries until it succeeds. Thus there is no need > TC> for the GP system to act as a server, just as a client and it does not > TC> need to be online 24x7. The GP PMS/clincal system needs to handle the > TC> situation in which the Special Authority Web service is down or offline, > TC> or when it does not reply in the specified time period. There is no > TC> store-and-forward facility or ability for the GP's system to deposit > TC> applications in a queue for HealthPAC to process when its Web services > TC> come back on line. > > TC> All this communication must occur "via a network approved by the Health > TC> Intranet Governance Body. Currently the approved network providers are > TC> Telecom New Zealand (providing the Health Express product) and > TC> Healthlink (providing the SecurIT product)." > > TC> As noted, a pervasive PKI is also necessary. > > TC> Now, if all this does indeed work nicely, as Tom tells us it does (and I > TC> have no reason to disbelieve him), then it begs the question: Why can't > TC> this model be turned around and be used for results and reports delivery > TC> to GPs? The GP's system needs to provide a HTTP server accessible at an > TC> Internet URL, and this Web server handles Web services requests for > TC> delivery and receipt of results and requests from path labs, > TC> radiologists, specialists or hospitals (eg discharge referrals). The > TC> sender acts as a client, and if the recipient GP Web service is not > TC> contactable or doesn't confirm receipt, then it retries for a defined > TC> period then falls back to alternative deliver methods if the urgency of > TC> the results or report warrants it eg faxing, courier delivery of paper > TC> results or snail mail. The electronic version of the results or report > TC> could still be retrieved later by the GP system (or sent to it later) > TC> when the GP system comes back up online. > > TC> The nice features of this model are: > > TC> a) All communication is peer-to-peer. No middlemen, no toll gates, no > TC> single point of failure. > > TC> b) The sender gets immediate status information about the delivery of > TC> the report or results, and can take appropriate alternative action if > TC> necessary. > > TC> c) The software machinery for all this is now readily available as .NET, > TC> Java, Python etc libraries. > > TC> The downside is that there is no store-and-forward mechanism, so that > TC> quite a lot of retrying is needed if a GP or other service provider Web > TC> service is offline or down. However, retries only occur when Web > TC> services are offline, and I suspect that the total volume of retries > TC> might be less than the volume of polling requests in the IHE model which > TC> Ross Davey advances. Also, the lack of store-and-forward can be seen as > TC> an advantage because it allows for immediate delivery status tracking by > TC> the sender, all the way to tthe recipient clinical information system , > TC> a feature which Tom Bowden constantly reminds us is very important. > > TC> It is easy to conceive of each Web service (eg for each practice) > TC> publishing a list of alternative delivery mechanisms to be used for > TC> urgent information (fax, SMS etc). Sending parties could use those > TC> alternative routes if the Web service to which they are trying to send > TC> is down and the information they are trying to send or have processed or > TC> acted upon is urgent. > > TC> Necessary infrastructure for this to work: > > TC> 1) A pervasive X.509 PKI, with an associated human- and machine-readable > TC> directory of the people who work in each service provider (eg GP > TC> practice), their human-relevant contact details (phone number, snailmail > TC> and street addresses etc), and the URLs of teh Web services which they > TC> expose to the rest of the world. > > TC> 2) Health service providers such as GPs need Internet connections with > TC> fixed IP addreses to allow them to run a Web services server - not > TC> necessarily 24x7, but at least during office hours. This implies a > TC> suitable firewall/Web server at the edge of their practice LAN on which > TC> the Web services can be run, and the necessary SOAP interfaces between > TC> their clinical applications and those Web services. I suspect that if > TC> this model became popular, more and more practices would run 24x7 Web > TC> services. But if they didn't, it would still be functional. > > TC> Why is all this better than using SMTP to securely deliver documents? > TC> Because Web services can do more than just send and receive documents > TC> such as path results. The NZ authority drug application illustrates > TC> this. The GP system is effectively asking via a Web service RPC (remote > TC> procedure call) "Can I prescribe this drug to this patient for these > TC> reasons, can I, huh, please, pretty please, what's your answer, tell me > TC> now?" and immediately, the govt authority responds "Hmmm, everything > TC> seems to be in order, so yes, you may and here's the authorisation > TC> number." (Or it may respond "<cough> Computer says 'no'"...). OK, there > TC> is not a lot of on-the-spot value-adding by the govt authority in this > TC> example, but you get the idea. This sort of conversation could be > TC> carried out via SMTP store-and-forward email messages, but the more > TC> involved and complex the conversation between the parties, the more > TC> difficult that becomes. > > TC> So thanks to Tom Bowden and Healthlink for providing a nice example of > TC> peer-to-peer, no-middle-man, no-single-point-of-failure Web services in > TC> health. Bring it on, I say. Apart from progressing the establishment of > TC> the necessary infrastructure as described above, and finalising or at > TC> least fleshing out the Web services framework it has described so far, > TC> the best thing that NEHTA could do would be to commission the creation > TC> of a set of "reference" software implementations of the Web service > TC> server and clients ends, for a number of software frameworks/platforms > TC> (.NET and Java are obvious ones, and I would add Python as a good > TC> cross-platform third bet), and release these reference software > TC> implementations under a suitable open source license which allows > TC> clinical software vendors to freely incorporate the reference > TC> implementation code into their products. This saves everyone from having > TC> to build their own implementations to the NEHTA Web services specs, and > TC> thus would promote consistency and adherence to those specs, as well as > TC> providing a level playing field which actively promotes competition. The > TC> cost of creating open sourced reference implementations of Web services > TC> servers and clients should only be in the hundreds of thousands or low > TC> millions of dollars (since much of the machinery is already available in > TC> standard or free SOAP libraries) - maybe much less. > > TC> That would be nirvana for mice, I think. > >>> 2. HL7 Definitions v1.6:- >>> >>> http://www.healthlink.net/Special_Authorities/SA-HL7Def16.pdf > > TC> Sorry, I have to deal with HL7 2.x as part of my day job, which is > TC> enough to induce a severe dysthmic reaction (the HL7 2.x, not my day > TC> job). Reading yet more HL7 2.x specs on a Saturday morning would be > TC> risking my mental health, I fear. > > TC> Tim C > > TC> _______________________________________________ > TC> Gpcg_talk mailing list > TC> [email protected] > TC> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > TC> __________ NOD32 1.1512 (20060428) Information __________ > > TC> This message was checked by NOD32 antivirus system. > TC> http://www.eset.com > > > > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
