Semi structured narrative data

[joostholslag]

@borut.jures

My comment was only for the part about using markdown for data entry. Since the markdown field is free-form text, it needs to be converted into DV_TEXT or other structures.

It looked to me that you would like markdown to work the same way as DV_PARAGRAPH. My suggestion is to separate data entry (using free form text with auto-suggestions) and create DV_TEXT or other structures in the background. I would expect clinicians aren’t too happy to “build” these structures during their data entry. They shouldn’t be bothered with that if we can perform the transformation in the background.

A DV_TEXT.value can contain the text in markdown format, if DV_TEXT.formattign is set to markdown. That’s not the issue. The issue is how to then query based on snomed codes, and the other context info, like what kind of match it is (exact, narrower, broader etc), how to recognize it’s snomed (not loinc), the purpose of the mapping, the preferred term displayed etc. And this with the openEHR premise of a specified data format where different client apps can natively interact with different backend CDRs.

I agree you want to seperate partly data entry from storage. You probably want user confirmation on the mapping, and may want to suggest a fully structured form based on the text input. And you definately do not want to render separate text fields for the 4 data parts I previously described.