FHIR Chat · US Core vs ONC plain text · argonaut

Stream: argonaut

Topic: US Core vs ONC plain text


view this post on Zulip Jenni Syed (Apr 16 2020 at 16:23):

I'm pretty sure US Core allows for PDF/format of choice for Notes and documents in the clinical note section. However, the 21st Century Cures regulation seems to say Notes are constrained to plain text:
"We note that in the Proposed Rule we proposed in 84 FR 7480 that the clinical note text included in the “DocumentReference” resource would need to be represented in its “raw” text form, and further proposed in 84 FR 7480 that it would be unacceptable for the note text to be converted to another file or format (e.g., .docx, PDF) when it is provided as part of an API response. We clarify that the clinical note text included in any of the notes described in the “Clinical Notes Guidance” section of the US Core IG adopted in § 170.215(a)(2) must be represented in a “plain text” form, and would be unacceptable for the note text to be converted to another file or format (e.g., .docx, PDF) when it is provided as part of an API response."

view this post on Zulip Jenni Syed (Apr 16 2020 at 16:24):

I assume that's just horrible wording and they really meant "represented as stored/used in the source system" - but I'm not missing anything in US Core that would have required this, correct?

view this post on Zulip Jenni Syed (Apr 16 2020 at 16:24):

taking something that is formatted and has (for example) strikethroughs and making it plain text seems dangerous.

view this post on Zulip Robert McClure (Apr 16 2020 at 19:50):

@Jenni Syed I wonder (with no review of Cures to confirm) if the intent was to use a different exchange element to exchange notes that are not plain text? @Brett Marquard @Eric Haas Thoughts on this?

view this post on Zulip Brett Marquard (Apr 16 2020 at 19:58):

This question was posted to Structured Documents Listserv a few weeks back. @Avinash Shanbhag mentioned ONC is reviewing...

view this post on Zulip Brett Marquard (Apr 16 2020 at 20:00):

I don't think ONC intended the media type 'text/plain' here. My memory on intent here was to not have server convert everything to PDF on retrieval.

view this post on Zulip Keith Boone (Apr 16 2020 at 20:01):

Often times, PDF is the raw format HCPs get from third parties. There are ways to EXTRACT that text, but they AREN'T perfect by any stretch of the imagination, and FAX is still used by some, which at the very least, best exchanged using PDF rather than raw image formats which don't support pagination well (TIFF is the only format that really supports paging, and few viewers work, and it's garbage for compatibility).

view this post on Zulip Keith Boone (Apr 16 2020 at 20:02):

At least with PDF you can get to PDF/A without harm to content, and there may be some access to text even with FAX (using OCR) through standardized access methods.

view this post on Zulip Jenni Syed (Apr 16 2020 at 20:06):

I agree it would not be fun to force servers to always convert to some other format, even ignoring the lossy conversion issues. Here's hoping that ends up the confirmed intent :)

view this post on Zulip Matt Rahn (Apr 17 2020 at 19:31):

ONC would like to clarify that clinical note text that originates from Health IT Modules must be exchanged using a “plain text” (e.g., “machine readable”) format. The intent of this policy is to prohibit Health IT Modules from converting clinical notes from a “machine readable” format to a non-“machine readable” format (e.g., PDF). Clinical note text that originates from outside Health IT Modules should be exchanged using its original format. ONC will include clarification in the Certification Program documentation for the associated criteria. Thanks for highlighting this ambiguity.

view this post on Zulip Jenni Syed (Apr 17 2020 at 19:48):

@Matt Rahn We have notes that are raw pdf and scanned in via fax. We were planning on exposing the data as it is raw in our system and read by clinicians.

view this post on Zulip Jenni Syed (Apr 17 2020 at 19:51):

Most of the data today is not in that format, but we would expose what we have. For patient apps that want to actually display data to the user, we also offer to convert to PDF since that is one of the best ways to get a consistent cross-platform view of a document. But they would have access to the raw (eg: RTF) if it wasn't pdf.

view this post on Zulip Jenni Syed (Apr 17 2020 at 20:01):

Going from any of that to plain text/json/xml loses clinical context and human readability, which is dangerous.

view this post on Zulip Vassil Peytchev (Apr 17 2020 at 20:20):

There ought to be a better description of the intent. I don't think that formatting and presentation are necessarily "not machine readable". Was the distinction meant for discrete data?

view this post on Zulip Brett Marquard (Apr 17 2020 at 20:54):

I read as 'maintain the value' of whatever format the server had when passing to a client -- don't convert everything into PDF.

view this post on Zulip Vassil Peytchev (Apr 17 2020 at 20:58):

That would make an excellent clarification, especially since "text/plain" has a very specific technical meaning.

view this post on Zulip Matt Rahn (Apr 20 2020 at 21:08):

Brett Marquard said:

I read as 'maintain the value' of whatever format the server had when passing to a client -- don't convert everything into PDF.

Yeah, thanks Brett. That is what I was trying to convey. You should maintain the value that it was received. If you received and were forced to store as a pdf then it would be ok to return that way. Also, the rule was not meant to imply convert to ‘text/plain’.


Last updated: Apr 12 2022 at 19:14 UTC