On 16/07/2018 13:35, Bert Verhees wrote:
On 16-07-18 13:49, Thomas Beale wrote:
It seems to be a competitor to FHIR in some way, since it is not
using FHIR.
Aren't we all? ;-)
But serious, I don't think so, they don't use FHIR because their
target-market does not use FHIR. It are mostly REST-webservices they
have as target, they combine and convert the API's to their own API.
https://www.humanapi.co/data-network
Not the company, but their API was meant as an example.
I just had a look at this. It's pretty low-level. See Medications API
<https://reference.humanapi.co/#medications> for example.
Depends on what you call low level. In this discussion, yesterday, I
called the OpenEhr API low-level, because it had no meaningful API's
at all. So calling this also low-level might be confusing.
They return with medication, productname, brandname, dosageinfo,
pharmacy, generic productname, I don't understand why you think this
is low level.
It was not particularly meant as a criticism, but have a look at this:
We can see that:
* there is no structuring - it's a flat list
* there are only basic programming types (probably from TypeScript)
* there is a mixture of infrastructure / data management and content
fields (the former highlighted).
Maybe this is fine for some uses, maybe many. But if you look at the CKM
or Apperta or other medication archetypes, it's easy to see that
obtaining that kind of data would be somewhat painful with this
interface. An interface of similar simplicity, but /generated/ from
templates using those archetypes however would be interesting...
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
There are also many tools, also for many purposes, mostly all in their
own programming language eco-system. You are jumping to the technical
process already. That is nice. Where can we download the templates you
are talking about. And what should be the target of the transformer,
or multiple-targets?
well some templates are being slowly added to the international CKM and
other CKMs, but generally, templates are what local users and vendors
create themselves. Since they don't break archetypes, it is safe to
create them according to your own data-set needs.
API's are formed in human minds, also in this century, some things do
not change. Which steps you follow to create/generate them, which
tools you want to use, that is not so important at this moment of the
discussion.
So lets call that, step Zero then. The defining of the API's
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.
REST is bounded to http 1.1 which is from 1997, it is spoiling of
resources, it needs to translate everything to strings which cost
performance in processing time, and performance in bandwith. But we
can do it with that for coming two years. I think by then the world
(also browsers for web-application front ends, also in mobile
platforms) are running http 2.0, which is stable since 2015.
But it should not be that hard to transform REST to protocol buffers,
so to make transformers for more target-protocols and more programming
languages.
indeed. Feel free to replace where I wrote 'REST' with GraphQL,
protobuf3, Apache Thrift etc ;)
The most important thing of API's are the functional part, not the
protocol they follow. (a big mistake of FHIR was incorporating a
technical standard in a message-standard, that was a weak point,
Google is repairing it: https://github.com/google/fhir )
agree.
- thomas
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
