Tom Bowden wrote: > > > 1. PMS Requirements v1.3 :- > > http://www.healthlink.net/Special_Authorities/SA-PMSReq13.pdf
OK, thanks Tom. An interesting document - it details a Web service through which a GP PMS (practice management system) is able to request approvals for special authority drugs - an approach which is MUCH better than having to fill in an HTML form, as it allows fairly tight integration with the clinical software system in each practice, avoiding the need for rekeying or cutting-and-pasting data. If I understand it correctly, HealthPAC, which is the NZ govt authority responsible for regulating and approving authority drugs (I think) issues a monthly list of authority drugs and an associated set of criteria, as an XML file. Each PMS must import this list and process it so that when prescribed by the GP, the PMS recognises that an authority to prescribed is required and it displays an HTML form asking the relevant criteria questions for that particular drug. HealthPAC provides an XSL stylesheet which converts their criteria XML into an HTML form to be rendered by the PMS in order to collect the necessary criteria information from the harried GP. The PMS then generates the appropriate HL7-in-XML document, digitally signs it, encrypts it using HealthPAC's public key and wraps it in a SOAP wrapper. The PMS then contacts the Special Authority Web service and synchronously sends the authority application and waits, still connected to the Web service, for a reply. If no reply, it just retries until it succeeds. Thus there is no need for the GP system to act as a server, just as a client and it does not need to be online 24x7. The GP PMS/clincal system needs to handle the situation in which the Special Authority Web service is down or offline, or when it does not reply in the specified time period. There is no store-and-forward facility or ability for the GP's system to deposit applications in a queue for HealthPAC to process when its Web services come back on line. All this communication must occur "via a network approved by the Health Intranet Governance Body. Currently the approved network providers are Telecom New Zealand (providing the Health Express product) and Healthlink (providing the SecurIT product)." As noted, a pervasive PKI is also necessary. Now, if all this does indeed work nicely, as Tom tells us it does (and I have no reason to disbelieve him), then it begs the question: Why can't this model be turned around and be used for results and reports delivery to GPs? The GP's system needs to provide a HTTP server accessible at an Internet URL, and this Web server handles Web services requests for delivery and receipt of results and requests from path labs, radiologists, specialists or hospitals (eg discharge referrals). The sender acts as a client, and if the recipient GP Web service is not contactable or doesn't confirm receipt, then it retries for a defined period then falls back to alternative deliver methods if the urgency of the results or report warrants it eg faxing, courier delivery of paper results or snail mail. The electronic version of the results or report could still be retrieved later by the GP system (or sent to it later) when the GP system comes back up online. The nice features of this model are: a) All communication is peer-to-peer. No middlemen, no toll gates, no single point of failure. b) The sender gets immediate status information about the delivery of the report or results, and can take appropriate alternative action if necessary. c) The software machinery for all this is now readily available as .NET, Java, Python etc libraries. The downside is that there is no store-and-forward mechanism, so that quite a lot of retrying is needed if a GP or other service provider Web service is offline or down. However, retries only occur when Web services are offline, and I suspect that the total volume of retries might be less than the volume of polling requests in the IHE model which Ross Davey advances. Also, the lack of store-and-forward can be seen as an advantage because it allows for immediate delivery status tracking by the sender, all the way to tthe recipient clinical information system , a feature which Tom Bowden constantly reminds us is very important. It is easy to conceive of each Web service (eg for each practice) publishing a list of alternative delivery mechanisms to be used for urgent information (fax, SMS etc). Sending parties could use those alternative routes if the Web service to which they are trying to send is down and the information they are trying to send or have processed or acted upon is urgent. Necessary infrastructure for this to work: 1) A pervasive X.509 PKI, with an associated human- and machine-readable directory of the people who work in each service provider (eg GP practice), their human-relevant contact details (phone number, snailmail and street addresses etc), and the URLs of teh Web services which they expose to the rest of the world. 2) Health service providers such as GPs need Internet connections with fixed IP addreses to allow them to run a Web services server - not necessarily 24x7, but at least during office hours. This implies a suitable firewall/Web server at the edge of their practice LAN on which the Web services can be run, and the necessary SOAP interfaces between their clinical applications and those Web services. I suspect that if this model became popular, more and more practices would run 24x7 Web services. But if they didn't, it would still be functional. Why is all this better than using SMTP to securely deliver documents? Because Web services can do more than just send and receive documents such as path results. The NZ authority drug application illustrates this. The GP system is effectively asking via a Web service RPC (remote procedure call) "Can I prescribe this drug to this patient for these reasons, can I, huh, please, pretty please, what's your answer, tell me now?" and immediately, the govt authority responds "Hmmm, everything seems to be in order, so yes, you may and here's the authorisation number." (Or it may respond "<cough> Computer says 'no'"...). OK, there is not a lot of on-the-spot value-adding by the govt authority in this example, but you get the idea. This sort of conversation could be carried out via SMTP store-and-forward email messages, but the more involved and complex the conversation between the parties, the more difficult that becomes. So thanks to Tom Bowden and Healthlink for providing a nice example of peer-to-peer, no-middle-man, no-single-point-of-failure Web services in health. Bring it on, I say. Apart from progressing the establishment of the necessary infrastructure as described above, and finalising or at least fleshing out the Web services framework it has described so far, the best thing that NEHTA could do would be to commission the creation of a set of "reference" software implementations of the Web service server and clients ends, for a number of software frameworks/platforms (.NET and Java are obvious ones, and I would add Python as a good cross-platform third bet), and release these reference software implementations under a suitable open source license which allows clinical software vendors to freely incorporate the reference implementation code into their products. This saves everyone from having to build their own implementations to the NEHTA Web services specs, and thus would promote consistency and adherence to those specs, as well as providing a level playing field which actively promotes competition. The cost of creating open sourced reference implementations of Web services servers and clients should only be in the hundreds of thousands or low millions of dollars (since much of the machinery is already available in standard or free SOAP libraries) - maybe much less. That would be nirvana for mice, I think. > 2. HL7 Definitions v1.6:- > > http://www.healthlink.net/Special_Authorities/SA-HL7Def16.pdf Sorry, I have to deal with HL7 2.x as part of my day job, which is enough to induce a severe dysthmic reaction (the HL7 2.x, not my day job). Reading yet more HL7 2.x specs on a Saturday morning would be risking my mental health, I fear. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
