Hello everybody, Let me try if I understand this correctly, : An EHR in the openEHR sense holds ALL data about a patient, in archetyped form. As Thomas mentions you then go and "shape concrete expressions" for certain well defined purposes, by combining these pieces in a meaningful way.
USECASE A: openEHR type of EHR in communities with close cooperation In a typical situation today an openEHR type EHR could be situated within a healthcare organization, where all employees fill in data as they provide their special bit of care. Many of this is unstable and intermediate, as caregivers get deeper into diagnosis and treatment, within days or even hours. There is full detail. Some data is not fact, but assumption, to be refined and tested further. This data is often not intended to be communicated outside the own organization. ALL data about a patient is available within a single organisation without severe data protection issues. Finally, at the end of a treatment phase, someone would typically generate a "concrete expression", e.g. a discharge summary, to be used by someone else OUTSIDE the own organization, maybe a resident doctor who continues the treatment of the patient. This is where the data protection laws come in. USECASE B: "message based", between partners who are more loosely coupled What we now think of as a typical "EHR" on a national level, for example in Austria and in the Netherlands, is something different: It does not hold ALL information about a single patient, it just holds the "concrete expressions", e.g. the discharge letters that someone generated for a certain purpose, to be used by someone at a completely different place. Information must be complete, stable and reliable, filtered, and give the complete picture, with interpretations, not too much details, more on the summarizing side. The lawyers and the public healthcare authorities today are used to deal with "concrete expressions", as you find them in this type of communication. Documents are usually signed and legally binding in many countries, and that is the only type of cross enterprise communication that "a wider audience" is familiar with today. Within the next decades we may hopefully see that ALL EHRs change to the openEHR type. There is no way around that, as the healthcare process gets more interconnected, and caregivers become more and more closely coupled, and therefore willing to share intermediate observations that they now need to keep secret. I guess it will take some time to change the heads of caregivers and healthcare authorities. Did I get this right? Comments welcome, and greetings from Austria, Stefan Sauermann -----Urspr?ngliche Nachricht----- Von: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-bounces at openehr.org] Im Auftrag von Thomas Beale Gesendet: Donnerstag, 19. Juni 2008 08:22 An: For openEHR clinical discussions Betreff: Re: use cases I have started a wiki page to help answer some of these questions - see http://www.openehr.org/wiki/display/resources/EHR+versus+Messages I will try to fill this in over the next few days. One important point to note about messages versus EHRs is that messages come from the era of hand-defined content, whereas EHRs, certainly the CEN/openEHR idea of an EHR assumes that content is defined in archetypes that are then used to shape concrete expressions of the information such as in: persistent store, screen view, data capture screens, messages, various forms of output including XML, HTML, PDF and so on. In other words define-once-use-many. Conversions can be made from messages to generate EHR content, some more painful than others. However, as a strategy for the future I don't believe manually defined messages make much sense. They need to be generated artefacts based on archetypes and templates. (The openEHR way of doing this is called the 'template data schema' and has been discussed here recently. Some description of this will go up on the wiki when time permits). - thomas Stef Verlinden 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, > > Stef > > > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > > -- *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> * * _______________________________________________ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
