# Data capture from Rich Text editor

**URL:** <https://discourse.openehr.org/t/data-capture-from-rich-text-editor/17213>\
**Category:** Clinical\
**Created:** [20 August 2026 11:02 UTC](https://discourse.openehr.org/t/data-capture-from-rich-text-editor/17213 "2026-08-20T11:02:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ian\_Bennett](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian_bennett/32/1283_2.png) [@Ian\_Bennett](https://discourse.openehr.org/u/Ian_Bennett)\
**Post date:** [20 August 2026 11:02 UTC](https://discourse.openehr.org/t/data-capture-from-rich-text-editor/17213/1 "2026-08-20T11:02:49Z")

</div>

Hi, does anyone know if reference model can support data capture and retrieval via a Rich text editor in the frontend? Or does anyone have experience of this?  
A lot of EPRs using proprietary data models will capture progress notes using a Rich text editor.

---

<div class="post-metadata">

**Author:** ![marcusbaw](https://discourse.openehr.org/user_avatar/discourse.openehr.org/marcusbaw/32/4792_2.png) [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)\
**Post date:** [20 August 2026 13:41 UTC](https://discourse.openehr.org/t/data-capture-from-rich-text-editor/17213/2 "2026-08-20T13:41:48Z")

</div>

In terms of persisting the text from the Rich Text Editor, if you can render it as plain text with markup, then it can be persisted the same way as the text from any Entry would be persisted. It’s just text.

Perhaps converting the RTF to [MarkDown](https://www.markdownguide.org/) (trivial, lots of libraries can do this) would be a way to make the Rich Text formatting more portable.

I don’t think the Reference Model has direct provision for RTF or rich text elements, and it probably doesn’t need to have. If you can get the clinical progress note as a text block with a well-known formatting syntax it just persists that. Markdown has been around for 20 years but has gained a huge amount of popularity in recent years because it’s a good middle ground between complex fully formatted text formats and unformatted plain text, and LLMs speak it fluently, without wasting too many additional tokens over it. So as far as I’m concerned MarkDown is the future.

I wrote a thing called Medical Markdown a while ago, not exactly the same as what you’re asking, but aimed at using MarkDown to separate out a single block of free text into sections by parsing section headers.

Source

> **[GitHub - pacharanero/medical-markdown: A Markdown-like specification for quickly writing...](https://github.com/pacharanero/medical-markdown)**
>
> A Markdown-like specification for quickly writing free text medical notes that can be programmatically parsed into structured data, with terminologies where appropriate

Demo

> **[Medical Markdown - redirecting](https://pacharanero.github.io/medical-markdown/)**

Video

[![](https://discourse.openehr.org/uploads/default/original/2X/3/3ad4965910b57811a796a4e94e42835f482461ea.jpeg "'Medical Markdown' - a 10-year-old idea finally gets built!") ](https://www.youtube.com/watch?v=bgVkNkyH7E8)

---

<div class="post-metadata">

**Author:** ![Ian\_Bennett](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian_bennett/32/1283_2.png) [@Ian\_Bennett](https://discourse.openehr.org/u/Ian_Bennett)\
**Post date:** [21 August 2026 08:10 UTC](https://discourse.openehr.org/t/data-capture-from-rich-text-editor/17213/3 "2026-08-21T08:10:20Z")

</div>

Thanks Marcus, these are great resources… will pass this back into some of our developers for comment

---

<div class="post-metadata">

**Author:** ![borut.jures](https://discourse.openehr.org/user_avatar/discourse.openehr.org/borut.jures/32/1391_2.png) [@borut.jures](https://discourse.openehr.org/u/borut.jures)\
**Post date:** [21 August 2026 08:26 UTC](https://discourse.openehr.org/t/data-capture-from-rich-text-editor/17213/4 "2026-08-21T08:26:26Z")

</div>

There is a similar discussion here: [Embedding of HTML in Markdown inside DV\_TEXT](https://discourse.openehr.org/t/embedding-of-html-in-markdown-inside-dv-text/17205)