Simplified Data Template (SDT) - Behavior

Hi everybody,

we are currently implementing the simSDT format in EHRbase respectively the openEHR SDK. However, we found some behavior that is not defined in the current spec.

For example, in the Better implementation, the ctx/origin is set automatically from ctx/time. If I remember correctly, the composer is also set automatically using the session information of the user.

In my opinion these things have to explicitly described, otherwise clients might not be able to directly work with the different CDRs.

Is there any information available of what replaces which value when and can this be added to the spec?

Hi Birger,

ctx is quite a nice idea, and I can probably document the behaviour but I would suggest that you initially implement what Better call their FLAT/STRUCTURED ‘OUTPUT’ format which does not use the ctx construct and is essentially what comes back out again after the ctx defaults are applied - so things like entry-level language, observation.origin are explicit. You can also send these as an input format and increasingly I am working with that for both Create and Read as it makes updates much easier, since the json structure is identical. It is a slightly higher leaning curve but inevitably devs have to get used to the OUTPUT format, in order to do PUTS.

This is still in flux - see this post.

I was trying to list out all the various JSON fragments for variations on the theme on this wiki page.

I ave an initial clean spec (short) that is supposed to scoop up all this and explain it, so I’ll do some more work on that and then everyone else can tell me what changes we need to get to an agreed version. Feel free to make any notes on the wiki page or the discussion thread obviously.

The thing is that I actually like the idea to hide especially the language fields and explicit party self entries and instead work with some defaults. There is just some stuff that needs to be handled by the server and I don’t think it is very much work to implement these things right away. E.g. extracting the composer from spring boot is a matter of few hours (if not minutes) to implement.

Stefan has actually managed already to implement both formats, input and output, and he only needs to do these tweaks + the “switch” to raw json representations (if this is more convenient compared to the simSDT format)

Edit: we also have an implementation of the webTemplate/simplified Json Template format. Might also be good to get into a deeper discussion on the details.


Not sure if this deserves its own thread: we also found a small difference regarding the naming convention.

Better format:


I think there are good arguments for both approaches but I think sticking to the RM would be consistent here.

1 Like

I agree sticking with RM in future but it would be good to support the Better format initially as well. And I appreciate that this will be very annoying :slight_smile:

I would say sticking to RM is the only real answer. If not we would need a comprehensive list of all these differences

1 Like

I agree, as part of the formal standard, but for practical purposes, right now, supporting both would be very helpful indeed.

@yampeku is right though, we would need a full list of these deviations. I might be able to work it out myself, I remember running across more than one of these when comparing the Better spec to the RM.

1 Like

This was my attempt to model the Marand ‘ctx’ structure.

1 Like

Thanks Tom,

what should be added imo is a column with information such as

If data.origin is not set by the client, the value from ctx/time is used

Would be great if @matijap could provide this information if this has not been part of the spec that you got from Better.

On that particular data point, we have had the idea for some time (probably there is a PR or CR for it) to add something like ENTRY.effective_time() which takes the ‘obvious’ value from OBSERVATION, EVALUATION etc. We could include such a value as a field (i.e. not a function) in a simplified / serialised Entry.

FYI, the implementation in EHRbase is now complete, only doing some minor bug fixes. Took a bit longer due to Stefan’s duties in other projects but I’m very happy that we now have an open source implementation as part of the openEHR SDK and EHRbase


Great news. When is it expected to be released?


It’s currently on the EHRbase develop branch. I guess the team will soon make a new release but you can already use it.

Thank you. Will check it out