Issue with STRUCTURED format

Implementation
,
1

Hi all,

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.

EHRBase returns

“phenotype_description”: [
{
“|formatting”: “plain”,
“|value”: “Skeletal dysplasia”
}
]

Better returns

“phenotype_description”: [“Skeletal dysplasia”]

Have I missed something in how I’m using the API ?

Thanks for the help

2

Hi, that format is not standardized in the openEHR specs, so it’s expected that some miss-alignments could happen between different implementations.

If you want to get always the same format use the canonical openEHR JSON one.

1 Like
3

Hi @Simon,

the implementation in EHRbase is based on the integration tests used by Better’s library (web-template/src/test/resources/convert at master · better-care/web-template · GitHub ) but is a different code base.

I will check with the team about the particular difference and if we can align. Is there anything else that you noticed?

4

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 items[0]items[0]items[5}value if you see what I mean :wink:

1 Like
5

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.

1 Like
6

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.

7

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

“phenotype_description”: [
{
“|value”: “Skeletal dysplasia”
}
]

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.

  1. Support for “phenotype_description”: [“Skeletal dysplasia”] should be added

  2. 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
    ‘value’.

8

I got over-excited and had a look at GitHub - better-care/web-template: WebTemplate implementation for openEHR CDR .

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.

2 Likes