Were HL7 messages exist and are working, we will continue to consume them using the TDS intermediate form. As stated previously, the TDS is not intended for information exchange, but as a tool for integration.
Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Tim Cook > Sent: Tuesday, 27 November 2007 11:11 AM > To: For openEHR technical discussions > Subject: Re: Compact XML format...? > > Hello Hugh, > > Thanks for the reply. > > I think we have a communications issue though. My questions/comments > weren't about the technical aspects. > > As I understood the proposition. It was to encourage other system > vendors to create these templates in order to communicate with an > openEHR based application. > > My argument is that the world of healthcare data exchange has been built > (so far) on HL7 v2.x If my understanding of your proposal is correct > then I will argue that we will have very little success in getting these > vendors to incorporate a message format for openEHR. I believe it is > better to just continue doing what you are now by consuming HL7 > messages. > > Again, I "think" we are saying the same things but I'm not positive. :-) > > Cheers, > Tim > > > > > On Tue, 2007-11-27 at 09:12 +1100, Hugh Leslie wrote: > > Hi Tim > > > > Yes, I absolutely agree with this - our tools are capable of receiving > > V2 messages and producing openEHR data - we did this at MedInfo for > > the interoperability demo. The problem with V2 is that the ability to > > put clinical content in there is limited (which is why all the work on > > v3!) and so we are also working on these other methods. As I said > > previously we are currently capable of creating and sending CDA R2 > > messages from openEHR and so as soon as there are applications out > > there capable of receiving them, we are capable of sending. > > > > regards Hugh > > > > Tim Cook wrote: > > > Hugh, Tom, Heath, et.al. > > > > > > I agree that openEHR systems MUST interact with everyone else. I also > > > agree that MOST healthcare information providers only have a small > > > segment of healthcare information to consider. I agree that if we (as an > > > openEHR community) do not work with the broader, more established world > > > we will be isolated (no matter that our approach is superior :-> ). > > > > > > However, (I always have a BUT or a HOWEVER to present) "I do think" that > > > it is more prudent to do these translations INSIDE an openEHR > > > implementation instead of trying to coax outside entities into doing > > > them to communicate with openEHR implementations? > > > > > > A different approach says that; openEHR can translate ANYTHING thrown at > > > it via these really cool translations (TDS?). Instead of trying to get > > > various vendors to support our (strange) formats that they do not > > > understand. > > > > > > We certainly know that not many vendors are providing HL7 v3 messages at > > > this point. Shouldn't we concentrate on providing HL7 v2 lab, rad, etc. > > > input to EHR's/PHR's instead of trying to convince the uninformed world > > > that they should be giving us openEHR EHR_Extracts or even transformed > > > XML data? > > > > > > Thanks, > > > Tim > > > > > > > > > > > > On Mon, 2007-11-26 at 20:25 +1100, Hugh Leslie wrote: > > > > > > > I also think the problem is that we have to accept the pragmatics of > > > > the current situation in health care where companies are not > > > > immediately going to re-engineer their systems to become openEHR > > > > compliant, no matter how much we would like that. In time, many > > > > companies will re-engineer their software, and other new applications > > > > will arrive on the scene that are fully openEHR compliant. > > > > > > > > In the meantime, this pragmatic approach allows for archetypes and > > > > templates to completely model clinical medicine and to enable everyone > > > > to participate at, initially, minimum cost and effort. The exciting > > > > thing about the openEHR approach, is that these Template Data Schemas > > > > are not hand coded, but are generated directly from templates and > > > > archetypes using tools. In Australia, we are using this approach to > > > > enable the completely tool driven generation of CDA R2 documents > > > > (because in a pragmatic world, we have to interact with everyone!) > > > > with data going both in and out of CDA. Of course we are doing this > > > > with openEHR as well. > > > > > > > > Hugh Leslie > > > > > > > > Thomas Beale wrote: > > > > > > > > > Rong Chen wrote: > > > > > > > > > > > > > > > > Hi Heath, Tom and others, > > > > > > > > > > > > I clearly see there is a need for TDS based integration. But I am > also > > > > > > concerned with the side-effects of it. By offering this 'easy' way > of > > > > > > integrating openEHR systems, we make it possible for vendors to > ignore > > > > > > the 'hard' way of integrating openEHR systems using archetypes and > the > > > > > > generic RM. As you have indicated TDS doesn't contain all the > > > > > > semantics of the archetypes and RM, some semantics will be forever > > > > > > lost when data are received using TDS. Without the knowledge of > > > > > > archetypes and RM, some intelligent use of the data won't be > possible, > > > > > > e.g. AQL queries of the data. > > > > > > > > > > > > > > > > > This unfortunately is a purist view. I know - I used to have it ;-) > > > > > Realistically, many vendors of software used in places like > laboratories > > > > > will only use simple XML or other message-based solutions - they just > > > > > will not go into the nice theories or modelling that we are interested > > > > > in here. So the TDS approach is designed to allow them to have a > simple > > > > > schema (i.e. with tags they understand) whose instance data is > > > > > guaranteed to map directly into a proper openEHR server. THe > developers > > > > > who build that software just have to generate conformant instance, and > > > > > there is nothing else to do. The data are not widely usable until > > > > > converted into openEHR form, which is why this approach is really only > > > > > appropriate for source systems feeding to an EHR system. But - that > > > > > might be 50% or more of all health information communications in the > > > > > world, so it is a major use case. > > > > > > > > > > > > > > > > Also one-template-one-schema seems to imply software changes > whenever > > > > > > new templates are introduced. > > > > > > > > > > > > > > > > > well it might at their end, e.g. if the lab wants to create a new lab > > > > > message, but that's what they expect. This is good economics of > software > > > > > building for such vendors. > > > > > > > > > > > > > > > > Such changes will not be necessary if the openEHR RM can be mapped > > > > > > directly into a generic internal model, which is constrained in > > > > > > runtime using semantics in the archetypes/templates. So even it > seems > > > > > > to be harder than TDS based integration, it does offer full benefits > > > > > > of using archetypes and makes the system more adaptive. > > > > > > > > > > > > > > > > > > > > > > > Yes, but only some people want adaptive systems. It all comes down to > > > > > software engineering economics. If your system only generates 25 > > > > > different pathology result messages which change very little over the > > > > > years (as is true for the basic biochemistry, bloods, micro etc) then > it > > > > > doesn't make any sense to build a fully adaptive generic system; it > will > > > > > be far cheaper to more or less hard-wire the messages into some part > of > > > > > your software. For such vendors, the main game isn't the diversity or > > > > > rate of change of the content, it is the volume of throughput, > security, > > > > > uptime and other such issues that are far more important - as would be > > > > > for the case for any large lab company with a contract with e.g. a > > > > > regional or state government health service. The semantics are not the > > > > > most important thing for suppliers whose systems only deal with a > > > > > relatively small section of health data types. > > > > > > > > > > - thomas beale > > > > > > > > > > _______________________________________________ > > > > > openEHR-technical mailing list > > > > > openEHR-technical at openehr.org > > > > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > > > > > > > > > __________ NOD32 2685 (20071126) Information __________ > > > > > > > > > > This message was checked by NOD32 antivirus system. > > > > > http://www.eset.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ________________________________________________ > > > > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > > > > Clinical Director > > > > Ocean Informatics Pty Ltd > > > > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: > > > > www.oceaninformatics.com > > > > > > > > _______________________________________________ > > > > openEHR-technical mailing list > > > > openEHR-technical at openehr.org > > > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > > -- > > ________________________________________________ > > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > > Clinical Director > > Ocean Informatics Pty Ltd > > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: > > www.oceaninformatics.com > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- > Timothy Cook, MSc > Health Informatics Research & Development Services > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
