Simplified JSON data formats for openEHR

Specifications ITS
,
#1

For those interested, here is a wiki page on which we are refining so-called simplified (JSON) data formats for representing EHR data when talking through openEHR REST APIs, and maybe in other contexts.

This is likely to be relevant if you use EhrScape, EhrBase, EtherCIS among other products.

#2

Great, does this include both template and archetype in one json?

#3

The JSON ‘templates’ referred to here are close-to-runtime data instances (i.e. just need the multiple fields expanded and values filled out) of an OPT, but in this ‘compact’ JSON format which programmers seem to prefer, and which is definitely more efficient than standard JSON.

To get an idea of what this kind of JSON looks like, see the Simplified Data Template example (the Lab one) in this draft spec.

That example has programmer-friendly paths, not just compressed data values, and was originally developed by Better (i.e. Marand).

Just to be clear, the wiki page being talked about here is just trying to reach agreement on ‘compact’ JSON form(s) the leaf data items. It’s a work in progress…

#4

In the stringified datatype format for DV_CODED_TEXT, I wonder if we need to distinguish to use cases…

  1. Where the rubric/value (text) is intended to be read-only /advisory i.e the original intent of

local::at00034 | Large cuff |

or just

at00034 | Large cuff |

as Better allow in AQL and is very useful in other documentation /visualisation

  1. Where the text/value/rubric is intended to be written into the data

e.g the Ocean Temple Designer shortcut for default values

local::at00034:: Large cuff

I’m not clear that we need do both variants - perhaps the context of use makes it clear??