Hi Stef, Interesting topic I will use the Scottish NHS experience as an examplar of the advantages and limitations I have seen of the messaging based approach.
Scotland (in contrast to England) has never used HL7, opting for a home grown messaging standard, SCI-XML, based on EN13606 and using Read codes as a terminology. We were fortunate in having advice from one of the originators of XML Schema, who at the time was a visiting professor at Edinburgh University. A number of high level COMPOSITION type messages were defined, such as Discharge , Referral, Lab Test and all of these are currently in use. One of the keys to the relative success of SCI-XML was a library of XSD components called general.xsd, which are very archetype like and promote a considerable degree of re-use e.g Medication, Diagnosis, Patient problem. So far, so good!! Now to the problems... These XSD fragments are hand-crafted and there are only 2 or 3 people in Scotland who have the skills and experience to extend the current schema in a coherent fashion, and the demand for new structures or variations far outstrips the capacity to supply. We do have a Data Standards unit NCDDP, whose remit is to define clinical data standards, to be incorporated into vendor products and, of course, SCI-XML but the output of NCDDP is not in any usable formalism that can be automatically mapped to SCI-XML, nor does it use SCI-XML as a reference model. Interestingly, there appears to be a very similar position in Denmark i.e a technical disconnect between the standards documentation and implementation, and I would guess that this maybe an almost universal issue. Although moving to HL7v3 would widen the available skillset, due to the well-known difficulties in authoring clinical content in V3, we would probably be worse off in the significant roadblock in clinical content definition. The NHS England experience of openEHR for clinical content definition is that it has proved far easier than using HL7v3. Even if HL7v3 resolved these difficulties and through better tools or a leaner ref model became clinician-friendly, it is my belief that the archetype 'maximal dataset' approach has a very profound socio-technical effect on modelling and implementation Minimal dataset definitions, as used by most Clinical modelling, whether the Scottish NCDDP or HL7v3 message definitions, work fairly well where a high degree of consensus (or enforcement) can be acheived. Unfortunately, beyond some fairly simple clinical entites, such consensus is often impossible to acheive - a minimum is agreed and anything else is held to be 'out-of-scope'. The problem now is that, in due course, some of these out-of-scope concepts need to be interoperable. Since they are hidden from the shared modelling space, it is likely that there has been even more drift in the way that the new concept has been expressed and re-alignment is awkward and costly. Similarly, new and innovative ideas will have been modelled privately, perhaps by several different vendors/ research teams. By using the maximal dataset archetype approach, we create a shared space where different approaches to a very tightly defined clinical concept can be explored and modelled but always in a highly visible fashion. Genuine innovation can be encouraged, messy semantic overlaps can be discouraged or prohibited. This will be particularly powerful in the currently very difficult area of community multi-disciplinary assessment where consensus is extremely difficult to achieve. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? www.phcsg.org 2008/6/19 Erik Sundvall <erisu at imt.liu.se>: > Hi! > > A couple of months ago a similar investigation was conducted in Sweden > (written in Swedish though). The decision made after the report was > delivered was to go for the EN13606/openEHR approach. > > Formally I believe the decision was EN13606, but I believe any project > with reasonably limited deadlines would benefit from start using > openEHR 1.0.1 internally and then possibly convert to 13606 on demand > if such use cases arise. There is not enough implementation experience > and tools available for EN13606 yet. > > One of the arguments for the EN13606/openEHR approach is that deeper > semantic interoperability requires shared semantics at the point of > entry (not necessarily shared exactly entry user interface though). > Otherwise (if you allow any kind of semantics at the entry point) you > can not guarantee that semantic conversions between entry semantics > and message semantics are algorithmically solvable and thus > technically implementable in a patient safe manner. This is not > obvious to all messaging advocates if the main messages in mind are > traditionally well structured and fairly similar things such as lab > tests etc instead of arbitrary parts of an EHR that are usually > exchanged using faxed papers read by humans. > > This said, having a central 'switch point' is possible with both the > HL7 and openEHR approaches, maintenance of nationally shared semantics > affecting the point of entry will likely be a lot easier using the > openEHR that was designed with that in mind. > > Best regards, > Erik Sundvall > erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 > > > On Wed, Jun 18, 2008 at 16:48, Stef Verlinden <stef at vivici.nl> wrote: >> Dear all, >> >> Could you help me with some clinical use cases to demonstrate the >> differences between an 'EHR' based on standardized messages and an >> EHR based on a standardized information architecture/ reference model. >> >> As you might be aware here in the Netherlands our government has >> chosen, for now, to use standardized messages in combination with a >> central 'switch point'. Basically this provides a communication >> infrastructure which deals with identification and authorization en >> provides a look-up function so data can be found in other systems. >> Data remains de-central in legacy systems and vendors translate their >> legacy data to these standardized messages in XML so those bits of >> information can be shared between the health care providers connected >> to the switch point. >> >> Recently within NEN (the Dutch partner of CEN) we've completed an >> inventarisation with regard to the existing standards in this area. >> Goal is to provide an overview and some guidance for the NEN members >> wrt to these standards. >> >> In short the conclusion is that the HL7 and EN13606 standards should >> be seen as complementary. HL7 has proven it's use for the exchange of >> messages and will be around for some time since legacy systems will >> use this to communicate with each-other. EN13606 defines an >> information architecture which assures semantic interoperability >> between information systems based on that standard. Both systems can >> (and in the Netherlands will) use the 'switch point infrastructure >> and with regard of the exchange of information between information >> systems HL7 v3 can be used as the envelope for the information. Since >> openEHR isn't an CEN/ISO standard yet, we've left this out for now. >> Next year we'll do an re-inventarisation and hopefully we can add >> openEHR to the list (We'll take small steps at the time. This was >> already quite a big step within the Netherlands). >> >> Now there is a request to provide a document which can be used by a >> broader public (especially decision makers, healthcare providers and >> vendors of health care applications/systems) which explains in more >> detail where we're heading for, what choices can be made and what the >> consequences of those choices could be. >> >> Our idea is to explain this with a couple of clear use cases and from >> there zoom in on the technical requirements/ choices to be made/ >> consequences. >> We're looking for use cases for which standardized messages is a >> sufficient solution and use cases for which one really needs >> information systems which provide semantic interoperability. >> >> Of course other suggestions are more than welcome. >> >> Cheers, > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > >
