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
