Stream: implementers
Topic: USCDI Clinical Notes
Dawn Bekemeier (Jun 29 2020 at 19:04):
HI everyone. I am a product owner and trying to write the stories for the Clinical Note portion of USCDI. We have a few interpretations of what Clinical Note really is and means. Is clinical note a 'type' if you will that when a user opens a patient chart they can query for all progress notes? Procedure notes? AND within those clinical notes (documents) we must be able to send any free text or narrative for different sections, such as meds, allergies, something the provider wants to notate in ROS that is not in a structured format ? OR is it where we (as developers) have to say okay, if a provider types narrative in the Assessment area and the Plan area, that has to be assigned to Consult Note and can not be associated to anything else?
Lloyd McKenzie (Jun 29 2020 at 22:21):
@Brett Marquard @Eric Haas
Brett Marquard (Jun 29 2020 at 22:53):
You should be able to send the full progress note
Brett Marquard (Jun 29 2020 at 22:54):
Clinical notes is a tricky term, if your system considers it a note, it should be available
SueAnn Svaby (May 13 2021 at 19:00):
I have been struggling to understand what exactly is required for Cures Cert when it comes to (g)(10) and Document Reference. The Companion Guide for (g)(10) specifically indicates "plain text" while FHIR V4 documentation mentions all types of different formats. If I get an API call for Progress Notes, what should be included in the response?
Eric Haas (May 13 2021 at 20:35):
here is the guidance:
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 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. 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. Additionally, “plain text” does not necessarily mean the FHIR “contentType” “text/plain.”
SueAnn Svaby (May 14 2021 at 15:12):
Eric Haas said:
here is the guidance:
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 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. 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. Additionally, “plain text” does not necessarily mean the FHIR “contentType” “text/plain.”
I appreciate your quick response Eric but I have read that about 50 times and I still don't understand what it means. In our system, we generate a printable document at the end of each encounter. The format is similar to docx. What do we do with those documents? We don't have text fields that host clinical notes.
Michele Mottini (May 14 2021 at 15:59):
I read that as requiring you convert your 'similar to docx' format to plain text or maybe HTML. If you rally cannot do that return what you have (but clients would not be able to do much with it...)
Jenni Syed (May 14 2021 at 16:04):
I could be wrong, but I thought specifically the goal was "native as it is stored" as "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. Additionally, “plain text” does not necessarily mean the FHIR “contentType” “text/plain.”"
Jenni Syed (May 14 2021 at 16:05):
was the clarification when we asked about what exactly they meant by machine readable, and that we had items stored natively as rtf... but could be misremembering the discussion?
SueAnn Svaby (May 14 2021 at 16:06):
We are actually thinking about converting our files to text. I wanted to make absolutely sure that it is required before we go forward with that solution. Normally, we take our proprietary document format and convert it to PDF before we send it out to ensure clients can read it. Is the idea that the machine readable content can be imported and incorporated into another system's workflow? As opposed to importing a PDF and needing to open it outside of the provider workflow?
Cooper Thompson (May 14 2021 at 18:33):
Converting to text/plain from a richer format can be dangerous. For example, if your proprietary format supports strikethrough, then when you convert to text you could be negating the meaning of statements that have a strikethrough, since that can't be represented well in text/plain. If you do need to convert, converting to another rich format (RTF, HTML, markdown) can have the potential to avoid that sort of issue (of course you still need to convert markup accurately).
SueAnn Svaby (May 14 2021 at 18:52):
That is a very good example Cooper. We have discussed similar dangers which is why I need to make sure I completely understand what is required. Our system is different from many others in that the providers don't need to type paragraphs of content. Our users can generate notes that include the discrete data. We could try to generate the content and store it in a text field but then all of the formatting is lost.
Cooper Thompson (May 14 2021 at 19:04):
If your inputs are discrete data, can you just return those directly in your other USCDI APIs, or possibly as Observations if none of the other APIs make sense? I'm not sure why you need to go down the notes route in the first place if your users don't actually type notes.
Peter Jordan (May 15 2021 at 23:33):
Interesting thread. Looking at the 5 categories of 'Clinical Notes' in USCDI - the definition of Consultation Note (ie, 'Contains the response to request from a clinician for an opinion or advice from another clinician.') is different from that used here in NZ where, in primary care at least, it relates to the notes made by a clinician during a consultation that may lead to a diagnosis and treatment plans. Typically, it might include SOAP notes and will be available on patient portals if a clinician consents to the Open Notes approach, as well as passed in GP2GP when patient records are transferred to a new practice.
This issue may extend beyond USCDI if that is aligned to the IPS and Clinical Notes are added to the later. We've also had discussions with primary care clinicians about whether Consultation Notes should go in a patient summary and the general feeling is that they shouldn't - particularly after we've shown them practical examples of some of the format conversion issues that @Cooper Thompson refers to.
SueAnn Svaby (May 16 2021 at 19:18):
@Cooper Thompson We do support all of the other USDCDI elements and we support Document Reference which returns all of our artifacts (converted to PDF). The only reason we are trying to go down the notes route is to attain Cures Certification. Bottom line is that FHIR says "send whatever you have" and the regulation says "send your text". You are saying; if we don't have text to send, then we don't send text (and I believe @Jenni Syed was making that point as well). I suppose I have to take this issue up with ONC and explain that our clinical notes don't live in our system as plain text. I appreciate all of your responses to help me gain clarity on this issue. Thank you so much!
@Peter Jordan I have looked at the definition of the each of the clinical notes and have come up with similar questions. The Laboratory Report Narrative is confusing. Does the narrative come from the lab? Or is it expected that the ordering provider always writes a paragraph or two about the results once they are received? Our providers can enter comments associated with a set of results but it wouldn't make sense to send the comments without the discrete data. Including the lab data as plain text in the Laboratory Report Narrative would require the reader to spend a lot of time deciphering the content. The requirement for "plain text" sounds so simple but it is creating some BIG challenges for me:(
Cooper Thompson (May 17 2021 at 13:00):
For lab, you'd probably send a DiagnosticReport for each lab test, and then a set of Observations. Some of the Observations would be the discrete component results, and you'd send another Observation for any narrative content. If you allow comments that pertain to specific components results, you'd have to figure that out, but typically I expect any narratives would be against the overall test (DxRpt).
Last updated: Apr 12 2022 at 19:14 UTC
