An endpoint for resolving EHR-URIs + changed Query URI

[ErikSundvall]

It would be helpful to have an EHR-URI-resolving endpoint/resource standardized and possible to include in some level of the conformance spec. Likely the same conformance level as AQL since if you have implemented AQL you can do a very simple tranformation to also do EHR-URI resolution. (Implementing EHR-URI-resolution might also be a path towards AQL)

@bjornna mentioned that DIPS has a such endpoint/resource. Please add more information/experience regarding that.

Suggestions:

1. add a new resource under something like /query/path or /query/ehr-uri (since the EHR-URI syntax is essentialy a minimal query language), It should allow both GET with query string (e.g. GET /query/path?q={ehr-uri}) and POST (e.g. /query/path)
2. change GET /query/?aql={aql} to GET /query/aql?q={aql} to be consistent with POST /query/aql and to make room for other query languages,

In the above suggestions I replaced the quert-parameter name "aql" with "q" and reused the same ("q") for the EHR-URI-path since it makes a shorter uri and avoids repeating "query" and "aql"/"path" that are already clearly visible in the path. Examples of others uisng the q-convention: https://www.google.se/search?q=test https://www.bing.com/search?q=test https://stackoverflow.com/search?q=test

P.s. The old sugesstion in LiU-EEE paper (see table 1 in https://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/1472-6947-13-57) to have it as a continued path after a trailing slash in the versioned object URI is bad for at least two reasons: 1, the openEHR EHR-URI-spec has changed and now includes things like /folder/ and /composition/ and a single EHR-URI-resolution service should be able to point to any of those structures - thus putting it somewhere under e.g. /compsoition/ would be a bad idea.

2. Square brackets [] etc used in EHR-URIs are considered unsafe in http://www.ietf.org/rfc/rfc1738.txt so we'd need to URL-encode them anyway and they thus fit to be sent in a GET query paramater or a post.

[wolandscat]

Just a dumb Q: I assume the idea is that a dedicated end-point provides a place where translations of EHR_URIs as they are now into proper EHR REST calls and paths? I.e. we remove any assumption that a raw EHR-URI needs to be a valid REST path in the APIs we are now developing?

[ErikSundvall]

Well, up to the point of the composition/folder root based on just object/verision EHR-URIs will be valid as is now. But the continuation beyond that including square brackets etc likely needs this additionl approach.

In some use-cases (e.g. where you want to retrieve the full composition but highlight a certain part) you could theoretically use the composition resource instead and replace the slash (after versionid) with a # and hope that a clever client can navigate to the highlight (and that things get url-encoded or tolerated by the server/browser... Example: /ehrs/{ehrId}/compositions/56d03821-8e89-cca769b7d39e::test2.eee.mi.imt.liu.se::1#content[openEHR-EHR-SECTION.vital_signs.v1]/items[openEHR-EHR-OBSERVATION.blood_pressure.v1]/data/

...but the /query/path resource-suggestion above primarily caters for another use-case where you just want to retrieve a piece of a composition pointed out by the EHR-URI. See table 1 in the LiU-EEE-paper where both use-cases are listed (but using different old syntax)