On 15/07/2018 20:52, Bert Verhees wrote:
On 15-07-18 11:19, Thomas Beale wrote:
Bert,
the addition of business-level transactional APIs, e.g for medication
list, e-pharmacy, or other business level functions is certainly
intended and envisaged. It's just not the first step.
Such APIs would convert relatively simple transactional concepts e.g.
get_medication_list(), suspend_medication() etc to what may be
non-trivial information structures defined by specific archetypes,
which would be valuable for the reasons you say. Also: they improve
data interoperability because complex structures (say, Care Plans)
are guaranteed to always be the correct structure due to the API,
whereas manual creation might end up with different variations.
I agree, thanks for your reply. What I would find interesting is that
there would be an API-set, which is defined from good reasoning, how a
specific API should look like. I found an example on the Internet from
a Californian startup, which may be far from complete and maybe there
is otherways much to improve, but they incorporate also Wellness and
we don't see that a lot. But the final judgment I let that to people
who studied for it.
https://hub.humanapi.co/docs/overview
I just had a look at this. It's pretty low-level. See Medications API
<https://reference.humanapi.co/#medications> for example. It seems to be
a competitor to FHIR in some way, since it is not using FHIR.
Anyway, there are two kinds of things we can do, both more advanced than
this.
The first is to generate APIs from templates, in the same way we
generate a TDS (Template Data Schema, which is an XSD) from a template.
All we need to do to build a transformer, not hand-build APIs (that's
last century thinking). This means we would have a way to generate an
API from any template, i.e. any content. This kind of API is one way to
get data out of a system.
The second interesting thing to do is to design transactional API models
for things like 'Medication List' and 'Care Plan', which have a
functional interface. In the first instance we could do this in UML
(same approach as the current Abstract Platform Service model
<https://www.openehr.org/releases/SM/latest/docs/openehr_platform/openehr_platform.html>)
or IDL, and build a generator to output REST APIs. This style of API is
functional and transactionally oriented, and is the basis of writing
changes into the system.
If there are people interested in working on either of these, we can put
together a working group (or two).
- thomas
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
<https://theobjectivestance.net/>
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
