Re: Announcing Archie version 0.4

[Bert Verhees]

On 23-02-18 17:17, Thomas Beale wrote:


On 23/02/2018 15:36, Pieter Bos wrote:
For microservices with enough traffic, or for devices with limited 
processing power or limited bandwidth, a binary encoding makes sense. 
However, GRPC would not be my first choice for OpenEHR - you would 
have to find a way to map all the inheritance in the OpenEHR model to 
protocol buffers.




actually, you don't need to do that, you can just map to protobuf from 
inheritance-flattened form of the model classes. That can easily be 
generated from a model - UML tools, do it, BMM supports it, I think it 
should also be easy via Java reflection.


Good idea, there is some information on the subject on internet.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Thomas Beale]

On 23/02/2018 15:36, Pieter Bos wrote:

For microservices with enough traffic, or for devices with limited processing 
power or limited bandwidth, a binary encoding makes sense. However, GRPC would 
not be my first choice for OpenEHR - you would have to find a way to map all 
the inheritance in the OpenEHR model to protocol buffers.



actually, you don't need to do that, you can just map to protobuf from 
inheritance-flattened form of the model classes. That can easily be 
generated from a model - UML tools, do it, BMM supports it, I think it 
should also be easy via Java reflection.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

From the tutorial you mention:

'Don't go looking for facilities similar to class inheritance, though – 
protocol buffers don't do that.'

On 23/02/2018, 16:57, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:

On 23-02-18 16:36, Pieter Bos wrote:
> you would have to find a way to map all the inheritance in the OpenEHR 
model to protocol buffers.
For Java I found this web-page which explains how to do it. It is about 
a class with one nested class

https://developers.google.com/protocol-buffers/docs/javatutorial




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Bert Verhees]

On 23-02-18 16:36, Pieter Bos wrote:

you would have to find a way to map all the inheritance in the OpenEHR model to 
protocol buffers.
For Java I found this web-page which explains how to do it. It is about 
a class with one nested class


https://developers.google.com/protocol-buffers/docs/javatutorial




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

Those are all valid points, but for many applications, I would say are not 
actual problems. If we're discussing the context of archetype editing tools, I 
would say REST with JSON is fine. HTTP traffic is usually compressed and 
browsers have heavily optimized their JSON parsing, making it much more 
efficient than it would seem. Very good tools are available in many languages 
to parse and validate JSON encoded data against a given model and given types. 
Many people know how to use it so they can start developing right away, and 
debugging is easy due to the fact that is human readable.

For microservices with enough traffic, or for devices with limited processing 
power or limited bandwidth, a binary encoding makes sense. However, GRPC would 
not be my first choice for OpenEHR - you would have to find a way to map all 
the inheritance in the OpenEHR model to protocol buffers.

Regards,

Pieter Bos
Nedap Healthcare

On 23/02/2018, 15:30, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:

On 23-02-18 14:37, Pieter Bos wrote:
> A small amount of JavaScript working with Json from a backend works very 
well for us.
>
> You don’t always need explicit class definitions. it does require a 
different programming style than a more object oriented language.

Thomas has a point,

JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 
bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of 
CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are 
misused for functional error-codes
- the http-protocol with all the headers is not efficient and has 
unnecessary overload
- REST is not error or type safe, you can send anything to a 
restservice, it processes the whole request-headers, and then looks if 
the parameters are sufficient in number and in type

Check this, it is a good explanation (if you have time for that, it 
hardly handles about Go):
https://www.youtube.com/watch?v=J-NTfvYL_OE

The question is only of a license-restricted product as ICE is the 
answer to this problem
For microservices GRPC works very well, it has a performance of 
sometimes 100* the performance of rest, it supports also bi-directional 
streaming, and it is safe, because the interface-code is generated.

There are some promising projects for GRPC in browsers which support 
HTTP/2 (this are all browsers in their latest versions)
I did not test it, but I will, in a few weeks in a project I am working on.
https://github.com/improbable-eng/grpc-web

Bert

