Thanks Sam
Gnumed is using PostgreSQL as a backend with an intelligent middleware
"broker" between client and DB which can be remote.
The OpenEHR reference model and Archetypes could provide a rational data
model and DB schema. How much work would be involved in converting these
to SQL? (Are they fully "mappable" to SQL?)
I guess the simplest method would be to do it by hand for a set of
archtypes/structures that are sufficient for your record. It seems
overkill to write a program that will only need to do it once - or is
there a need for dynamic/runtime data objects - if so why?
Which archetypes would you use for a standard GP medical medical record
to create a standard DB schema?
On a separate question
Much of my day to day typing in an electronic record is the unstructured
history/presenting complaint and examination findings - these form the
basis of the "legal" record, which is one of the legitimate uses of the
record. Which archetypes are best fit for this imformation?
The problem for me is always - the mind numbing complexity of any
solution - where to start - where to put my effort.
I am a volunteer working part time in IT - I dont want to waste my
effort such as it is. So in the end I pick around the edges and flit
from one idea to another without achieving much except learning. :(
In the past I have created quite complex projects in electronics with
assembly level software and circuit/PCB design , so I reckon I could
contribute something
Richard
Sam Heard wrote:
Dear Tim and Richard....
I got lost on the old list and someone bumped me this.
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?)
/
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.
/ 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
/
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.
SAM> The archetypes actually specify how a particular reusable information
structure (or data group in NEHTA) is to be represented (and stored) using
the /open/EHR information model - which provides the database schema.
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.
SAM> Ocean have a .Net one which will hopefully be open source if we
get suffucient sponsors. The DSTC have one based on 0.96. It is likely
that there will be open source components but that the /open/EHR backend
will be marketed to ensure upgrading and maintenance in a streamlined
manner. We will have to wait and see how the space fills. Anyone wanting
to join the open source effort should look on the openEHR site.
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.
SAM> I agree - but there as many are on the way and we have to get the
information structures standardised if we are going to share information
it is worth getting on with it!
Tim C
------------------------------------------------------------------------
_______________________________________________
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
