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 -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
