Hi Heath, I follow a similar approach on EHRServer with some particularities: queries are created using a UI, then stored, and then executed from clients using the UID of the query (instead of the name). There is a REST endpoint that allow clients to list all the queries available on the server, then execute one. In the near future we will add some authorization filters so the query list will return just the queries each specific client can use. Also importing/exporting queries will be in place by UI and by a REST endpoint. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com
From: [email protected] To: openehr-technical at lists.openehr.org CC: openehr-technical at lists.openehr.org Subject: Re: CRUD Restlet Date: Tue, 20 Jan 2015 22:30:47 +0000 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> 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>: 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 _______________________________________________ openEHR-technical mailing list 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/14e410aa/attachment.html>
