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?
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.
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.
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
@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.
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
