in SQL, there are actually 2 models , the DDL, and the DML;  with DDL one can create and constrain a schema,

and with DML one can use it.

In XML there are actually 2 models, the XSD, and the XML; withe the XSD one can create and constrain a schema,

and with XML one can use it.



On Mon Jan 2 7:43 , "Hugh Leslie" sent:

Hi All

> Tim Churches wrote:
> Richard Hosking wrote:
>> Reading the OpenEHR site again - they are progressing and seem to be
>> the best candidates for an information model. There is 20 years of
>> research behind the concepts. Unfortunately they are using Java,
>> Eiffel, and C#, but the info is open (Mozilla license - is this a
>> problem?)

There is a lot of openEHR development going on in a lot of different
development environments. Indeed on the openEHR website you can find a
mixture of Java, Eiffel and C# and some MySQL db schemas. openEHR is
completely development environment agnostic and the only requirement is that
all the software conforms to the open source specification.

> The currenly available openEHR tools are all for creating and
> validating Archetype definitions. The choice of languages is not
> really a problem for such support tools. Mozilla license is fully open
> source, and rather less restrictive than the GPL. No problem at all.

There are now more than just archetype creation tools available. There is
now an early Java reference openEHR engine which comprises a number of
components, probably the most important of which is the kernel - "a small
but sophisticated component which implements the reference model (RM) and
archetype model (AM) in order to actually use archetypes at runtime to build
and validate data. It is the key component in many openEHR services, and
central to the archetype method."
OceanInformatics have a C# based kernel is likely to be opensourced in the
near future.

>> How could we translate Archetypes into SQL tables in a database?
>> I guess it could be done by hand - better would be some sort of parser.
>> This is a separate issue to the user interface of course

There are two parts to the openEHR specification - the archetype model and
the reference model. The archetype model allows you to describe and
constrain a clinical idea such as blood pressure. The reference model
allows you to build concrete examples of these archetypes and in the openEHR
world, a database is full of reference model components that are described
by archetypes. One of the main advantages of this design is that the
underlying database schema can be designed once and as long as the reference
model doesn't change, ANY new archetyped data can be included even if it's a
new concept or hasn't been seen before. The clinical concepts are
completely separate from the database schema. This also makes it possible
to exchange data much more easily i.e. a discharge summary can be received
and a blood pressure contained in some part of that discharge summary can be
understood and included in any list of blood pressures that the software
provides.

> The idea is that Archetypes are the storage mechanism - just text
> files
> - but this implies the existence of openEHR storage engines which can
> make use of them. This is the missing part of the puzzle - not such
> engines are generally available, either as open source or
> commercially, althought there is a Swedish one which is very poorly
> documented at present. A few companies have built their own engines
> for use in specifica products, but openEHR Arcetypes won't fly until
> there is a range of open source and commercial data storage and
> retrieval engines for it.

> Tim C

There are a number of projects around the world that have built systems that
utilise this structure and in Australia there are at least three working
examples of openEHR kernels including a commercial offering that is being
used by QLD Health.
Its true that for openEHR to work, we will need some open source and
commercial engines - this is happening now and support is growing all around
the world.

Hugh Leslie

__________________________________
Dr Hugh Leslie
MBBS, Dip. Obs. RACOG, FRACGP, FACHI

Ocean Informatics Pty Ltd
M: 0404 033 767 E: [EMAIL PROTECTED]
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk


_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to