>
> Regards,
>
> Pieter Bos
>
> Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
> het volgende geschreven:
>
> The problem with Ice is that it is not open source licensed when used in 
a non GPLv2 product.
> Another problem is that they do not publish the price of a commercial 
license.
>
> That are restrictions that cause many programmers not to use it.
>
> https://zeroc.com/licensing
>
>
> On 23-02-18 13:59, Thomas Beale wrote:
>
> Belated thought on this topic: a much better way to connect a JavaScript 
front end with a Java back end, or any similar combination, would be with a 
binary RPC protocol like ICE, that comes with 
tools to make it all work.
>
> - thomas
>
> On 05/02/2018 22:04, Thomas Beale wrote:
>
>
> yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.
>
> - thomas
>
> On 03/02/2018 07:56, Peter Gummer wrote:
> On 1 Feb 2018, at 05:13, Thomas Beale 
> wrote:
>
> ... But the main interest is that we will be able to build new tools such 
as a Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.
>
> Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how 
Archie (written in Java, disappointingly) would enable JavaScript 
implementations. JavaScript has nothing in common with Java (apart from the 
name).
>
> Peter
>
>
>
>
> ___
> openEHR-technical mailing list
> 

Re: Announcing Archie version 0.4

[Bert Verhees]

On 23-02-18 14:37, Pieter Bos wrote:

A small amount of JavaScript working with Json from a backend works very well 
for us.

You don’t always need explicit class definitions. it does require a different 
programming style than a more object oriented language.


Thomas has a point,

JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 
bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of 
CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are 
misused for functional error-codes
- the http-protocol with all the headers is not efficient and has 
unnecessary overload
- REST is not error or type safe, you can send anything to a 
restservice, it processes the whole request-headers, and then looks if 
the parameters are sufficient in number and in type


Check this, it is a good explanation (if you have time for that, it 
hardly handles about Go):

https://www.youtube.com/watch?v=J-NTfvYL_OE

The question is only of a license-restricted product as ICE is the 
answer to this problem
For microservices GRPC works very well, it has a performance of 
sometimes 100* the performance of rest, it supports also bi-directional 
streaming, and it is safe, because the interface-code is generated.


There are some promising projects for GRPC in browsers which support 
HTTP/2 (this are all browsers in their latest versions)

I did not test it, but I will, in a few weeks in a project I am working on.
https://github.com/improbable-eng/grpc-web

Bert



Regards,

Pieter Bos

Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
> het volgende geschreven:

The problem with Ice is that it is not open source licensed when used in a non 
GPLv2 product.
Another problem is that they do not publish the price of a commercial license.

That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:

Belated thought on this topic: a much better way to connect a JavaScript front end 
with a Java back end, or any similar combination, would be with a binary RPC protocol 
like ICE, that comes with tools to make it all 
work.

- thomas

On 05/02/2018 22:04, Thomas Beale wrote:


yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. 
Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.

- thomas

On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

A small amount of JavaScript working with Json from a backend works very well 
for us.

You don’t always need explicit class definitions. it does require a different 
programming style than a more object oriented language.

Regards,

Pieter Bos

Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
> het volgende geschreven:

The problem with Ice is that it is not open source licensed when used in a non 
GPLv2 product.
Another problem is that they do not publish the price of a commercial license.

That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:

Belated thought on this topic: a much better way to connect a JavaScript front 
end with a Java back end, or any similar combination, would be with a binary 
RPC protocol like ICE, that comes with tools to 
make it all work.

- thomas

On 05/02/2018 22:04, Thomas Beale wrote:


yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. 
Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.

- thomas

On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Bert Verhees]

The problem with Ice is that it is not open source licensed when used in 
a non GPLv2 product.
Another problem is that they do not publish the price of a commercial 
license.


That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:


Belated thought on this topic: a much better way to connect a 
JavaScript front end with a Java back end, or any similar combination, 
would be with a binary RPC protocol like ICE 
, that comes with tools to make it all 
work.


- thomas

On 05/02/2018 22:04, Thomas Beale wrote:



yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for 
web app development these days, and Java for the back-end. The 
connection between front and back-end that people seem to prefer 
these days is REST APIs, which both Java and JS can do easily enough.


- thomas


On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:


... But the main interest is that we will be able to build new 
tools such as a Java/JS replacement for the ADL Workbench, and of 
course things like a high-quality, BMM-driven runtime archetype 
validating kernel for EHR systems, workflow implementations and 
many other components.




Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand 
how Archie (written in Java, disappointingly) would enable 
JavaScript implementations. JavaScript has nothing in common with 
Java (apart from the name).


Peter




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Thomas Beale]

Belated thought on this topic: a much better way to connect a JavaScript 
front end with a Java back end, or any similar combination, would be 
with a binary RPC protocol like ICE , 
that comes with tools to make it all work.


- thomas

On 05/02/2018 22:04, Thomas Beale wrote:



yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for 
web app development these days, and Java for the back-end. The 
connection between front and back-end that people seem to prefer these 
days is REST APIs, which both Java and JS can do easily enough.


- thomas


