Hi Bert,
Date: Thu, 28 Nov 2013 08:22:59 +0100
From: [email protected]
To: openehr-technical at lists.openehr.org
Subject: Re: Musings about a more web-friendly openehr
Reflections on Pablo and Leo, both
recognizing the complexity of the RM and looking for ways how to
deal with it.
On 11/28/2013 04:30 AM, pablo pazos wrote:
Hi Leo,
I think simplifying openEHR is not a good strategy. The
problem is that most programmers are not implementing against
openEHR specs, they are implementing against other people's
implementations. So they have the learning curve of the specs
+ the learning curve of using provider XWZ tools.
Hi Pablo, you are talking about tooling, which is one way to
approach the complexity-problem. A good way too.
Hide the complexity, behind GUI-based tooling.
When I mentioned tools, I meant any kind of software that implements openEHR,
not only modeling tools.
Strong points in your attitude towards OpenEHR is that you
recognized the complexity of the RM, and second, that you are making
easier the way to work with it.
I don't have to recognize the complexity, is just there in the healthcare
domain!
This is not inherent to openEHR: any model of a complex reality with a certaing
level of specification will be complex.
The problem is creating a model for a complex reality that is simpler than the
needed complexity. At the end we'll find that the comlpexity was needed and
will start making patches/customizations to the implementation that should be
handled by the model. This decreases interoperability in the long term.
We can't use ultra-generic models at the implementation level: we'll end up
with a database with only two tables like when implementing an ontology (one
for class instances, the other for relationship instances). The DB of that
system will be very simple but the logic and UI will be a mess because those
layers will handle specific data, not an abstract structure.
The only part of the IM that I would smiplify is ITEM_STRUCTURE. I commented
this a long time ago:
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateB-RemoveITEM_STRUCTURE
But there can be also more fundamentally ways to handle the
complexity and make the learning curve less burdensome.
I couldn't find any good alternative to encapsulating complexity, i.e. dealing
with complexity myself. IMO changing the standard is not a good way of handlign
complexity, in fact is not handling complexity at all, just changing what we
are not comfortable with. And all standards on earth passed through the
"simpleification" stage, with no good results. Just see CDA, green CDA, ...
One is, the most important, but not in our hands, make the AOM
important, create RM's above the AOM, use it for other purposes
than OpenEHR only. The more the AOM is used, the less developers
will complain about complexity.
IMO end system developers should not even know about AOM. We can create stuff
that hides that from them and they can just consume APIs the way they are
familiar with, e.g. like they consume Twitter or Google Maps APIs.
But as I said, that is not in our hands.
My opinion is the contrary. From an architectural perspective, this is just
adding an abstraction layer between an openEHR system and the end system
developer. It is in our hands to do that or let the end system developer to
deal with the complexity of out systems and the openEHR IM/AOM.
We decide to implement that layer or not.
So, what else can we do?
Create a substandard which makes entrance to the AOM less
complicated. That is what Leo is writing about.
I skip some text
....................
....................
....................
....................
....................
> </last_name>
> </person_name>
> </identities>
> </details>
> </person>
>
> which would also be much more efficient to store and
index, and lead to more intuitive xpath
>
> //first_name_part[1]/value/text() (: Jan :)
> //first_name_part[2]/value/text() (: Peter :)
> //last_name_value/value/text() (: Balkenende :)
Hi Leo,
You advertises a simplification to make the AOM better to work with.
This is also an approach, but, simplification means, lost of
functionality.
And technical arguments like indexing should not weight in
innovation.
Because when you consider current technical arguments in defining
something new, you are not innovating, but you are consolidating.
Henry Ford said: If I asked the people what they want, they would
say: A faster horse.
So think beyond the current boundaries. Do not think of AOM making
simpler to remove a learning curve, or solve technical problems,
because that is conforming to the present, which is already the past
one second later.
So think beyond that. That is one of the good things of the
designers of OpenEHR, and more, the designers of the side effects,
like AOM, which are important beyond the boundary of OpenEHR.
Today is thanksgiving? Let us thank those people for their wonderful
work which started about in the beginning of this millennium, or
even in the end of the previous millennium.
They designed an eco-system without having a technical reference to
build it. They showed the courage of Henry Ford. They were inventing
technical solutions, instead of conforming to technical solutions of
the that time current which is now the past.
I know, through the years, people struggled a lot with how to
implement it. And I know, most of them do not admit that. Every
implementor has to solve his own secret problems. OpenEHR is not an
open developer-community, but it is a community of entrepreneurs
which all want to be the number one.
What would have happened if OpenEHR was designed conforming the
technical possibilities of 1999, would we still have been talking
about it right now?
OK, enough of hallelujah.
----------------------------
What's next....
- Tooling is good, but tooling is always situation/platform
depending. It is not a fundamental solution.
- Simplification in order to solve technical problems is conforming
to the past and is not a good way.
We need to think deeper about this.
I did not get in this any further then the path/value combinations,
and in succession, the short path notation
(which makes it in fact more complicated).
Bert
_______________________________________________
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131128/fca9b154/attachment-0001.html>
