I think, it would be good if the community who did this fantastic job,
should also divide a kernel in micro-services and having interfaces
between them, and let there be one entry-service to have the
micro-services expose themselve to the outside world over REST, for now.
There is knowledge about how to structure micro-services, how which
pattern to sue, between them and inside the service.
The kernel for OpenEhr is too large for not dividing it. Think about:
- OpenEhr-Terminology,
- Archetype parsing,
- Archetype serializing,
- Storage,
- Validating of data,
- validating of users/authorizations (or connecting to an external
user-service),
- measurement (ucum),
- SNOMED,
- Patient repository (connecting to external)
- Messaging to other EHR eco-systems
- Internal Message queue
It would be a great help if these microservices were defined, so
everyone could build and borrow them, when they are defined on community
level, they will be interchangeable.
This is a good starting point for learning about that subject, but an
experienced architect would be welcome.
https://www.packtpub.com/application-development/microservice-patterns-and-best-practices
Bert
On 16-02-18 12:38, Thomas Beale wrote:
I've been developing an abstract version of the platform definition in
the background, mostly reverse-engineered from the REST API, in order
to capture the pure call semantics (i.e. without HTTP protocol
effects, JSON or XML serialisation etc), and in that I proposed two
interfaces, one for ADL14 and one for ADL2, which seems a clearer
approach to me - see here
<https://www.openehr.org/releases/SM/latest/docs/openehr_platform/openehr_platform.html#_definition_package>.
This might be helpful in determining the separation we want.
- thomas
On 15/02/2018 13:09, Pieter Bos wrote:
I noticed the recent version of the REST api only works with templates, and
not archetypes.
As our EHR is ADL 2 only, this has some interesting consequences.
Of course, you can upload just the operational templates and probably create a
fully functional EHR, but if you work with ADL 2, you would always need an
external tool to create the OPT2 from the ADL repository that you want to use,
instead of an EHR that generates the OPT2s from the source archetypes itself.
Of course, you could just use the ADL workbench or the Archie adlchecker
command-line utility to do it for you, but I’m not sure if it’s a nice thing to
do.
Also if you only use OPT2, you might want to do queries such as ‘retrieve all
information that is stored in an EHR that has been derived from archetype with
id X, including archetypes specializing from X’ (not just operational template
X). An example: retrieve all reports, or all care plans, regardless of the used
template. To do that, you probably need a specialization section in the OPT2,
which according to the specs should have been removed, and you also need to
create operational templates for archetypes that you never use to directly
create compositions from. Or the tool querying the EHR must be fully aware of
the full archetype specialization tree and use that to create a query with all
specializing archetypes included in the query.
So, is it intended that the REST API only works with operational templates, and
never archetypes?
Regards,
_______________________________________________
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
