The approach I took with my FHIR like API was to have a named query with know parameters and result columns. This could be registered internally using AQL or hard coded. This all comes from FHIR principles as they allow registering queries and then executing them.
Regards Heath On 20 Jan 2015, at 7:39 am, "Thomas Beale" <thomas.beale at oceaninformatics.com<mailto:thomas.beale at oceaninformatics.com>> wrote: 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<mailto: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<mailto:openEHR-technical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150120/38f42ffa/attachment-0001.html>
