Aniket
openEHR is ambitious - it aims to provide working solutions. There are two
elements to this that need to be shared
1. archetypes and a tool to look at and propose alterations to these. There
is also a need in the longer term for a comprehensive repository for the
archetypes.
2. what we call the kernel, which is the tool that can help build an
instance of the COMPOSITION (formerly TRANSACTION class) and ensure that the
data instance complies to the archetypes embedded in the composition. This
can operate at a range of points:
a) at write and edit time - allowing constraint of the data to be based
on
archetypes (metadata) rather than application specific processes.
b) at the time the application or schema is created - so that the
application has read all the constrains the data as indicated - but not
through interation with the archetype at runtime.
c) at persistence time - either into a database or some other
persistence
means
d) at communication time such as when creating an EHR extract.
There are potential problems and benefits with all approaches - 'a' makes
'b' and 'c' redundant and allows the application to stay up to date with the
archetype development process. 'b' makes 'c' redundant (potentially) but
means code has to be cut to encorporate new archetypes. 'c' and 'd' mean
that data may be proved incompatible at a time later than data entry and
this may lead to other problems - 'd' means you can carry on regardless but
there is a risk that data collected will not be compatible with models that
are proposed for interoperability.
Aniket - I hope this helps a little. If you want to get involved in building
an EHR system that is based on openEHR, then at this stage you need to get
involved in development of the archetypes and the kernel. We have a
prototype archetype editor at Ocean which we will be putting forward to
openEHR if we get support - I am happy to let you have a go with this and
some candidate archetypes as long as you see it only as a alpha and there is
no guarantee the work you do will be able to be translated into formal
openEHR archetypes - we should be able to guarantee this shortly but there
is a round of reviews to do first and Thomas and I are currently working on
the linking his formal parser and my interface.
You can also learn from what we have done already and build what you can now
with an eye on the future - a lot of people have to do this!
Does this help?
Cheers, Sam
> -----Original Message-----
> From: Gerard Freriks [mailto:gfrer at luna.nl]
> Sent: Thursday, 4 September 2003 5:34 AM
> To: aniket Joshi
> Cc: Thomas Beale; Sam Heard; Dipak Kalra
> Subject: Re: Model Code for EHRs
>
>
> Dear Aniket,
>
>
> OpenEhr is not about an hospital information system but an Electric Health
> Record.
> OpenEHR is participating in work by CEN/TC251 together with HL7 and
> Standards Australia to produce a standard.
> Have a look at www.openehr.com
>
> Gerard
> -- <private> --
> Gerard Freriks, arts
> Huigsloterdijk 378
> 2158 LR Buitenkaag
> The Netherlands
>
> +31 252 544896
> +31 654 792800
>
>
> > From: aniket Joshi <anya_joshi at yahoo.com>
> > Date: Wed, 3 Sep 2003 07:13:18 -0700 (PDT)
> > To: Gerard Freriks <gfrer at luna.nl>
> > Subject: Re: Model Code for EHRs
> >
> > To All,
> > I have been following the EHR development since the
> > past 1.5 to 2 years.
> > We have discussed quite a lot of issues based on
> > variety of subjects.
> > The discussions have been very specific to very
> > bizarre.
> > The whole idea of the discussion is the development of
> > the standard of EHR which I am still not clear as to
> > where are we from our goal.
> > If I have to develop a Hospital Information system
> > based on openEHR guidelines,how should I go about it.
> > DR ANIKET JOSHI
>
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
