On 16-07-18 16:54, Ian McNicoll wrote:
Hi Bert,
Have a look at what Ripple is doing in terms of 'meaningful APIs'.
See
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2018-February/014799.html
This is interesting, although, what I understand from it in a "quicky"
This is what I think to have read in that quick information absorption.
In the link is (I think) explained that one should not build a GUI
around a datamodel, but have their own criteria to build a GUI.
I agree with that, because a GUI serves another purpose then a datamodel
(in which the data are stored)
The same is also for creating a message, it must not mimic the datamodel
where it comes from, but have its own criteria, based on
understandability and structures for others also easy to follow in
receiving and transmitting.
Unless you are the center of the universe, of course, then you can
expect others to follow you, that they have the functionality to
understand and parse what you bring over.
This is interesting because this means that an API does not need to
export OpenEhr/archetype-structures, they are often not going to be used
anyway.
So that is not what we want, as a study from Helma van der Linden
apparently also shows.
A GUI, a message, (an API) should be effective in the context of the
receiver, not in the context of the sending party.
Thomas called the medication API from the Human API "low level", but
this was a confusing term. Better would have been to call it primitive,
or something like that. But what he meant to say was understandable and
right in that example. But I like to rephrase it because it better fits
in my thinking. (funny, this communication misunderstanding is a lot
like API misunderstandings, so context is important.)
Low level in OpenEhr context would mean, exporting the structures as
they are found inside OpenEhr-storage, Low level would mean in my
understanding, as close as possible to the source. Mostly, low level is
more complicated then high level. Compare it with ways of communicating
computer-instructions: assembly (Low Level, complex, processor-type
bounded and not fit or interoperability) with Java (High level, not
complex, runs on every machine).
That is what an API does. It does not want to preserve structures which
are in use on the sending side, but it wants to exchange data with other
purposes/platforms in a way that it is easy to understand. We cannot
expect from the other side that they know how to parse archetypes.
So we could ask ourselves, is "more primitive" worse then "low level"?
There must be a level between these which is good.
I agree that meta-data, like "created at", "id" should not be mixed up
with clinical data. So that part is not right in the Human API
medication call. Maybe there are more points wrong.
But that should not be the discussion. The discussion should be about
how the API will look like, (and maybe learn from others, because others
will use the API)
And there is another thing, an API should be stable. Because CKM is
regarded as a base-structure set for OpenEhr which is sensible to use,
this does not mean that every OpenEhr installation follows CKM
completely, partly, or not at all. This is propagated as flexibility.
CKM is not the center of the universe. An API should therefor not impose
a structure from CKM on users. It should have its own means of
communication. This must consist from primitive structures, because many
software designers which think in other ways must find it usable.
Apart from this interoperability (with other paradigms) thinking, there
can of course also be a low level API which dumps archetype structures
over the wall because the other side knows how to parse ADL and knows
how to store and retrieve archetyped data, so the other side is an
OpenEhr machine. Between two OpenEhr systems, OpenEhr is the center of
the universe.
Best regard
Bert Verhees
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: [email protected] <mailto:[email protected]>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation [email protected]
<mailto:[email protected]>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On Mon, 16 Jul 2018 at 15:06, Bert Verhees <[email protected]
<mailto:[email protected]>> wrote:
On 16-07-18 15:56, Bert Verhees wrote:
> But again, the starting point must be the API's defined, maybe in a
> transformerable language like swagger, which seems to connect
well to
> the OpenAPI initiative.(I never liked swagger much, but my last
> experience with it was from years ago, maybe it is better now)
>
> And then you mentioned BMM, I don't know about that. I should
look at
> it, I saw your other email. Do you have somewhere a document why
BMM
> is so good?
The latest version of Open API (swagger became the Open API)
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
