I’m support that and add the rule that in a situation where terminology and code are not populated, that this can be assumed to be a dv_text. That essentially flattens DV_CODED_TEXT and DV_TEXT and makes it much easier to handle for devs - if the UI returns a code, you must populate code AND terminology or you will get a validation error but if only value is populated and the element allows a DV_TEXT, that will be stored as DV_TEXT. No need to worry about different classes.
I think currently the Better format does allow : “X” :“some text” and does not like " “X|value” :“some text” for a TEXT.
I would continue to allow that as long as we are confident we can spot the stringified CODED_TEXTs.
They are used widely in GDL, and would be really helpful in AQL, so it’s not just about the composition data. The complexity is really all on the CDR side.
It does make documenting use for apps developers much easier, and it should always optional.
I would very much like to start with the intent that the new standard format allows for the Better variations if at all possible. By all means flagged as deprecated and quite possibly removed in the future. I appreciate this might not be wholly possible but the more we can live with ‘units’; vs. ‘unit’ tyep of idiosyncracies, the faster we will get the new format adopted.
Just to be clear, the intention is to handle the ‘Marand web template’ format, or whatever you want to call that (‘ehrscape format’?). This is a base assumption in what I am doing.
2 Likes