Embedding of HTML in Markdown inside DV_TEXT

Specifications
1

Hi all,

we got a customer project where we are doing integration from an EMR system. The EMR systems stores free text which includes html tags for formatting (paragraphs, headlines etc.). I remember we had some discussions in the past about the use of only Markdown as valid formatting option in DV_TEXT. Now I explorer a bit the options how we can proceed without reverting to the DV_PARSABLE (which is missing in most archetypes anyway and is deprecated?) or transforming from HTML to Markdown as part of ETL.

A possible answer I found was that in commonMark, it’s actually allowed to embed raw html. So technically this seems to be possible. However, I was wondering if others have come across this requirement and what way they chose. Of course this raises some interesting questions about sanitizing input.

Cheers

2

I don’t have a good answer, only a few observations in the hope that they are helpful:

  • DV_PARSABLE is not deprecated to my knowledge (DV_PARAGRAPH is)
  • Not sure DV_PARSABLE was intended to be used for html, but in any case, yes, it would require it to be present in the archetype, e.g. as a Choice between DV_TEXT and DV_PARSABLE in my understanding?
  • There is a section in the DV_TEXT spec indicating that markdown should not contain html (5.1.7. Formatting and Hyperlinking)

Not all CommonMark features are allowed in the value field, if it contains markdown. The following should not be used:
HTML ‘blocks’;
raw HTML;
images - these may be included in openEHR content via the DV_MULTIMEDIA types.

Possibly extending the supportedformatting values of DV_TEXT to include html may be the cleanest way of supporting this requirement. But then again, someone may need the mixture of (pure) markdown and html, in which case removing or softening the above “not … allowed” and “should not be used” restriction may be more helpful.

All that said, I think we had a good discussion about preferring markdown over html (or DV_PARAGRAPHS using css as formatting) when rewriting this part of the spec and input sanitation was part of that discussion. However for integration, it may simply be unavoidable.

3

To me a dv text value should be human readable as raw. Markdown is close enough and I would say html is not. So I agree with the current state of the specs.
What’s the downside of converting rtf/html to markdown as part of the etl?
If you are concerned about persisting the original a custom (generic entry) archetype as an interim/additional details cluster may make sense.

4

I was considering doing it like his: convert to markdown and then store the original text in feeder_audit . So we will have an attempt in this direction

5

Convert to markdown and store in DV_TEXT and store the HTML in feeder_audit?
If it is stored as markdown in DV_TEXT, when it is retrieved by another system, does that set an expectation that the frontend applies it?

6

They only time this I need it HTML tag was for underlining text which in markdown is not supported because it is used for hyperlinks but I think definitely we need some way of representing structured text because it’s not just looks of it but semantics is embedded what’s the title which is kind of an important things that defines what’s coming down and also numbered or bullet lists and tables. I love MD BTW

7

That is what I would do. If they want to use complex HTML, not just formatting that can be accommodated by markdown then you need to use DV_PARSABLE, and treat it as opaque content (which still might be displayable, based on formalism - in this case it would be).

8

The stored HTML value in DV_TEXT itself isn’t the problem. You can put HTML in it today and nothing stops you, since CommonMark allows raw HTML and the RM has no rule to reject it. The spec only says it “should not be used”. The problem is on the client side, where that text gets rendered. If we decide to render HTML as intended, then we rely on every client that shows it to sanitize it properly, so it does not execute any malicious code in the background without the user knowing.

To make it concrete: HTML can carry a script, or a hidden link, that is completely invisible when the note is displayed but runs in the background the moment someone opens it. It could send the user’s session or other sensitive user data somewhere else, and the clinician reading the note would not notice anything. If a composition accepts patient-entered text, that payload ends up in the CDR and fires in every client that shows it, unless every single one of those clients sanitizes it correctly. That’s a lot of trust to place in every client out there.

9

The full quote is:

Not all CommonMark features are allowed in the value field, if it contains markdown. The following should not be used: …

I guess you can read this as either “strongly discouraged” or “forbidden”.

In any case, I agree with you…if html is in there for whatever reason, it MUST be sanitized to avoid e.g. XSS attacks.

In cases where it can be avoided by using or converting to (pure) markdown (and then using feeder_audit for the original text) that seems a better option to me.