On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:


... But the main interest is that we will be able to build new tools 
such as a Java/JS replacement for the ADL Workbench, and of course 
things like a high-quality, BMM-driven runtime archetype validating 
kernel for EHR systems, workflow implementations and many other 
components.




Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand 
how Archie (written in Java, disappointingly) would enable JavaScript 
implementations. JavaScript has nothing in common with Java (apart 
from the name).


Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Creating a terminology

[Seref Arikan]

Hi Matthew,

Great to hear from you. https://wiki.nci.nih.gov/display/lexevs/lexevs
worked for me back in 2009 or so, it is apparently still alive. maybe worth
taking a look at.

All the best
Seref


On Fri, Feb 23, 2018 at 11:18 AM, Darlison, Matthew 
wrote:

> Dear Charlie,
>
>
>
> That’s interesting, and not something I’d come across – many thanks!
>
>
>
> Is anyone aware of an open, freely available terminology service suite
> that could be used to experiment with what should be in a terminology in
> order to make it useful for various purposes..?
>
>
>
> Yours,
>
>
>
> Matthew
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Charles McCay
> *Sent:* 22 February 2018 15:42
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* Re: Creating a terminology
>
>
>
> HI Matthew
>
> You may be interested in HL7 InfoButton - which is a standard for linking
> clinical systems to knowledge bases -- it is a fairly simple and open REST
> interface -- allowing you to define the sorts of search parameters that you
> are expecting - and retuning the knowledge in a few possible formats.
>
> Whether this will work for you depends upon how you anticipate your
> knowledge being accessed - and whether the process will be triggered from
> within the EHR or from some other user interaction.
>
>
>
> I have not used it but it does not seem too tied to other HL7 standards,
> and so may also be of use and relevance in an OpenEHR context.  At the very
> least it will be an interesting example of folk trying to do something
> similar to you :)
>
> The following page looks like a good place to start ---
> http://www.openinfobutton.org/hl7-infobutton-standard
>
> all the best
>
> Charlie
>
>
> Charlie McCay, char...@ramseysystems.co.uk
> Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES
> tel +44 7808 570172 <+44%207808%20570172>  skype: charliemccay
> linkedin:charliemccay
>
>
>
> On 22 February 2018 at 13:57, Darlison, Matthew 
> wrote:
>
> Dear Diego,
>
>
>
> I don’t know precisely yet, but the problem space arises when, for
> example, a procedure is standardised (by a protocol or SOP), and thus has a
> set of agreed “allowed” outputs which one might need to record in the kind
> of way that would fit with mapping to a DV_CODED_TEXT from an archetype.
> When this goes finer-grained than any existing terminology (for example,
> when the basis is something like a locus-specific mutation database) there
> needs to be a way to create pick-lists etc. without embedding the logic
> inside an archetype.
>
>
>
> My current thinking is that the protocol/SOP maps to 1…* archetypes, but
> the knowledge needs not to be embedded there because it has broader uses.
>
>
>
> Does that make sense?
>
>
>
> Yours,
>
>
>
> Matthew
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Diego Boscá
> *Sent:* 22 February 2018 13:05
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* RE: Creating a terminology
>
>
>
> Matthew, what is the scope of your terminology? Are the terms intended to
> appear in data instances? If terms are intrinsic to a set of archetypes
> then you could probably define the terms as constraint bindings in each
> archetype.
>
>
>
> El 22 feb. 2018 1:44 p. m., "Darlison, Matthew" 
> escribió:
>
> Dear Gerard,
>
>
>
> Many thanks – that’s interesting as an expression of the terminology, but
> I’m guessing that was either generated from a machine-readable expression
> of the terminology, or would need such a machine-readable version to exist
> before it could be instantiated within a terminology server/service? I’m
> also interested to try that out, so that other software might be able to
> interrogate the resource…
>
>
>
> Yours,
>
>
>
> Matthew
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *GF
> *Sent:* 22 February 2018 12:23
> *To:* Thomas Beale 
> *Subject:* Re: Creating a terminology
>
>
>
> Dear Matthew,
>
>
>
> In the attachment a candidate terminology as PDF
>
>
>
> It is known as SIAMM
>
> Semantic Interpretabily Artefact Modelling method
>
>
> Gerard   Freriks
>
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
>
>
> Kattensingel  20
>
> 2801 CA Gouda
>
> the Netherlands
>
>
>
> On 22 Feb 2018, at 13:03, Darlison, Matthew  wrote:
>
>
>
> Dear All,
>
> I've been looking for some time for ways of injecting knowledge into the
> ecosystem so that it is available to an EHR, but also to other systems that
> might want to use it.
>
> I currently think I need to create a terminology (or maybe more than one),
> but I've found vanishingly few open tools and little guidance on what I
> could use to do this, and experiment to see if it does 

