-----Original Message----- From: Parisot, Charles (GE Healthcare) [mailto:[EMAIL PROTECTED] Sent: Thursday, 11 May 2006 10:24 PM To: [EMAIL PROTECTED]; Werner Van Huffel; [EMAIL PROTECTED] Subject: RE: [HL7Info] Re[2]: [GPCG_TALK] IHE and XDS - sharing of documents and
Peter, I am no longer in San Antionio. I had to leave on Tuesday for the European ministers eHealth conference where I was invited to speak on IHE.. Two different issues are raised. On security this may be coming from folks nor realizing that IHE does not deliver a monolyth profile (the magic XDS to do everything) but a set of related Integration profiles that complement each other, but allow flexibility. The minimum is XDS+ATNA+CT. This provides time such for spoofing avoidance, digital certificate base node authentication and on the wire encryption. A rather solid basis. The next profile adding user authentication is in development and will leverage the fact that XDS is web services based to apply and profile the upcoming sercurity profiles from OASIS and WS-I. These standards are not completetd yet, but will be by year yend, so expect that to be addressed by early 2007. This is what we call XUA. But deployment can start without XUA along with the proper policies. For V2, the 100% of EHR vendors that support IHE for regional and national programs are not dummies and all realize the huge installed based of HL7. Mapping HL7 V2 to CDA is mangeable, and is actually the right thing to do. Mapping HL7 V2 to HL7 V3 is hard and will take some time .... So CDA is the transition to the world of V3 with minimal pains. Hope this help. If you want we could have a t-con with those folks who are asking the good questions that have already been asked and answered. - Best Regards - Salutations Charles Parisot Mgr Standards and Testing _______________________________________________ GE Healthcare Integrated IT Solutions Visit Us On The Internet: http://www.gehealthcare.com Enterprise System Solutions GE Interoperability & Security HL7, IHE, DICOM, etc. http://ge.com/interoperability Charles Parisot: Phone : +33 130 70 99 77 mailto: [EMAIL PROTECTED] _______________________________________________ -----Original Message----- From: Peter MacIsaac [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 4:59 AM To: Parisot, Charles (GE Healthcare); 'Werner Van Huffel'; [EMAIL PROTECTED] Subject: FW: [HL7Info] Re[2]: [GPCG_TALK] IHE and XDS - sharing of documents and The debate on IHE is hotting up, on the GP list. This response from a communication vendor claims that there is an insufficient security layer for XDS to work in Australia and questions the model. I think he is also saying that we send messages in HL7 V2 and don't use CDA so it wont work and that we want to do more things semantically with the data like central allergy registers. Charles, who was the security expert at the IHE technical workshop on XDS? Are you available to have a chat while we are still in San Antonio. Regards Peter MacIsaac MacIsaac Informatics Consulting in Health Informatics, Terminology & Data management and Health Policy. [EMAIL PROTECTED] 0411403462 (mobile) 61611327 (office) peter_macisaac (skype) 8 Ewart St. Yarralumla 2600 "We trained hard, but it seemed every time we were beginning to form up into teams, we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising, and a wonderful method it can be for creation the illusion of progress while producing confusion, inefficiency and demoralisation." - From Pertonii Arbitri AD 66, attributed to Gaius Petronus, a Roman General who later committed suicide. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew McIntyre Sent: Wednesday, 10 May 2006 10:45 PM To: General Practice Computing Group Talk Cc: [EMAIL PROTECTED] Subject: [HL7Info] Re[2]: [GPCG_TALK] IHE and XDS - sharing of documents and 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 ANS> US-centric radiology model is very pertinent. The IHE model is, ANS> IMO, excellent for ANS> handling the kind of huge blocks of data inherent in the retrieval ANS> of images. Having only a 'manifest' stored centrally makes the ANS> process extremely efficient. That said, the IHE model does offer ANS> tremendous flexibility because it allows the storage at source, or ANS> in a centralised ANS> repository. This makes it feasible for pathololgy to *choose* to ANS> keep results on their server, for prescriptions to be centralised, ANS> while at the same time facilitating comms between small providers ANS> (such as specialists and GPs) when neither has the ability to host ANS> a repository in their practice. ANS> I urge all the decision makers in this debate to consider ANS> diligently the ANS> implications on small providers and consumers of a ANS> SOA/WebServices/IHE (take your pick) model. Yes, pathology and ANS> radiology dominate in terms of volumes, and no model can succeed ANS> 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 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.2/330 - Release Date: 3/05/2006 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.2/330 - Release Date: 3/05/2006 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.2/330 - Release Date: 3/05/2006 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.2/330 - Release Date: 3/05/2006 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
