Existing Result sets (and openEHR RM JSON serializations)
- Ocean (XML?)
- Marand (JSON, see below)
- DIPS (JSON, see below)
- All the LiU-EEE-specific schemas are at https://github.com/LiU-IMT/EEE/tree/master/src/main/xsd
- Our experimental result format for queries of XML data (originally intended for openEHR AQL queries) in that directory is at https://github.com/LiU-IMT/EEE/blob/master/src/main/xsd/xml-result-v1.xsd It was inspired by SPARQL's result set at http://www.w3.org/TR/rdf-sparql-XMLres/
- ...but agreeing on a JSON-format is probably more urgent than for XML.
- The JSON format for SPARQL might be a useful input for thought though, see http://www.w3.org/TR/2013/REC-sparql11-results-json-20130321/ The "head" and "bindings" stuff using vairables from the query might be interesting. The SPARQL response looks a bit more like the Marand than the DIPS version. I am not sure that using terms like "rows" and "columns" (like in the DIPS-version) is the best for tree-shaped NoSQL data (even though they are logically some kind of rows).
- Archie (has RM serialization in JSON & XML?)
- Code24 (see below)
Marand Ehrscape result set
{ "meta": { "href": "http://thinkehr2:8082/rest/v1/query/?aql=select%20%20%20%20%20a_a/data%5Bat0002%5D/events%5Bat0003%5D/data%5Bat0001%5D/items%5Bat0004%5D/value%20as%20Temperature,%20%20%20%20%20a_b/data%5Bat0001%5D/events%5Bat0006%5D/data%5Bat0003%5D/items%5Bat0004%5D/value%20as%20Blood_Pressure_Systolic,%20%20%20%20%20a_b/data%5Bat0001%5D/events%5Bat0006%5D/data%5Bat0003%5D/items%5Bat0005%5D/value%20as%20Diastolic%20from%20EHR%20e%20contains%20COMPOSITION%20a%20contains%20(%20%20%20%20%20OBSERVATION%20a_a%5BopenEHR-EHR-OBSERVATION.body_temperature.v1%5D%20and%20%20%20%20%20OBSERVATION%20a_b%5BopenEHR-EHR-OBSERVATION.blood_pressure.v1%5D)%20offset%200%20limit%20100" }, "aql": "select a_a/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value as Temperature, a_b/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value as Blood_Pressure_Systolic, a_b/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value as Diastolic from EHR e contains COMPOSITION a contains ( OBSERVATION a_a[openEHR-EHR-OBSERVATION.body_temperature.v1] and OBSERVATION a_b[openEHR-EHR-OBSERVATION.blood_pressure.v1]) offset 0 limit 100", "executedAql": "select a_a/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value as Temperature, a_b/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value as Blood_Pressure_Systolic, a_b/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value as Diastolic from EHR e contains COMPOSITION a contains ( OBSERVATION a_a[openEHR-EHR-OBSERVATION.body_temperature.v1] and OBSERVATION a_b[openEHR-EHR-OBSERVATION.blood_pressure.v1]) offset 0 limit 100", "resultSet": [ { "Temperature": { "@class": "DV_QUANTITY", "magnitude": 37.1, "units": "°C", "precision": 1 }, "Blood_Pressure_Systolic": { "@class": "DV_QUANTITY", "magnitude": 120, "units": "mm[Hg]" }, "Diastolic": { "@class": "DV_QUANTITY", "magnitude": 90, "units": "mm[Hg]" } }, { ...
There is some meta-data at the beginning:
- href: href of the call
- aql: the AQL client sent
- executedAql: AQL the server executed - this will have potential parameters replaced
Resultset is a simple array of rows with one object per column. Columns names are taken from AQL select aliases, if none is present then just 0-based column index prefixed by a hash-sign (#) is used instead, i.e.: #0 for first column, etc.
JSON format used here for the RM is also used for other operations. Here is an example where we select an Observation rather than simple DATA_VALUEs:
"Measurement": { "@class": "OBSERVATION", "name": { "@class": "DV_TEXT", "value": "Body temperature" }, "archetype_details": { "@class": "ARCHETYPED", "archetype_id": { "@class": "ARCHETYPE_ID", "value": "openEHR-EHR-OBSERVATION.body_temperature.v1" ...
Attribute names are snake-case (like defined in MagicDraw). We also add attribute @class to every object to define the exact class used for the object. Class names are all upper case and also snake-case.
DIPS Arena EHR ResultSet
Below it the resultset from DIPS Arena EHR Server. The query used is the same as in the Marand example above.
Arena EHR Server supports both JSON and XML on the query resource. The JSON is shown below and a XML examples is here: Arena EHR Server API
{ "@class": "RESULTSET", "@schemaversion": "0.1.0", "@type": "raw", "@created": "2016-06-17T14:18:00.422+02:00", "@generator": "DIPS.OpenEhr.ResultSets.Serialization.Json.ResultSetJsonWriter (5.0.0.0)", "name": null, "correlationid": "00000000-0000-0000-0000-000000000000", "totalResults": 31, "columns": [ { "name": "Temperature", "path": "/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value" }, { "name": "Blood_Pressure_Systolic", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value" }, { "name": "Diastolic", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value" } ], "rows": [ [ { "@class": "DV_QUANTITY", "magnitude": 37.0, "units": "Cel" }, { "@class": "DV_QUANTITY", "magnitude": 120.0, "units": "mm[Hg]" }, { "@class": "DV_QUANTITY", "magnitude": 80.0, "units": "mm[Hg]" } ],
Archie
Archie can serialize RM Objects to XML using the standard openEHR RM XSD, or it can be used to serialize to JSON. The format we have now is very similar that the one Marand uses: snake_cased attribute names, type names as the same notation as the RM specs. Our EHR is still in the prototype phase, so the format is still subject to change, and no results from AQL queries yet.
The code to configure Jackson (XML serialization library) to serialize to/from this exact format is not yet present in Archie.
"data" : { "type" : "HISTORY", "name" : { "type" : "DV_TEXT", "value" : "history" }, "archetype_node_id" : "id2", "events" : [ { "type" : "POINT_EVENT", "name" : { "type" : "DV_TEXT", "value" : "any event" }, "archetype_node_id" : "id7", "time" : { "type" : "DV_DATE_TIME", "magnitude" : 1466427403, "value" : "2016-06-20T14:56:43.702+02:00" }, "data" : { "type" : "ITEM_TREE", "name" : { "type" : "DV_TEXT" }, "archetype_node_id" : "id4", "items" : [ { "type" : "ELEMENT", "name" : { "type" : "DV_TEXT", "value" : "Systolic" }, "archetype_node_id" : "id5", "value" : { "type" : "DV_QUANTITY", "magnitude" : 120.0, "precision" : 0, "units" : "mm[Hg]" }, "path" : "/data[id2]/event[id7]/data[id4]/item[id5]" }, { "type" : "ELEMENT", "name" : { "type" : "DV_TEXT", "value" : "Diastolic" }, "archetype_node_id" : "id6", "value" : { "type" : "DV_QUANTITY", "magnitude" : 80.0, "precision" : 0, "units" : "mm[Hg]" }, "path" : "/data[id2]/event[id7]/data[id4]/item[id6]" },
Code24
Code24 does not have yet implemented AQL, but most probably it will be ready in Q3/Q4 2016. Intention is to follow the same JSON as Marand's example above. The current RESTApi that we have at this time is published at http://rest.base24.nl/docs
JSON Specifics
Proposed Standard