Stream: implementers
Topic: SOAP Notes
kler (Jan 29 2018 at 12:19):
can any one tell me that which resource can be used for SOAP notes?
Lloyd McKenzie (Jan 29 2018 at 12:33):
The answer to that question isn't fully nailed down yet. However the leaning is ClinicalAssessment.
Rob Hausam (Jan 29 2018 at 12:35):
I'm not sure if that's really the leaning :)
Lloyd McKenzie (Jan 29 2018 at 12:37):
Has PatientCare landed on a different approach?
Rob Hausam (Jan 29 2018 at 12:37):
Hopefully we'll get some further clarity on that today Q2 in Patient Care.
Rob Hausam (Jan 29 2018 at 12:39):
It's been mostly on the back burner lately, but PC wants to try to land it.
Alexander Henket (Jan 29 2018 at 12:39):
You might want to check a previous discussion here https://chat.fhir.org/#narrow/stream/implementers/subject/GP.20Encounter.20Report
And check the attached stuff from the agenda of todays PC meeting that Rob refers to: wiki.hl7.org/index.php?title=January_2018_WGM_New_Orleans;_Jan_27_to_Feb_8
Rob Hausam (Jan 29 2018 at 12:39):
Yes.
Alexander Henket (Jan 29 2018 at 12:40):
My current leaning is Composition by the way. I've not yet checked the ClinicalNote thing that's been proposed (saw that this morning in the agenda)
Alexander Henket (Jan 29 2018 at 12:41):
I do not really see why structured reporting would be more than a profile on Composition, but I might be missing previously discussed rationales
Lloyd McKenzie (Jan 29 2018 at 12:46):
Composition is a way of packaging data into a document. It doesn't define net new data - that all needs to live in another resource or set of resources. (And you shouldn't ever have to use documents to share any set of clinical or administrative data.)
Rob Hausam (Jan 29 2018 at 12:51):
That's a good part of what we need to discuss and decide - where do we represent the text of a written document (for this purpose, as well as others).
Michelle (Moseman) Miller (Jan 29 2018 at 12:58):
I think it is safe to say PatientCare doesn't want to use ClinicalAssessment. I believe the leading candidates at the moment are DocumentReference and Composition. Structured Document says that Composition can include net new data (in theComposition.section.text element).
Rob Hausam (Jan 29 2018 at 13:14):
What Michelle says is, I believe, the current leaning in PC.
Lloyd McKenzie (Jan 29 2018 at 13:44):
Any information in FHIR can be represented in a document, but we try to ensure that all FHIR information never has to be conveyed in a document. So whether we're talking about a discharge summary or a referral or anything else, you can package up all of the information and send it as a message or access the resources by navigating a RESTful resource cloud or over some other paradigm. I don't understand why this one particular set of data would need to have an exemption from that principle. At minimum, I think we'd need to take this up with FMG
Eric Haas (Jan 29 2018 at 16:39):
@Lloyd McKenzie you have a .text element that by definition means composition is this source of information. And I have several comments and followup to get Composition != Document, since I believe this conflation is the source of a lot of confusion.
Lloyd McKenzie (Jan 29 2018 at 17:51):
But composition.text is text that is about the compilation of the information. It's not appropriate to use it to capture an individual assessment. The semantics of assesment are "Observe" not "collect together".
Alexander Henket (Jan 29 2018 at 20:49):
I'll have to chew on that @Lloyd McKenzie. The separate journal entry lines are never queried. They are always queried in context to each other. Suppose I really extract the section.text into an Observation, it'll be an Observation (S-O-A-P) that is impossible to look at unless you also get the rest.
Lloyd McKenzie (Jan 30 2018 at 00:27):
Similar issue for "would you ever get the MedicationRequest without the Medication" or the "Observation without the Specimen". And I'm not sure that it's true that you will ALWAYS want to look at all 4 parts of the SOAP. Sometimes you might just want to query the "Plan" part for example.
Eric Haas (Jan 30 2018 at 01:05):
"But composition.text is text that is about the compilation of the information." That intent was not communicated clearly at all... That is not how many of us use it or interpret it as. It looks like a place to stick free text blob for narrative only sections. I think Alex had a tracker that I have added extensive followup regarding this.
Lloyd McKenzie (Jan 30 2018 at 02:04):
We have a challenge that there are multiple perspectives on this. There are absolutely times where the Composition.text will be the only thing that exists - but that SHOULD happen only when you're dealing with systems that can't/won't encode the data or may not understand what the data is. From a FHIR architecture perspective, it SHOULD always be possible to represent the information in an appropriate "semantic" resource. That way the information can be expressed in a coded way and queried/manipulated independently of how it might be packaged in a particular document representation. It may be that convention is that such discrete representation simply isn't "a thing" for stuff like SOAP notes. Or practices might vary by system or by type of note. But if we have a situation where the only place we can represent fully coded information is within Composition, then we've probably done something wrong.
Michael Donnelly (Jan 30 2018 at 16:13):
In practice, even notes that could be represented as discrete data often won't be. Until NLP advances and is widely adopted, plaintext notes are going to be the only place where important information exists.
Michael Donnelly (Jan 30 2018 at 16:13):
And it isn't only important to pull notes out of an EHR; they also need to go back in.
Michael Donnelly (Jan 30 2018 at 16:14):
Many clients will be unable and/or users will be unwilling to code the information manually.
Josh Mandel (Jan 30 2018 at 16:14):
I agree wholeheartedly on both points!
Eric Haas (Jan 30 2018 at 16:27):
@Lloyd as I read your interpretation let me rephrase into my crude words:
Comp is a wrapper for an annotated outline of resources and .text should not be there.... If I scribble down a few sentences for a progress notes they should be stored in some resource ( clinical impression is my fav) instead of cramming into .section.text... so why the hell is .section.text there. IMO we've probably ignored this issue too long.
Michael Donnelly (Jan 30 2018 at 16:31):
Yes, it's definitely been out there for too long.
Michael Donnelly (Jan 30 2018 at 16:32):
I'm not strongly invested in any one specific solution. But we need something that will hold a note without needing much else.
Grahame Grieve (Jan 30 2018 at 16:35):
that's important to me too - "notes" spans a wide range of contents from a few paragraphs entered into the patient record through to a carefully constructed document with controlled structured data for exchange with an external party
Grahame Grieve (Jan 30 2018 at 16:35):
the kinds of solution that work for the first case are not the ones that are suitable for the last case. That difference creates confusion
Michael Donnelly (Jan 30 2018 at 16:44):
I agree.
Michael Donnelly (Jan 30 2018 at 16:44):
We have an urgent need for the former.
Michael Donnelly (Jan 30 2018 at 16:46):
And the latter is handled with C-CDA and Binary.
Michael Donnelly (Jan 30 2018 at 16:46):
But I don't think anyone wants the overhead of C-CDA for a few paragraphs of text with no other data.
Eric Haas (Jan 30 2018 at 17:31):
@Michelle (Moseman) Miller and @Brett Marquard This is strongly suggests to me that there is a tough choice to:
- a single resource that we can point to use for any kind of scribbles from a provider for any context So a PR goes here a History here and a PE here.
- a directory of resource for scribbles from a provide for reach context. History --> obs, PR --> clinical impression, phone call --> communication etc.
Brett Marquard (Jan 30 2018 at 17:34):
We discussed this during the connectathon, and in Patient Care yesterday. Current leaning is to use DocumentReference to discover these 'notes'. The DocRef could return a pointer to a Binary (PDF, RTF, etc.) or something which support structure (Composition, or Binary-C-CDA)
Brett Marquard (Jan 30 2018 at 17:34):
This will allow a client to query for a 'Discharge Summary' with one entry point and then server can provide the format they have
Eric Haas (Jan 30 2018 at 17:36):
@Brett Marquard did you read the issue above with the creation and representation of the "de-novo" content which I refer to as provider 'scribbles' (Cliff notes: It is not supposed to go into .section.text.)
Eric Haas (Jan 30 2018 at 17:37):
and binary provides no context
Grahame Grieve (Jan 30 2018 at 17:38):
yes (agreeing with Michael)
Brett Marquard (Jan 30 2018 at 17:38):
context for binary is provided by the DocRef
Michael Donnelly (Jan 30 2018 at 17:38):
How does that address creating notes?
Brett Marquard (Jan 30 2018 at 17:41):
Maybe I am not fully understanding intent of 'ClinicalImpression' - do we have a list of values for clinicalImpression.code?
Eric Haas (Jan 30 2018 at 17:41):
DocRef is clear for retrieval but not for creation and that is what I keep stumbling over
Eric Haas (Jan 30 2018 at 17:42):
If we can articulate that then I agree could use it.
Brett Marquard (Jan 30 2018 at 17:42):
@Michael Donnelly in clicnialImpression, would you want to exchange as RTF?
Brett Marquard (Jan 30 2018 at 17:43):
I guess root question is probably getting better understanding of intended use of Clinicalmpession
Michael Donnelly (Jan 30 2018 at 17:43):
I don't think anyone should exchange RTF ever.
Peter Jordan (Jan 30 2018 at 17:44):
...along with a whole host of other formats we see in NZ GP2GP (transfers of complete primary care records)!
Brett Marquard (Jan 30 2018 at 17:46):
oh, funny, that came up as a use case this weekend.
Peter Jordan (Jan 30 2018 at 17:48):
Well over 80% of point-of-care systems that I've seen have free text controls for notes/comments in every clinical and administrative entry - these are used for both structured and unstructured notes. When this information is exchanged, receiving systems are going to expect to be able to (re)populate the 'notes' in those entries and won't take kindly to having to extract them from aggregations (or external documents).
Rob Hausam (Jan 30 2018 at 17:49):
In the scope and use of ClinicalImpression we say "An impression is a clinical summation of information and/or an opinion formed, which is the outcome of the clinical assessment process." Assuming that we don't want or intend to change that, the impression is an important part of many (not all) notes, but it definitely is not the note.
Eric Haas (Jan 30 2018 at 17:58):
Why is this suggestion hated by implementers? Sticking the "de-novo" text in the resource .text ?
~~~
<Observation xmlns="http://hl7.org/fhir">
<id value="foo"/>
<text> <status value="additional"/> <div xmlns="http://www.w3.org/1999/xhtml"><p> <b>*FREE TEXT HERE* </p> </div> </text>
<status value="final"/>
<subject>
<reference value="Patient/example"/>
</subject>
<effectiveDateTime value="2016-05-18"/>
</Observation>
Peter Jordan (Jan 30 2018 at 18:04):
Shouldn't all the text be populated from 'atomic' data elements in the resource, or is that just for CDA?
Rob Hausam (Jan 30 2018 at 18:06):
This seems to say that in a general "observation" (no specific code or value) you can say anything about everything (or vice versa)?
Alexander Henket (Jan 30 2018 at 18:07):
If Composition.section.text ist Verboten and every section just consists of the entries that contain the text a reader should read (in the order occurring), how is that helping a reader?
Alexander Henket (Jan 30 2018 at 18:09):
Even worse: why would I use Composition at all and not just a pure Bundle of "Observations"?
Eric Haas (Jan 30 2018 at 18:10):
@Alexander Henket the Composition.text should be a union of all the resource narratives. This topic is a particular unclear set of guidance in the resource and I think we both commented on that in GForge.
Brett Marquard (Jan 30 2018 at 18:11):
let's say there are no nested resources -- could Composition.text contain the Note?
Eric Haas (Jan 30 2018 at 18:11):
@Alexander Henket Composition is like a table of contents. Still begs the question what is the section.text is for.
Brett Marquard (Jan 30 2018 at 18:11):
Hmm, I don't view Composition as a Table of contents, but we can get to that when we discuss those logged trackers
Alexander Henket (Jan 30 2018 at 18:13):
section.text at minimum is just that, might have no entries. Second option is the sum of the entry resources.text. Third option is a mix (just like in CDA). Section.text.type indicates what the sender did
In any case: section without section.text is pointless to me
Alexander Henket (Jan 30 2018 at 18:16):
What I showed Monday was section.text, no entries. Reason: you are never going to query separate journal entries (SOAP) in our context. So although you might envision exposing SOAP Observations, there's no current pressing need to.
You could compare section.text without entries to CDA Level 2.
Grahame Grieve (Jan 30 2018 at 18:49):
@Rick Geimer @Brett Marquard does SD have updated scope text after Q1 this morning?
Lloyd McKenzie (Jan 30 2018 at 21:58):
Joining this a little late:
@Eric Haas The purpose of Composition.section.text (as I understand it) is as follows: The narrative that makes sense when a resource stands alone doesn't always work well when you're rendering it as part of a list of narratives that make up the rendering of a document. As well there are a couple of additional cases - section resource doesn't have narrative (for whatever reason) and because there was a desire to avoid the overhead of List whenever you had a section that points to a collection of things. So there is use for it. However, there's not intended to be any situation where, when FHIR is "done", there's content that can only be expressed in Composition.section.text and doesn't have a home in a resource narrative or other discrete resource element. Composition.text is generally intended to be the rendering of the document's metadata. So it's generally needed. For a non-encoded document, it would also represent all other content of the document - and there are legitimate cases for that. The "rule"/"intent" of the Composition design (as I understand it) though is that there should never be a situation where the only place that a piece of information can appear is in Composition.text or Composition.section.text and there's no other resource home for that data if someone wants to fully encode. (There's absolutely situations
@Brett Marquard I would like to ensure that we're not limited to only Binary or Composition. Observation should absolutely be in the list. And ClinicalImpression too, most likely
Eric Haas (Jan 30 2018 at 22:01):
Shall we put that in the definition of section.text :-)
Eric Haas (Jan 30 2018 at 22:05):
That is not very clarifying Lloyd and this also begs the question of where do the section resource narratives go? it sounds like you said in section.text instead of the [resource].text ( or both?) I think appending in the Composition.text makes sense.
Lloyd McKenzie (Jan 30 2018 at 22:18):
If a section has text, you render that in place of the resource narrative.
Lloyd McKenzie (Jan 30 2018 at 22:19):
Each MedicationRequest might say "John Smith (MRN 12345) was prescribed....". If you concatenate 5 of those together, that's going to get really annoying. The Section.text can put together a nice table and wouldn't mention the Patient at all because that'll be handled by rendering the subject hanging off the Composition
Venkateswara R Davuluri (Jan 30 2018 at 22:22):
We are using composition resource to include all resource references. And one resource is clinical impression, where we can include the "free text".
Eric Haas (Jan 30 2018 at 22:25):
Lets keep it simple ... I have one section and one resource. Where does the narrative for the resource go? Append to Composition.text, section.text, or [resource].text?
Lloyd McKenzie (Jan 30 2018 at 22:31):
Narrative for the resource goes in Resource.text. If, for some reason, the author of the document feels the narrative needs to be tweaked for use in the document, they put that in Composition.resource.text. If the document has no resources or sections, the content could go in Composition.text
Drew Torres (Jan 30 2018 at 22:37):
In our system we have the concept of a document that is a mixture of free-text sections, and structured sections that can reference data that lives somewhere else. The free-text sections only exists in that section of the document. There is no other place that is lives other than in the context of that free-text box in the UI that is then stored as a data element of the document. Putting that all in a composition.text doesn't feel structured/interoperable. Doesn't CDA have this concept today? A section has a template id that identifies the type of data in the document that can then have free-text/narrative? Can't we achieve the same thing in composition?
Eric Haas (Jan 30 2018 at 22:39):
We did not say put the text only in Composition.text. I am only talking about how the narrative for the whole shebang is rendered.
Grahame Grieve (Jan 30 2018 at 22:40):
@Andrew Torres I believe that is the core question over which we proposed a connectathon track
Eric Haas (Jan 30 2018 at 22:40):
but it sounds like you are doing it wrong by sticking "de-novo" text into section.text. In other words it needs to live elsewhere based on this chat.
Drew Torres (Jan 30 2018 at 22:42):
@Eric Haas sorry I must have misunderstood. In comparing with CDA do you have one huge narrative? Don't style sheets give the nice representations, and just link to the respective sections?
Eric Haas (Jan 30 2018 at 22:44):
sure but this also relates to what gos in section.text and resource.text that are referenced in the section
Grahame Grieve (Jan 30 2018 at 22:46):
@Eric Haas : "but it sounds like you are doing it wrong by sticking "de-novo" text into section.text. In other words it needs to live elsewhere based on this chat." - it's not wrong. It's better to put it elsewhere, but it's not something that you SHALL do. I disagree with Drew about the best way to do it in this case, but it's for me to demonstrate the practical advantages I claim that exist. I'm looking forward to the connectathon
Drew Torres (Jan 30 2018 at 22:50):
Interesting. So, your question was more: If I have have a resource that should be referenced in composition.section should the narrative of the resource.text be in section.text or get appended to composition.text. What I would like to see (if possible) a reference to the resource.text from section.text and/or composition.text, but not sure if people would be supportive of that. I don't see a huge advantage in copying the text from the resource, to the section, and finally to the composition.text.
Brett Marquard (Jan 30 2018 at 23:02):
@Lloyd McKenzie noted, I don't plan to restrict to only Binary or Composition for initial testing
Richard Townley-O'Neill (Jan 31 2018 at 01:56):
@Lloyd McKenzie
Narrative for the resource goes in Resource.text. If, for some reason, the author of the document feels the narrative needs to be tweaked for use in the document, they put that in Composition.resource.text. If the document has no resources or sections, the content could go in Composition.text
Should Composition.resource.text be Composition.section.text ?
Lloyd McKenzie (Jan 31 2018 at 02:26):
@Eric Haas I'm not saying "It needs to live elsewhere". I'm saying "It needs to be able to live elsewhere". We're not going to force systems to fully encode their content
Lloyd McKenzie (Jan 31 2018 at 02:26):
@Richard Townley-O'Neill Yes. Typo on my part. Meant Composition.section.text
Brett Marquard (Jan 31 2018 at 03:49):
@Grahame Grieve Saving discussion on Composition for Scope for Thursday Q3. Regrettably, i won't be there but @Rick Geimer and @Andrew Torres plan to be.
Grahame Grieve (Jan 31 2018 at 12:10):
ok
Alexander Henket (Jan 31 2018 at 15:31):
I'm sorry I can't make it either. I'm happy with @Grahame Grieve's statement that "it's not wrong [to have text in a Composition that is not exposed otherwise]. It's better to put it elsewhere, but it's not something that you SHALL do".
I think most of the discussion should be around Composition.text versus Composition.section.text. The interesting thing about Composition is that it's design is to give some 'structure' to text that in turn may be derived from various entries.
So if the section.text holds the text you need to render, why would you duplicate all that once more in Composition.text. Seems to me Composition.text is probably usually sparsely populated as opposed to .text in other resources.
Grahame Grieve (Jan 31 2018 at 15:32):
Composition is special in that the resource has multiple narratives. So we should be clear and explicit about this. And what we should be explicit about is that composition, you must render all the narratives, and there's no need for duplication
Lloyd McKenzie (Jan 31 2018 at 15:37):
My point is that it's totally fine in some situations to render an allergy list or a diagnostic report using Composition.text or Composition.section.text - but that's never considered the "preferred" way to communicate the resource information. Even if we only have text, it's "better" to capture the individual AllergyIntolerances with narrative only if you can - because then the data shows up in the correct location when someone doesn't query the data as a document. My belief is that note information and other assessments needs to be handled the same way.
Michael Donnelly (Jan 31 2018 at 15:38):
Ideally, I agree completely.
Grahame Grieve (Jan 31 2018 at 15:38):
it seems to me that we have convergence on this point: it's better to do this, but if you can't, you can't
Michael Donnelly (Jan 31 2018 at 15:38):
Right.
Michael Donnelly (Jan 31 2018 at 15:39):
Discrete data are always better than plaintext when you know the discrete values.
Josh Mandel (Jan 31 2018 at 15:41):
And I think Lloyd's trying to build on this with something like "plaintext packed into otherwise-empty domain-appropriate resources is better than plaintext packed into sections of a document."
Grahame Grieve (Jan 31 2018 at 15:42):
the question is whether you have context/metadata/provenance about the resource that makes it possible to have a separate resource
Josh Mandel (Jan 31 2018 at 15:42):
Indeed.
Michael Donnelly (Jan 31 2018 at 15:43):
I can get behind that too.
Peter Jordan (Jan 31 2018 at 20:36):
Interesting, generic article about textual data at https://www.ewsolutions.com/variations-textual-data/
Mike Henderson (Nov 28 2018 at 23:03):
I'd like to see the current ClinicalNote proposal (http://wiki.hl7.org/index.php?title=ClinicalNote_FHIR_Resource_Proposal) advanced, or at least discussed, and would be willing to contribute to whatever work is required to add it to the list of resources. What would it take to get this onto an agenda for the January 2019 San Antonio WGM?
Grahame Grieve (Nov 29 2018 at 09:06):
@Brett Marquard
Brett Marquard (Nov 29 2018 at 13:30):
Thanks Mike and Grahame -- Patient Care and Structured Documents discussed creating a new clinical notes resource, several times. @Michelle (Moseman) Miller can probably point you to the minutes of several of these discussions, if you are interested. In more then one session we compared the potential new resource to Composition/DocumentReference/DiagnosticReport and found it quite difficult to differentiate when a system would use each. Fortunately, the Argonaut participants picked up the problem of 'exchanging Clinical Notes' and hosted a connectathon in May and September this year, and have decent design for exchange any clinical notes. -- no design is perfect, but please check it out and let us know what you think - Argonaut Clincal Notes . @Eric Haas and I presented some of this design at the Septemebr Work group and put much of the design in the HL7 ballot US Core.
Michelle (Moseman) Miller (Nov 29 2018 at 13:49):
I'll just add that we do have a quarter (Tues Q2) at the Jan 2019 WGM planned to discuss clinical notes. It is a joint quarter with Patient Care hosting OO (who owns DiagnosticReport), II, and SD (who owns DocumentReference). I'm chairing this quarter. The exact agenda isn't nailed down yet, but I suspect it will be a continuation of the strategy that Argonaut has started (i.e. which pieces of the IG need to be folded back into the core FHIR spec). I presented at DevDays on ClinicalNotes and there was some additional feedback to share, but I don't foresee Patient Care pursuing a new resource.
Last updated: Apr 12 2022 at 19:14 UTC
