New call proposals are in blue.
API levels in green.
Initial minimal REST API
Resource EHR
| Method | URL | Parameters | Description | Notes |
|---|---|---|---|---|
| POST | /ehr |
| Create a new EHR | |
| DELETE | /ehr/{ehrId} | Delete an EHR | ||
| GET | /ehr/{ehrId}/ehr_status | Retrieve EHR_STATUS | ||
| PUTPOST | /ehr/{ehrId}/ehr_status | Update EHR_STATUS | ||
| PUT | /ehr/{ehrId}/ehr_status/... | Update and attribute in ehr_status | TB | |
| GET | /ehr/{ehrId}/ehr_access | Retrieve EHR_ACCESS | ||
| PUTPOST | /ehr/{ehrId}/ehr_access | Update EHR_ACCESS | ||
| PUT | /ehr/{ehrId}/ehr_acess/... | Update and attribute in ehr_status | TB |
Resource FOLDER
| Method | URL | Parameters | Description | API level | Notes |
|---|---|---|---|---|---|
| GET | /ehr/{ehrId}/folderdirectory | List folders | R1 | ||
| GET | /ehr/{ehrId}/folderdirectory/{folderId} | List folder content (list of links/IDs of contained objects) | R1 | ||
| POST | /ehr/{ehrId}/folderdirectory | Create or update a folder for this EHR | |||
| PUTDELETE | /ehr/{ehrId}/folderdirectory | Update Deletes a folder for this EHR | SI |
Resource COMPOSITION
| Method | URL | Parameters | Description | API level | Notes | |
|---|---|---|---|---|---|---|
| POST | /compositioncompositions /ehr/{ehrId}/compositioncompositions |
| Create a new composition | |||
| GET | /compositioncompositions/{compositionId} | Retrieve a composition | R1 | PUT | /compositionDo we return a VERSION or a COMPOSITION here? | |
| GET | /compositions/{compositionId}/version
| Retrieve a VERSION | BL | |||
| POST | /compositions/{compositionId} /ehr/{ehrId}/compositioncompositions/{compositionId} |
| Update a composition | |||
| DELETE | /compositioncompositions/{compositionId} /ehr/{ehrId}/compositioncompositions/{compositionId} | committer
| Delete a composition |
Composition format is the canonical openEHR JSON or XML format. Sample JSON and XML are attached. JSON is using the attribute names based on the RM (snake-case, i.e.: composition.archetype_details.archetype_id) and it also adds the type information - this is the extra attribute "@class" which allows such JSON to be deserialised into proper objects of the target language.
...
| Method | URL | Parameters | Description | API level | Notes |
|---|---|---|---|---|---|
GET POST | /query
| aql | Execute an AQL | QL1 | GET has a max limit on the query length that will be too short for some queries. (Also if using GET make sure that the server sends proper caching headers.) Should we allow both POST and GET? Added post for querying to allow loooong queries |
| POST | /q/{query-language} | Generates a query-id and redirects to resulting resource (se rows below) | QL2 | (see http://www.biomedcentral.com/1472-6947/13/57) By default the query-id could be a SHA hash of the query itself (that way repeated identical queries do not need to be re-parsed/stored) If the http-server-log is used as the main source for audit-logging, then the query needs to be stored somewhere since the content of POST is usually not logged in http-logs (The stored query could be inspected using GET q/{query-language}/{query-id}/info/ ). Storing a query (could be an ad-hoc query) for logging purposes does not mean that it needs to be converted to a stored procedure in the database. Manual or automatic routines can be used for deciding when recurring queries (same hash) should be optimized/stored. If we want to support different query languages (or query language versions) we might want urls on the form q/{QUERY_LANGUAGE}/ (examples: /q/AQL/, /q/AQL2/, /q/AQLinXQuery/) | |
| GET | q/{query-language}/{query-id} | the dynamic parameters defined when query was stored | Executes named query (using dynamic parameters) | QL2 | |
| GET | /ehr/{ehrId}/q/{query-language}/{query-id} | the dynamic parameters defined when query was stored | Executes stored query (using named parameters) | QL2 | Discussion: Do we want to allow the possibility to (optionally?) split URIs for single- and multi-patient queries like this (including EHR ID in the URI)? Single-patient queries may have simpler requirements regarding security and may be more efficiently implemented in certain distributed environments. See http://www.biomedcentral.com/1472-6947/13/57 |
...