On 10/04/2013 15:46, Tim Cook wrote:
> On Wed, Apr 10, 2013 at 11:37 AM, Thomas Beale
> <thomas.beale at oceaninformatics.com> wrote:
>> Tim,
>>
>> Looking at the extract below, this MLHIM model would be hard to use as a
>> basis for generating source code facades, WSDL, JSON UI form specifications,
>> and other things we regularly generate downstream from templates.
>>
> I have no clue why you would say that when there are TONS of tools and
> libraries, built and tested, for working with XML Schemas and XML data
> in building WSDL, XForms, XQueries and other XML family artifacts, as
> well as JSON.
actually, that's true, but I was thinking more about the semantic
content of the model rather than what tools can do the transformation
work. And I just realised now I am looking at a RM-only definition, not
a clinical model definition, so ignore what I said for now. I need to
look more closely at the clinical MLHIMs.
>
> Your earlier statement on this subject was just so bizarre to me that
> I didn't reply to it. A simple survey of what is available as well as
> common sense dictate that these things all work together. The only
> thing I can think of is your "I must build it myself" approach. Which
> in that case, it might be difficult for you to build them. But why?
>
> I don't understand your concern. This is XML, you don't have to build
> or adapt it.
It depends on what you are trying to build. We have already described
our aims:
* 3 levels of models: Information Model / archetypes (library of
re-usable data point / group definitions) / templates (data sets)
* specialisation ability between models in all layers (it comes for
free in the IM layer, if expressed as an OO model)
* model - model referencing capability
* the general semantics of object models, exemplified by e.g. UML 2
(imperfect as it is), are needed - generic types, inheritance,
redefinition
* semantics of both constraint and extension within the archetype and
template layers of models
And we already know that XML Schema doesn't implement:
* generic types
* inheritance, in a reasonable way
* even container types are needlessly annoying
So to achieve the aims, XML schema is pretty far from being adequate
(and I recognise XSD 1.1 gets a bit closer than 1.0, but it doesn't
really fix the core semantics). In particular, it's hard to see how to
achieve the distinct archetype and template levels. It is however good
enough to describe single documents / messages which is why we routinely
generate XSDs from final templates, and deploy them as message content
definitions.
So yes, we have to do some innovation here, and invent something new. We
are not the only ones. Late last year, I spent a month with Dr Stan
Huff's group at InterMountain Health, and they have invented - slowly
and surely over 15+ years - nearly the same ecosystem as what openEHR
has. Some of their tools are way better, some not as good. Their use of
terminology is stronger, but flexibility of archetyping / templating
slightly less. They have 6,000 'clinical element models (CEMs)' (each
one is roughly the same as a single archetype primary data point, +
context data points), so the equivalent of about 300+ archetypes @
average of 20 data points / archetype. The multiple levels, redefinition
& specialisation , flattening, downstream XSD generation are all there,
just as for the archetype / template world. Have a look at their models
here
<http://www.clinicalelement.com/#/20130301/Intermountain/StandardLabObs>. The
only reason this isn't famous is because it's a proprietary unpublished
model formalism (well historically anyway). It's really impressive work.
The second major project that is also doing very nice modelling work in
true multiple layers at the VA is the MDHT project
<https://www.projects.openhealthtools.org/sf/projects/mdht/> that Dave
Carlson is leading. They are exploiting UML 2.x to the absolute limit to
make it do the kinds of things they want to do - very similar to the
openEHR and Intermountain list of requirements. They are extending this
project in the direction of ADL, under the 'AML', Archetype Modelling
Language project, which will add further ADL / AOM semantics to the
modelling capability. This tooling right now does not support all of the
semantics of ADL/AOM 1.5, but on the other hand has a much closer
binding with UML and all related tools and formalisms. Now UML has its
faults, but its formal sophistication is lot higher than XML schema.
The more recent Clinical Information Modelling Initiative
<http://informatics.mayo.edu/CIMI/index.php/Main_Page>has coalesced some
of the major e-health organisations from around the world, and they are
championing a general 'semantic modelling' approach for health. CIMI
chose as its preferred starting modelling formalism ADL/AOM 1.5 (by a
voting process). The group has already thrown up a couple of nice
requirements for ADL/AOM which we didn't think of in openEHR (Stan's
group also provided some new insights).
One of the goals we are working on is to make these three projects and
approaches - openEHR archetypes, Intermountain CEMs and MDHT tooling -
converge around a common formalism, which will probably come in three forms:
* ADL and its XML serialised equivalent
* AOM, the object model, independent of the serial format
* AML, an archetype-enabled UML, and XMI serialisation
I have not even mentioned the Smart health and other related OWL and API
projects going on in this space, looking to connect to archetype models
and information.
We might be crazy, but if we are, we are in good company.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130410/fd697c75/attachment.html>
