On Mon, 1 Mar 2004, J. Antas wrote:
> Thomas Beale wrote:
>
> > Others here and elsewhere of course have thought about the problem (for
> > many years) of making data models that really do work for all of the
> > domain,
Thomas and J.,
The 2-level modeling approach promises certain benefits, but there are
still significant unsolved problems. For example:
1) how best to divide the single model into 2 levels?
1.5) What are the implications of different ways of dividing up the 2
levels?
2) how to extend/change the upper level (metamodel) without breaking
existing lower level (metadata) objects (e.g. OIO forms, OpenEHR
archetypes)?
2.5) how to support interoperation between different 2-level systems?
> Rationally I do agree with you. I am sure that they are better models.
Two-level systems may make certain tasks easier (e.g. supporting specific
types of system changes), but they also make many things more complex and
harder. These trade-offs merit systematic study and further discussion.
(Hopefully as work on OpenEHR, OIO, GnuMed, Care2x, TORCH, OSCAR, FreeMed,
etc progress, we will be able to contribute to this discussion.)
> But my problem in the first place was:
> How are they doing in real life, do they really work?
Exactly!
If a tool helps you and I build systems faster and more reliably in
real-life, that's what counts. The debate is not really about single or
2-level model, but how we can more easily support change/customization
and interoperations.
After working with the OIO project for the past 5 years, I would say
the following:
1) Custom "one-model" programming is still needed.
2) Two-level models are useful for modeling highly-repeated patterns.
3) Deciding which patterns to model and how to model them is
still an art. Note that there are increasing number of 2-level systems
and they are all different.
> At which hospitals, clinics are they doing their work?
> People using them like to use it?
> Are those models generalizable?
> At which countries are they working?
I would further add
"How easy is it to integrate with foreign one-model systems?"
> > Andrew's OIO product has a similar goal; the HL7v3 RIM is another such model;
>
> These are two lines of thought that we are trying to "assimilate".
> OIO because it is beautifully simple way to code a very complex concept.
There is never free lunch; there are concepts that OIO cannot model
in its simplistic "2-level modeler":
1) These are pretty much the same concepts that paper-based systems have
have hard time modeling.
2) Identifying these limitations may lead to ways to overcome them (but
at a cost of adding complexity).
3) Just like there can never be a perfect one-model system, maybe it is
also true that there cannot be a single, perfect 2-level system? If
so, we really should start planning to build interoperability
between 2-level systems (e.g. between OpenEHR and OIO).
...
> So, you see, we must be pragmatic,
...
> Show us a reliable, working, hydrogen motor and we will use it and will
> give you all the credits for it too.
Hybrid system with 2 motors, gasoline + hydrogen? Care2x + OIO?
...
> I could tell you how are they doing in 16 more countries with Care2x.
This certainly shows the power of a well-designed one-model system.
OIO was first released in 2000 but it still not as widely used as Care2x.
As far as I know, OIO has been used only in Italy, Russia, Sri Lanka,
U.K., and U.S..
...
> So, you see, this is pragmatism at work, there is no "my baby" syndrome.
> It is plain earth-to-earth "if yours is better and if it comes with no
> strings attached (read if it it is FLOSS) we will use it".
The vision of 2-level systems (at least as I see it) is to provide the
metamodel level (e.g. archetypes, forms, workflows) and let other people
(e.g. one-model developers, domain experts) create the metadata level
(e.g. actual forms-instances, clinical guidelines/protocols).
Thus, the end product(s) will always have to be "our babies". :-)
> That has been the most constant thing in the Care2x project and perhaps
> one of its greatest strengths: if someone comes along with a *working*
> better approach, we drop ours and just adapt to the new code.
Not at all, we really need to work together. I know OIO cannot succeed
without collaborators who are willing to create practical forms and
workflows. I am sure OpenEHR has the same needs.
> We may even find some mutants along the way, but the only way to know if
> they are "adaptative" or not is... to try them. And I assure you, we do
> try a lot.
...
Have you had chance to try OIO yet? Please let us know what you think of
it!
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org
