Ross Davey wrote: > > Tim Churches wrote: >> Andrew N. Shrosbree wrote: >> >>> Tom, >>> >>> You evidently did not understand a word of what Ross said at the >>> conference. >>> >> >> What did Ross say at the conference? >> >> Tim C >> >> > Tim, > > The 'Workshop' was hosted by HL7 Australia as a forum for technical > people to share information about the practicalities of implementing Web > Services and SOA, and to share ideas on architecture, experiences and > opinions. > > I was asked by the organisers to present a model which I have put up for > discussion in other forums because they wanted to encourage discussion > about interoperability. The model that I presented was a reflection of > a model for passing documents which closely follows the Intergrated > Healthcare Enterprise (IHE) initiative (see www.IHE.net) that has been > advancing in the U.S. and gained a lot of respect. They started > with the radiology industry but now are expanding across all of healthcare. > > I only had a few minutes to present so the presentation was a very cut > down version. > > Basically this model conflicts with current NeHTA inclinations where > they prefer a model whereby they will encourage multiple providers of > message server 'hubs' (like HealthLink and eClinical et al) to negotiate > to intercommunicate and pass messages that they receive on to another > 'hub' provider if the recipient is a client of the second hub provider. > > Now I contend that this model has some serious technical challenges in > the protocols and methods for interchange of messages (yes I know we > demonstrated that it could be done at the last HIC conference when we > partcipated in the 'IHE Connectathon' there, however when you scale it > up the problems increase exponentially), but also the business > processes/rules for charging or not charging the client will be very > hard to resolve. > > On the other hand, the IHE model avoids all this complexity by a process > using what they call a 'Document Register', but even more importantly it > allows any message service provider (such as HealthLink) to interoperate > with all clients and other message service providers without the > complexity of needing to interchange the messages between 'hubs'. ie > the IHE model is a win for everyone. > > In lay terms, the Message Register allows a message service provider > (termed a 'Message Repository' in IHE) to 'advertise' that a message is > waiting for a particular healthcare provider, and where it is located. > Then the healthcare provider's software simply goes to the correct > 'Message Repository' (which could be HealthLink) to pick up the message. > > HealthLink should be very happy with this model because it allows them > to retain the ability to have 'control' over the entire message route, > from sender to receiver; which is a benefit that they keep selling as an > advantage of their service. The message would not go through anyone > else's hub. With a 'hub-to-hub' message routing model > HealthLink are not able to give this assurance because at some time they > would need to pass the message to someone else.
A few criticisms of the IHE model you propose: 1) It represents a single point of failure for all health message delivery. This is also a problem with teh hub-and-spoke model used by many of the messaging providers. One backhoe[1] taking out the fibre-optic trunk and healthcare grinds to a halt. Thus redundancy is needed: those organisations running servers would need to send notifications that a message is available for collection to not just one "document register" but several (and not just one which is mirrored to several others, as that would still be vulnerable to a backhoe). The client software then needs to know that if their primary document register is not responding, that they need to fail over to their secondary register to poll for messages to be collected. Then the document registers need to update each other with respect to the message notification and collection status. It's strating to look a bit complex... 2) Obviously client systems eg GPs need to authenticate to organisations running servers/services in order to be able to collect or deposit their messages (and only their messages). Do client systems also need to authenticate to the central document register(s)? If not, then the fact that documents/messages are available for collection will necessarily be publically readable, and this may leak information which is commercially or personally sensitive or confidential. If authentication is envisgaes, this is yet another set of credentials to maintain and keep synchronised - or is a single, shared credentially/authentication system envisaged? 3) Your presentation asserts that polling of service providers to determine whether new messages are available for pick-up is undesirable or impractical. Is it? The set-up/respond/tear-down time for a connection from a general practice to, say, a path provider server to determine whether there are messages waiting should be well under 10 seconds, and there is no reason why many such polling connections cannot be initiated from a client system at once - TCP/IP allows this - the polling doesn't have to be done in a serial fashion. The actual bandwidth needed for such polling should be very small. Thus, each practice could easily poll many hundreds of service providers every minute without putting a strain on anything. In practice, most GPs won't deal with more than a few tens of different service providers who might need to send messages to them. I am strongly in favour of the fully distributed, decentralised approach, with no single point of failure - which is the model adopted by Argusconnect. I don't see any need to give that away in teh move to Web services by interposing a centralised "document register". Tim C [1] Sydney-dwellers may recall the block of home units which partially collapsed into a hole in the ground which had been inadvertently opened by groundwater seepage caused by tunnelling for the Lane Cove road tunnel. As I drove past the site of the (minor) disaster on my way home, I was curious to see that Telstra vans outnumbered all the other emergency response vehicles present. I asked a friend with telco connections why - answer was that, apparently, BOTH of the main northern fibre optic trunk cables happened to cross the hole, and both were dangling in the breeze. It was pure luck that they were not damaged in the collapse - had they have been, much of the top right hand corner of Australia would have been blacked out as far as digital communication was concerned for quite some time - rather worse potential consequences than were reported here: http://www.crn.com.au/story.aspx?CIID=25501&src=site-marq There is a lesson to be learnt there, I think, and much to be said in praise of distributed, point-to-point services. TC _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
