Hello Andrew, I think the discussion is hampered by the lack of reference to the XDS documents. I have looked at them in reasonable depth over that last year or so, and do not feel they are appropriate for the Australian setup. The US has lots of large grouped "Practices" or HMO's and they have what XDS calls "Clinical Affinity Domains" where the patients records are common to many users, and this is why there is no huge security component to the model. The idea is that each department stores its own documents and there is a registry of documents you can query to find where documents exist for a particular patient, and then go out and get documents of interest from a department repository. The documents are often not standards based documents
This is not the Australian setup, In Australia we transfer documents between lots of small "Enterprises" and there is a need for a strong security model. You don't go to a registry and see what is available, and get it, you either are sent it or not, or you find out from the patient that is exists and request it from the source. The XDS model could be used within a large hospital to locate documents that exist in hospital departments and the security model there is part of the organisation's infrastructure. The XDS document specifically states "The placing and tracking of Orders (eg Drug prescriptions, radiology orders, etc) is not supported by XDS." There is no structure for discovery of addressing or what type of information is to be shared, or security. In fact what contents of shared documents are basically blobs, but the framework is orientated to HL7 CDA, which is not in use in Australia. it also states that "The management of dynamic information such as allergy lists, medication lists, problem lists etc is not addressed by XDS". So what XDS is is a system to index unstructured documents with a Clinical Affinity domain with an established trust model. In that domain it functions, but in the Australian Specialist - GP - Hospital domain I cannot see it being a good model. I would like to see Point to point encrypted, authenticated transmission of structured data with rich discovery and trust infrastructure and standards based messaging. In the Web services hype there is a tendency to try and reinvent the wheel. We have a messaging specification that supports Orders and results and medications with atomic data. It is responsible for the majority of Data transmission that occurs today - and it occurs millions of times a day now and seems to work. That is of course HL7 V2, and we already have international and local standards that are published and actually available for free. HL7 is not a document structure it is a full blown messaging specification that has survived 20 years... and will continue to survive because it works. If you want XML documents, no problem, HL7 V2 has well defined XML encoding specs. All we lack is the transport layer to move this around and the terminology and standards on how to use the terminology to achieve more semantic interoperability. wrt your radiology example: HL7 V2 defines an OBX type called a reference pointer that allows (and Medical-Objects has it working now and demonstrated it at HIC 2005) radiology companies to send a link to the DICOM image that can be accessed directly from the radiologist, if you choose to click the link. The IHE document repository actually adds extra layers to this model, for no benefit. For dialup users a store and forward mechanism exists now, there is no need for XDS, for broadband users there is no need for this, why not push the data directly to them? You get assured delivery (or documented non delivery) with no middle man. I agree that not all GP surgeries have the capability of running a webserver, but we have no GPs doing this, we can proxy their SOAP/HTTP interface and they just connect to the proxy and await incoming connections. The client they run is lightweight and they do not have to open firewall ports. My notebook runs three of these clients as part of our beta testing. The proxy function is a service that doesn't involve storing their data and is distributed and replaceable. If they want to open a port on their ADSL model an direct it to our realtime client and avoid the need for a proxy then they can do that as well (It is a SOAP enabled webserver as well as a client of the proxy) With the XDS model you will end up having 100's of repositories that you will have to monitor. The notification in the examples I have seen is often email, so you poll your email server, to be notified of a new document, which means you check the registry and then connect to the repository to collect the data. Its hardly a good point to point model. The next stage, that I would love to see, is live realtime messaging between providers for eg appointment availability etc and XDS doesn't support this at all. XDS adds a ebXML layer to unstructured data in a non realtime mode and underlying it is no security or service discovery infrastructure. Medical-Objects has studied the specification with the initial idea of implementing it, but after reading it closely could not see the value in it, and there are standards based solutions for many of the things it offers large organisations (eg Distributed queries rather than document registries) Debate is needed, but information about what we are debating is the first step. I would encourage people involved in the debate to read at least the first 20 pages of the XDS standard so that we know what it really is. go to this address to find the documentation http://www.ihe.net/ Andrew McIntyre Medical-Objects. Wednesday, May 10, 2006, 4:01:50 PM, you wrote: ANS> Gavan, ANS> Your question regarding whether it is appropriate to use a US-centric ANS> radiology model is very pertinent. The IHE model is, IMO, excellent for ANS> handling the kind of huge blocks of data inherent in the retrieval of ANS> images. Having only a 'manifest' stored centrally makes the process ANS> extremely efficient. That said, the IHE model does offer tremendous ANS> flexibility because it allows the storage at source, or in a centralised ANS> repository. This makes it feasible for pathololgy to *choose* to keep ANS> results on their server, for prescriptions to be centralised, while at ANS> the same time facilitating comms between small providers (such as ANS> specialists and GPs) when neither has the ability to host a repository ANS> in their practice. ANS> I urge all the decision makers in this debate to consider diligently the ANS> implications on small providers and consumers of a SOA/WebServices/IHE ANS> (take your pick) model. Yes, pathology and radiology dominate in terms ANS> of volumes, and no model can succeed IMO without their seal of approval, ANS> but the Holy Grail of interconnecting small players continues to be ANS> overshadowed by grand designs. ANS> Gavan Lim-Joon wrote: >>eClinic has been running a PKI secured HTTPS 'web service' nationally for >>more than five years now for pathology delivery. This particular service >>doesn't need to be online continually, and there are means to interoperate >>amongst providers without the needs for a registry. >> >>I think that what is perhaps missed is the fact that the IHE standards are >>all driven by big US RADIOLOGY vendors who have an interest in setting a new >>industry up (ref http://hl7.org.au/2004-IHE.htm Charles Parisot, Co-chair, >>IHE IT Infrastructure Technical Committee; GE Healthcare). So the issues I >>put are (A) is it applicable to the Australian environment and (B) is >>Radiology the model to use for various health services? That's the debate >>I'm waiting to see happen... >> >> >>--------- >>Gavan Lim-Joon >>Chief Technology Officer, eClinic Pty Ltd >>[EMAIL PROTECTED] / www.eclinic.com.au >>(03) 9381 4567 x106 / 040 234 8186 >> >> -- 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
