Hello Tim, What you describe is what Medical-Objects provides now. We can proxy the GP listening interface so that there is no need for them to open a listening port. You can then talk SOAP to a GP practice directly and get a HL7 ACK for the message you just sent them. It is a push model and our interface provides a handy "Alive" method that you can try first to see if the interface is available before you try and send.
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. 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? 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. 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" 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 -- Best regards, Andrew mailto:[EMAIL PROTECTED] Andrew McIntyre Buderim Gastroenterology Centre www.buderimgastro.com.au PH: 07 54455055 FAX: 54455047 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
