> From: Gerard Freriks <gfrer at luna.nl> > Date: Sat, 08 Jun 2002 17:54:55 +0200 <snip> > CEN started to standardise message components. Lego bricks. </snip>
The issue of standardised components raises very interesting issues. There are three different types of reusable element that we need to consider: 1. Reusable Business Patterns. These are sub-function type requirements specifications, including use case and business information model, written in a way to encourage re-use in requirements specifications. 2. Reusable Design Components. These are reusable chunks of design specification (using a common architecture) which can be reused. CEN GPICs and HL7 V3 CMETs seem to both fall into this category (and need to be brought together). 3. Reusable Technology Components. These are reusable chunks of technology-specific implementable specification. A good example is provided by XML complex types within a referenced name space, which have been developed specifically for reuse. There is a clear relationship between these three types of reusable element, but there is not a strict one to one mapping across them. They are not all different aspects of the same Lego brick. They each are used by different people to do different things. There may be a relationship between them, but that is not necessary to achieve the major benefits of reusability. When someone offers me a Lego brick, I want to be quite clear whether it is a reusable business pattern, a design component or a technology component. The predicted market for software components failed to grow as forecast during the 1990s simply because the software components were just offered as technology components (have widget, just pay me and then use it for whatever you like), and not anchored in a common design architecture that dealt with semantics properly, nor on business patterns. If standards (including standards for reusable elements) are properly anchored in specific use cases, then we can rid ourselves of a great deal of the bloated optionality which is the curse of so many otherwise good standards. Tim -- Tim Benson Abies Ltd, 24 Carlingford Road, London NW3 1RX, UK +44 (0) 20 7431 6428, tb at abies.co.uk > > My focus on narrative texts (the EHR) is obvious. > In medicine physicians exchange more than objective information and give > orders. They narrate the medical story of their patient, their thoughts and > deliberations about all the objective events that all constitute the EHR. > It is a personal account of a journey travelled together by the patient, its > relatives, and the healthcare provider. > In general it is NOT a narrative to be shared by many. The medical record is > a personal, subjective document. It is a narrative for personal usage. When > information is to be shared the author will select and rewrite parts of his > notes in order to meet a specific request by an other healthcare provider. > This is the way people work. This is the way healthcare providers know how > to work with using paper systems. > I can see that objective information (orders, test results) can be shared by > all without real problems. But people (good healthcare) will need subjective > narrative as recorded in their personal Medical Records. > Personally I don't believe in one all encompassing, fulfilling all needs for > all, Medical Record shared by all; now and in the future. > > Gerard > > > > On 2002-06-08 01:27, "Tim Benson" <tb at abies.co.uk> wrote: > >>> From: Gerard Freriks <gfrer at luna.nl> >>> Date: Fri, 07 Jun 2002 21:46:28 +0200 >>> >>> I want to separate CEN from HL7. With CEN we focus on Documents with >>> narrative in a structured form either stored or transported between persons. >>> HL7 (v2 and v3) are about messages exchanged between databases for logistics >>> purposes. They contain no real narrative. >> >> This comment seems to point to a mis-conception about what HL7 is doing now >> and what CEN has achieved over the past 10 years. Most existing HL7 >> implementations could be described as logistical, but the same is equally >> true of CEN implementations. Indeed the work has proceded in parallel with >> a good deal of duplication of effort. >> >> It is quite wrong to characterize the present work of HL7 as being "for >> logistics purposes" only. HL7 has about 30 different technical committees >> and special interest groups, and while some do have a logistical focus, many >> do not. The scope is so wide that few people have a full overview of all >> the work that is going on. >> >> I am not quite sure that I understand why you focus on the narrative >> perspective as being so crucial. Ideas about story-telling and narratology >> have been useful in understanding some of the ways in which GPs in >> particular use (and misuse) medical records, but they only illustrate one of >> the ways in which records are used (and these are mostly the ones where >> computability is least important). The primary use of narrative to to >> provide something that can be understood by a human being, while the value >> of structure is to have something that is computable. >> >> It is quite easy to produce a medical record which meets these requirements >> for a SINGLE group of users (such as GPs), but it is a different thing >> altogether to solve the problem for MULTIPLE groups. It is not the >> narrative that creates the problem, but the structure. Most structures use >> a version of a tree-like hierarchy, which can only support one perspective. >> The way forward is to use structures which support MANY different >> hierarchical structures at the same time. >> >> The key word above is MANY. Existing systems support several ways of >> looking at a medical record. Indeed the Abies GP system of 15 years ago >> allowed the user to view the record according to different types of date, by >> patient problem and by about 20 pre-defined characteristics (medication, >> diagnoses etc) and by groups of coded entries (using the Read Code >> hierarchy). Indeed the indexes for any medical record contained perhaps ten >> time as many entries as the record itself. This worked rather well for GPs, >> but did not migrate too well into secondary care, where there are multiple >> and conflicting ways that different groups wanted to look at the data. The >> solution to this problem is the evolution of virtual records for each group >> of users, based on their own specific use cases. But this has little to do >> with narrative... >> >> Kind regards >> >> Tim > > -- <private> -- > Gerard Freriks, arts > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > > +31 252 544896 > +31 654 792800 > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
