On 17/03/2011 08:08, Athanassios I. Hatzis, PhD wrote:
>
> Hi Thomas,
>
> I read your email and I would like to comment on the three main topics
> you touched. First I believe that people in openEHR project have
> contributed a lot in all three areas of health informatics as you
> mentioned in your email and congratulations to all for leading
> innovative work. Nevertheless in my opinion what makes openEHR to
> excel in the domain of health informatics and where I certainly place
> my bet for the future is the design of archetypes and especially
> templates. This is THE bridge between health professionals and
> software developers.
>
yes - this is the key for the future.
> You can find tons of specifications from all the organizations you
> referred to and you can also find a lot of open source software tools
> and applications in the health domain but the simplicity of archetypes
> and templates and the tools to design them is unique in your project.
> Nevertheless the last two years I have been pondering a lot on the
> state of the art regarding the design of graphical user interfaces,
> the design of the data model and the trend to support distributed
> systems with web services. This is certainly not the place to get into
> great depth about the technical details on all these but I am more
> than happy to present you my research plan and perhaps you can provide
> me with answers or directions on the OPEN design principles that you
> followed in your project in order to cope with the following issues:
>
> 1.Data model (I am referring to your UML RM model) - Archetypes and
> templates
>
> a.What database model are you using for the permanent storage of your
> entities, is that implemented on a popular DBMS, is it open ?
>
openEHR does not specify a physical data model - this should be a
freedom left up to developer organisations. They may want to persist
data in:
* an object database,
* a relational DB ...
o in classic 3NF form
o in blob + index form
o in some path-based form
o in some hybrid of any of the above
o other...
* some fast-file database
o like MUMPS (e.g. Cache)
o like http://fallabs.com/kyotocabinet/
* something else
all these have different run-time characteristics, which are crucially
important in production deployments, since we are talking about
O(10,000) - O(1,000,000) of EHRs. Even for a relational DB, as you can
see there is no standard persistence approach. What is starting to
emerge is lessons on better and worse DB strategies, and maybe openEHR
will publish some of the ones that work best. My guess is that the place
to look for interesting strategies is in projects like the opereffa project.
> b.How do you connect the database model with the programming data
> model and your ADL structures, what kind of OR mapping are you using
>
this is heavily dependent on the DB approach used. In the Ocean
products, a blob + index approach is used; this means blobs are
serialised and deserialised ('materialised') straight from/into object
structures. If a classic 3NF approach were used, an O/R mapper has to be
used. Classic 3NF for very object-oriented/hierarchical structures
doesn't work well, so it is best avoided. Some hybrid of blob/3NF can be
used; this needs to be designed and then you can use products like
Hibernate to help (but note Hibernate will, left to its own devices,
generate absolutely terrible DB table structures from object models).
> c.Why are you using ADL and not standard XML-XSD to describe your
> archetypes, templates ?
>
There are two answers to this....
1. Archetypes as XML Schemas (XSD)
it is difficult to specify any kind of information models properly in
XSD, because its inheritance and genericity semantics are absolutely
broken. No need to believe me - see the extracts at the bottom of this
post. The only safe approach with XSD is to minimise inheritance
(preferably remove it altogether). The lack of genericity (i.e. support
for types like List<T>) has to be worked around with special classes
representing the actual types to be used, e.g. List<Dog> etc.
The conclusion of this is that XSD can be used as an output expression
only, but is not useful in the internals of a modelling environment. For
that reason, XSDs in openEHR are (starting to be) generated by tools
starting from the Operational Template (OPT). In such XSDs, there is
little or no inheritance, just concrete types.
2. Archetypes as XML instance
Now, XSD is one kind of XML. In openEHR any archetype can be expressed
as XML instance, which is a serialisation of the published standard
archetype XSD, i.e. this is one schema for all archetypes. Archetypes
and templates expressed this way are simply XML serialisations of the
object model of archetypes (AOM).
> d.Have you explored the path on how your knowledge representation is
> linked to popular W3 technologies such as ontology, linked data, RDFs,
> especially the application of these on media information management ?
>
not nearly as much as we could - to date, we know where Xpath fits in
(Xpath is a surprisingly rich language), and there are still ideas of
interchange with OWL. However, note that OWL is a description logic
(DL), archetyes are essentially a kind of Frame Logic (FL). These are
two different kinds of logics (one based on classifications / types, one
based on instances) that can't easily be inter-converted. Rather
seamless interfacing should be the goal.
Things like Sparql could be explored, but as far as I know, not much
work has been done on this. Others on this list would be far more
competent than I to comment on these technologies.
> 2.Design of user interfaces, how is openEHR linked to the following
>
> a.What principle you follow when you bind your data to the GUI component ?
>
this is an area of great development. There are some new ideas about
doing such mappings that are now starting to emerge (see the technical
list).
> b.Is there a particular model you are following on the design of
> applications (e.g. MVC ?)
>
> c.Have you considered to support popular document formats such as
> Office Open XML and Open Document Format ?
>
> d.How easy is it for a developer to embody openEHR technology with
> popular frameworks (Adobe Flex, Microsoft .NET) ?
>
All of these questions are being actively pursued by openEHR
implementers and various university research as well. Probably worth
following the technical list for this.
> 4.Distributed systems and services
>
> a.Considering the major acceptance of the standard clinical documents
> (CCR, CDA) in the health domain and the impact they have on the
> interchange of data information, how do you match or implement those
> in openEHR ?
>
The content of CCR can be quite easily modelled using archetypes, with a
template to define the actual current standard CCR. Other templates can
be defined for all kinds of CCR-like things. Then from the OPT form of
such templates, XSDs can be generated. This approach completely replaces
the hand-built approach of current CCR, while adding a great deal of
flexibility to it (i.e. you can have 100 CCR types, all guaranteed to
create homogeneously queriable data). An openEHR standard for OPT => XSD
has not yet been published yet, but is coming. I don't know if the CCR
standard has yet been remodelled in archetypes and templates, but some
work has been done on this in Germany I believe.
> b.Is there an open demo of a complete prototype that one can explore
> to see openEHR in action (common scenario includes a clinic with
> doctors and patients where the user can explore health records for
> each one of them as well as services provided by the system) ?
>
Opereffa is probably the most complete demo right now - see
http://www.openehr.org/projects/opereffa.html
- thomas beale
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ XSD limitations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Should Inheritance Exist in XML Schema?
James Clark, designer of Relax NG, sees it as a design flaw (from
http://www.thaiopensource.com/relaxng/design.html#section:15):
... The support for inheritance in W3C XML Schema is probably the major
contributor to the considerable complexity of W3C XML Schema Part 1.
Yet, the inheritance mechanisms in W3C XML Schema do not allow W3C XML
Schema to express any constraints that cannot be expressed in RELAX NG.
Although W3C XML Schema has a very complex type system with two type
hierarchies, one for elements (called substitution groups) and one for
complex types, it supports only single inheritance. However, modern
object-oriented languages, such as Java and C#, support multiple
inheritance (at least for interfaces). Thus, in general the inheritance
structure of a class hierarchy cannot be represented in a schema.
Inheritance has proven to be very useful in modeling languages such as
UML. However, I would argue that trying to make an XML schema language
also be a modeling language is not a good idea. An XML schema language
has to be concerned with syntactic details, such as whether to use
elements or attributes, which are irrelevant to the conceptual model.
Instead, I believe it is better to use a standard modeling language such
as UML, which provides full multiple inheritance, to do conceptual
modeling, and then generate schemas and class definitions from the model
[5 <http://www.thaiopensource.com/relaxng/design.html#uml>]....
Type Restriction in XSD
Refer to
http://www.xml.com/pub/a/2002/11/20/schemas.html?page=4#restriction. The
following quote from this page summarises the problem quite well.
The parts of the WXS spec which describe derivation by restriction in
complex types (Section 3.4.6
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#derivation-ok-restriction>
and Section 3.9.6
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#cos-particle-restrict>)
are generally considered to be its most complex parts. Most bugs in
implementations cluster around this feature, and it is quite common to
see implementers express exasperation when discussing the various
nuances of derivation by restriction in complex types. Further, this
kind of derivation does not neatly map to concepts in either object
oriented programming or relational database theory, which are the
primary producers and consumers of XML data. This is the exact opposite
of the situation with derivation by extension of complex types.
Another challenge in using derivation by restriction of complex types
arises from the way in which restrictions are declared: when a given
complex type is to be derived by restriction from another complex type,
its content model must be duplicated and refined. Duplication of a
definition replicates definitions, possibly down a long derivation
chain, so any modification to an ancestor type must be manually
propagated down the derivation tree. Furthermore, such replication
cannot cross namespace boundaries -- deriving |ns2:SlowCar| from
|ns1:Car| may not work if |ns2:SlowCar|'s has a child element,
|ns2:MaxSpeed|, because it cannot be correctly derived from |ns1:Car|'s
child element |ns1:MaxSpeed|.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110318/1f88646e/attachment.html>
