Vergil Slee wrote: > Are you familiar with this? > I believe this is another example of a label change.... (GEHR vs OpenEHR) (pardon lack of formatting -- it looks better in Folio)
=========================== Good Electronic Health Record (GEHR) - http://www.gehr.org/; GEHR also = Good European Health Record; site has a great FAQ [http://www.gehr.org/introduction/faq-1.html] that also lists other EMR initiatives; Correspondence - References 2 May 2002 - DAS - Subject: GEHR cites us To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: GEHR cites us check out the footnote on page 20: http://www.gehr.org/gpcg/OACIS/Hospital_GEHR_Transformation.pdf 23 Aug 2001 - from vns; Subject: Neat lines I've been prowling re GEHR and GALEN. Each has a neat "subtitle" which would add spice to the definitions. GEHR plans to be built with "future-proof software," e.g., the list of diagnoses can grow forever and not reach the limits of the archetype model software that Beale has been proposing. GALEN purports to be "making the impossible very difficult" That's cool, for my money. Love, Dad 22 Aug 2001: vns, Re: GEHR/Open Source medical record - update This is just to give you the address for a tech piece on how GEHR is thinking http://www.gehr.org/technical/archetypes/gehr_archetypes.html There's a pdf file there. This is about their archetype methodology, which is "how to future-proof information systems. What is GEHR? (Aug 2001 - dl from their web site) The Good Electronic Health Record: An innovation in software engineering for the benefit of patients. The Good Electronic Health Record (GEHR), a major part of the work of the openEHR Foundation, is an evolving electronic health record architecture designed to be comprehensive, portable and medico-legally robust. It has been developed from the Good European Health Record project requirements statement and object model - the most comprehensive requirements documents ever developed for the electronic health record. The Good Electronic ( nee European) Health Record is an open information architecture which formally expresses a set of requirements about patient health records. It is ultimately designed to be used by software developers as the starting point for application and system development, since software is the concrete embodiment of such an architecture. The advent of GEHR offers something new in the health informatics domain: the possibility for any health care facility (HCF) of being able to a) use health record software from different vendors on the same record data, and b) send and receive electronic health care records to other facilities . The original Good European Health Record project was a European Community project 2014 funded under the AIM (Advanced Informatics in Medicine) umbrella - it ran from 1992 until early 1995. The project developed an architecture for electronic health care records, which aimed to embody clinical, ethical, legal and computational requirements. Deliverable 19 of the GEHR project described the health care record information structures using a pure object-oriented formalism, a form expected to be suitable for implementation of standards-compliant software, and for electronic exchange of records. Due to changes in 1995 to the way European projects were funded and the advanced nature of the architecture, the GEHR work remained unchanged for some time. The Synapses and Support Action (EHCR-SupA) projects have added to this work. GEHR Standard status (it isn't yet, as of Aug 2001) GEHR-related standards proposal work is being continued by the Support Action project, and by a number of groups in Europe and Australia, co-ordinated by the original team at the Centre for Health Informatics in Multi-disciplinary Education (CHIME), located at the Whittington Hospital in London. The aim is to have the GEHR proposal accepted as a standard for use in Europe, Australia, and eventually, internationally. Other GEHR work, such as the Australian work (the subject of this document), and the Synex project (at CHIME) are continually improving the GEHR standards offering. GEHR Criteria for a Patient (Medical) Record Clinical information is complex ; compromises in the way the health record works should be in favour of availability and usability for the clinician recording a patient contact. [Del19-3.2.1] Growth and innovation in medical, clinical and general sciences, as well as public health and the cultural place of health care must be accommodated. [Del19-3.2.1] The record is important as a patient history device. [Del19-3.2.2] The record promotes clinical competence on the part of the care-giver: delivering care, organisation & planning, education, training, learning, QA; it also encourages the moral and ethical aspects of clinical care. [Del19-3.2.3] The record has a multitude of possible uses. [Del19-3.2.4] The record has a multitude of possible users. [Del19-3.2.4] The model is powerful enough to represent diverse information , including structured text, measurements, multi-media data, coded terms & classification, and unstructured information. [Del19-3.2.7- Expressiveness; also precision and uncertainty Del19-3.2.5, 3.2.6] GEHR: Open Standard (= "public domain" -- less restrictive than "open source") Open standard : any prescription for a health record architecture should be freely available, and not owned by corporate interests. This ensures that a) implementors wishing to use it may do so freely, and b) that the evolution of the standard continues to reflect the best interests of clinical practice, rather than the economic imperatives of a particular company. For these reasons, all GEHR deliverables are in the public domain. This requirement was not stated explicitly in [Del19] but was the common viewpoint of all parties who took part in the GEHR process. Existing GEHR implementations (Aug 2001) There is one commercial implementation of a GEHR-like application - HDMP's HEALTH.one - and some partial implementations of GEHR principles, including WinGEHR by Instituta Clinica Geral Zona Norte in Portugal and an implementation by Hull University Department of Computer Science. Implementations are also under development in New Zealand, Italy, Romania and South America. An Australian initiative began in late 1997 with the establishment of Ocean Informatics, which is evolving the formal model ideas of Deliverable 19 toward a high-quality GEHR "record engine" or "kernel". These implementation efforts have thrown new light on a number of the original GEHR ideas, and are influencing its further development. What is the GOM? Since the GEHR architecture proposes to standardise electronic health record information produced at and shared among health facilities, its primary statement is a description of information structure and semantics : the GEHR Object Model, or GOM. An initial GOM was proposed in Deliverable 9 of GEHR, but was recognised as requiring further work. In a nutshell, the model states the common information structures which must be adhered to by a piece of generating software if it is to guarantee that any health record it creates can be read by another piece of GEHR-compliant software, thus enabling: Vendor independence : different software applications (particularly from different vendors) at a site can read and write the same record; Storage medium independence : the record can be stored on any persistence mechanism supported by the standard, including files and client/server databases; Exchange : the record can travel to other GEHR-compliant sites via any exchange medium supported by the standard, and be read there. Since there are many, sometimes competing, requirements of the GEHR architecture, the requirements document (The GEHR technical requirements) clarifies these into a set of terse, consistent, technical requirements by which the GOM may be judged. GEHR vs HL7 The predominantly US-based HL7 approach describes a messaging standard; the 2.3 version of the standard is widely implemented in the US and increasingly in other countries such as Australia and New Zealand. Version 3 of HL7 recognises the shortcomings of the version 2.x offerings, by approaching the messaging problem from an information modelling standpoint. Version 3 consists of a number of deliverables: The Reference Information Model, or RIM, the definitive formal statement of HL7 v3 semantics, covering all aspects of the clinical care process, including administration, scheduling and billing. The Unified Service Action Model, or USAM. This is the clinical part of the RIM, and proposes a highly abstract model based around the concepts of "service" (health care actions) and "material" (real world things such as measurement devices, which are the objects of actions). The Patient Record Architecture, or PRA. This is an initiative to try and codify empirical clinical models into XML DTDs. The primary advantage of HL7 v2.x is that it has many extant implementations, and has therefore been widely "road-tested". HL7 v3 has not been finalised, and has not yet been implemented, but is dedicated to retaining the lessons learned from its predecessor. GEHR is in the process of assimilating ideas from HL7 v3, and is actively enagaged with the developers of HL7 in harmonisation initiatives. Areas of the HL7 v3 model with which GEHR can be directly compatible include data type definitions (such as "quantity", "concept descriptor" etc); it is expected that equivalences can be found between the concepts in the GOM and USAM+RIM, and also between the PRA+RIM and the GEHR archetypes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
