I have already done that ;)
When MIE accepts the paper I can tell more :D
2015-01-19 22:08 GMT+01:00 Thomas Beale <thomas.beale at oceaninformatics.com>:
> On 19/01/2015 21:01, Diego Bosc? wrote:
>
> Sad to see that go away, I liked the idea of reusing well known formats for
> everything.
> Regarding REST, I assume that nothing stops you to provide a method called
> "query" with the actual AQL query as a parameter :D
>
>
> sure - but that forces the app programmer to develop AQL queries. Now,
> serious programmers and system builders have to do this, but it's not
> unreasonable to minimise it, especially for common cases, and to help devs
> who may not be PhDs in openEHR, AQL, archetypes etc. So where can we help
> them? Well the FHIR approach is trying to hit that kind of sweet spot. The
> ideal version of FHIR or a FHIR-like approach, that we can work on in
> openEHR is to be able to generate directly from the archetype model-base
> FHIR profiles (and probably even some resources).
>
> - thomas
>
>
> 2015-01-19 21:58 GMT+01:00 Thomas Beale <thomas.beale at
> oceaninformatics.com>:
>>
>>
>> I would agree with Isabel.
>>
>> Not everything is a resource, or should be seen as a resource. If you just
>> want to pull back a lump of data, that could be a 'resource', and for that a
>> REST service based on FHIR or some other API will make sense.
>> Resource-oriented stateless services are suited to some kinds of
>> applications, mostly readers in my view.
>>
>> A service for talking directly to an EHR data store (i.e. a CDR) could be
>> designed as a REST service in theory, but it's not that well matched to the
>> kind of service interface of pattern of calls that will be made (especially
>> if distributed queries and commits are to be supported).
>>
>> The interesting question is: what style of service should be used for
>> e-health business entities, like active care plans, managed medication
>> lists, and order management, which all need much more complex APIs than just
>> 'get'? FHIR is not designed for this kind of thing, and it's questionable
>> whether REST is either. The APIs in these cases need to be carefully
>> designed, and could easily be stateful / session-oriented - especially if
>> they manage a shared resource that multiple agents may try to update
>> simultaneously. In any case, I don't see statefulness or not as the decider
>> on what kind of protocol you want; structure is a bigger decider.
>>
>> I think it's easy to fall into the trap of thinking a single latest /
>> fashionable protocol is good for all layers of a complex architecture.
>> That's very unlikely to be true. I see no problem with an complete solution
>> having REST, SOAP, binary RPC and other kinds of interfaces.
>>
>> - thomas
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