RE: Creating a terminology

[Darlison, Matthew]

Dear Charlie,

That’s interesting, and not something I’d come across – many thanks!

Is anyone aware of an open, freely available terminology service suite that 
could be used to experiment with what should be in a terminology in order to 
make it useful for various purposes..?

Yours,

Matthew


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Charles McCay
Sent: 22 February 2018 15:42
To: For openEHR technical discussions 
Subject: Re: Creating a terminology

HI Matthew
You may be interested in HL7 InfoButton - which is a standard for linking 
clinical systems to knowledge bases -- it is a fairly simple and open REST 
interface -- allowing you to define the sorts of search parameters that you are 
expecting - and retuning the knowledge in a few possible formats.
Whether this will work for you depends upon how you anticipate your knowledge 
being accessed - and whether the process will be triggered from within the EHR 
or from some other user interaction.

I have not used it but it does not seem too tied to other HL7 standards, and so 
may also be of use and relevance in an OpenEHR context.  At the very least it 
will be an interesting example of folk trying to do something similar to you :)

The following page looks like a good place to start --- 
http://www.openinfobutton.org/hl7-infobutton-standard
all the best
Charlie

Charlie McCay, char...@ramseysystems.co.uk
Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES
tel +44 7808 570172  skype: charliemccay   linkedin:charliemccay

On 22 February 2018 at 13:57, Darlison, Matthew 
> wrote:
Dear Diego,

I don’t know precisely yet, but the problem space arises when, for example, a 
procedure is standardised (by a protocol or SOP), and thus has a set of agreed 
“allowed” outputs which one might need to record in the kind of way that would 
fit with mapping to a DV_CODED_TEXT from an archetype. When this goes 
finer-grained than any existing terminology (for example, when the basis is 
something like a locus-specific mutation database) there needs to be a way to 
create pick-lists etc. without embedding the logic inside an archetype.

My current thinking is that the protocol/SOP maps to 1…* archetypes, but the 
knowledge needs not to be embedded there because it has broader uses.

Does that make sense?

Yours,

Matthew

From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org]
 On Behalf Of Diego Boscá
Sent: 22 February 2018 13:05
To: For openEHR technical discussions 
>
Subject: RE: Creating a terminology

Matthew, what is the scope of your terminology? Are the terms intended to 
appear in data instances? If terms are intrinsic to a set of archetypes then 
you could probably define the terms as constraint bindings in each archetype.

El 22 feb. 2018 1:44 p. m., "Darlison, Matthew" 
> escribió:
Dear Gerard,

Many thanks – that’s interesting as an expression of the terminology, but I’m 
guessing that was either generated from a machine-readable expression of the 
terminology, or would need such a machine-readable version to exist before it 
could be instantiated within a terminology server/service? I’m also interested 
to try that out, so that other software might be able to interrogate the 
resource…

Yours,

Matthew

From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org]
 On Behalf Of GF
Sent: 22 February 2018 12:23
To: Thomas Beale 
>
Subject: Re: Creating a terminology

Dear Matthew,

In the attachment a candidate terminology as PDF

It is known as SIAMM
Semantic Interpretabily Artefact Modelling method

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

On 22 Feb 2018, at 13:03, Darlison, Matthew 
> wrote:

Dear All,

I've been looking for some time for ways of injecting knowledge into the 
ecosystem so that it is available to an EHR, but also to other systems that 
might want to use it.

I currently think I need to create a terminology (or maybe more than one), but 
I've found vanishingly few open tools and little guidance on what I could use 
to do this, and experiment to see if it does what I need.

I'd be grateful for any advice...

Yours,

Matthew

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR REST APIs: any plans for Contribution semantics?

[Seref Arikan]

Apologies: I somehow managed to miss the Contribution resource at the
bottom of EHR API documentation.

On Fri, Feb 23, 2018 at 9:15 AM, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Greetings,
>
> I cannot see any resources that represent Contributions in the current
> REST API specs. Is this on the roadmap for REST API specifications?
>
> All the best
> Seref
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR REST APIs: any plans for Contribution semantics?

[Seref Arikan]

Greetings,

I cannot see any resources that represent Contributions in the current REST
API specs. Is this on the roadmap for REST API specifications?

All the best
Seref
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org