Re: openEHR
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: <vslee@juno.com>, <hschmidt@tringa.com>
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.
Reply to: