I’m busy building a ‘vendor neutral application’ and retrieving compositions from EHRBase and Better using the structured format. I understand this format is not yet formally a standard but this was the result with a text item.
It was the only issue that I noticed, although it was enough for me to take fright and use the canonical form as @pablo suggested. It takes a lot longer with itemsitemsitems[5}value if you see what I mean
Though paths are longer, the logic to process them is simple and repetitive, on the other hand those paths are standard and will always be the same across implementations if implementations comply with openEHR.
We will investigate anyway and glad to hear this was your only finding. Personally, even after 8 years or so, I don’t fell comfortable to directly work with canonical formats for anything related to application development. Of course we fully rely on the Reference Model internally in EHRbase.
Firstly I certainly regard the structured formats as -de-facto standards now they have been open-sourced and deployed in EhrBase as well as Better CDRs. They are widely adopted, deployed and liked. Of course there are other arguments in favour of canonical formats. However I think these should be separate discussions and not come into a request for help with a specific format
Leaving that aside, let me hazard a guess on what is happening here, as I think both versions should be acceptable. Having said that I’ve not looked at any code so might be barking up the wrong tree.
In most cases, a Text element contains only a value, so Better simplify
to “phenotype_description”: [“Skeletal dysplasia”]
Now Better should, I think, also support the first version, as if nothing else, this makes handling DV_TEXT/DV_CODED_TEXT constraints much easier.
2 possibities in ehrBase.
Support for “phenotype_description”: [“Skeletal dysplasia”] should be added
Support for this already exists but is being nullified by the presence of “|formatting”: “plain”, which is an optional attribute and in my experience so far never populated. It is not wrong per-se but might be forcing the use of the full datatype representation because there is an other attribute alongside v
I think I am on the right track and that perhaps the problem is actually on the Better side, and does relate to the DV_TEXT (and DV_CODED_TEXT / format attribute.
It looks as if my hunch was correct that there is code that is trying to detect a DV_TEXT object which only has the value attribute populated , in which case the simple name/value pair us used. The problem is that it is not testing for the ‘format’ attribute as far as I can tell.
So i think this is because Ehrbase is injecting a default value for format that is not bring handled correctly by Better.
IMV both the simple name/value style and the object with a value attribute should be accepted.