FHIR Chat · Clinical Notes guidance

Stream: argonaut

Topic: Clinical Notes guidance

Josh Mandel (Oct 17 2018 at 16:57):

For https://argonautproject.github.io/clinicalnotes/, a couple of questions:

1. Does/should the guidance page include some recap of the discussion from the most recent Connectathon, that notes captured in a diagnostic report would be available via DocumentReference in addition to DiagnosticReport?

2. For notes based on a procedure (e.g., randomly let's talk about https://details.loinc.org/LOINC/30621-7.html) would the document be expected to include (more or less) a "complete note" including the content described in that LOINC code (e.g., history, impressions, conclusions)? i.e., not just the impressions section? Again, a quick sentence in the guidance page might help.

@Brett Marquard

Brett Marquard (Oct 17 2018 at 16:58):

New connectathon guidance isn't present yet -- I plan to add by Monday.

Brett Marquard (Oct 17 2018 at 18:04):

on 2, yes, I would expect the note to be more than just impressions section

Brett Marquard (Oct 17 2018 at 18:04):

I will post a note here when I complete updates to the IG...lots needs to be added and it would be good to have lots of eyes on it!

Brett Marquard (Oct 23 2018 at 16:09):

Expanded guidance is now posted.

Jason Walonoski (Oct 24 2018 at 00:38):

I still think $expand feels weird. What is the expected response? A ValueSet?

Brett Marquard (Oct 24 2018 at 12:10):

yep.

Drew Torres (Jun 30 2020 at 20:28):

http://hl7.org/fhir/us/core/STU3.1/clinical-notes-guidance.html I think I want to make sure I understand the implementation. Is it OK to expose a DiagnosticReport link and a PDF link on DocumentReference? DIdn't we want like cardiology/pathology/radiology report as DiagnosticReport links?

Drew Torres (Jun 30 2020 at 20:37):

I think the spec is saying to do this:
DocumentReference.content.attachment.url
www.fhir.com/Binary/12345
DiagnosticReport.presentedForm.url
www.fhir.com/Binary/12345

What I thought we intended:
DocumentReference.content.attachment.url
www.fhir.com/DiagnosticReport/123
DiagnosticReport.presentedForm.url
www.fhir.com/Binary/12345

We can also do this, but doesn't this break/violate the intent of DocumentReference content?:
DocumentReference.content.attachment.url[0]
www.fhir.com/DiagnosticReport/123
DocumentReference.content.attachment.url[1]
www.fhir.com/Binary/12345
DiagnosticReport.presentedForm.url
www.fhir.com/Binary/12345

Brett Marquard (Jun 30 2020 at 21:06):

I am not sure how to respond to all the individual questions on phone so I will say yes.

Brett Marquard (Jun 30 2020 at 21:06):

We intended to have systems that can expose diagnostic Report expose that way

Brett Marquard (Jun 30 2020 at 21:07):

AND expose by document reference. I can write out more tonight when at desk and confirm what made spec

Drew Torres (Jun 30 2020 at 21:08):

OK I have some concerns and can chat to articulate better, but I think option 3 would be fine, but I think option 2 is ideal.

Drew Torres (Jun 30 2020 at 21:09):

But is option 3 OK under DocumentReference?

Drew Torres (Jun 30 2020 at 21:09):

We can chat later when you are at desk :-D

John Moehrke (Jun 30 2020 at 21:11):

Nothing is against the rules in DocumentReference... but in the case where the attachment.url is a DiagnosticReport then the mime type would be FHIR and not PDF

Michele Mottini (Jun 30 2020 at 21:12):

We understood - and implemented - option (1)

John Moehrke (Jun 30 2020 at 21:13):

so you need to look at the attachment.contentType to see how to interpret the content at the attachment.url

Michele Mottini (Jun 30 2020 at 21:13):

DocumentReference and DiagnosticReport having the same content - that is the actual HTML / PDF / plain text etc of the report

Drew Torres (Jun 30 2020 at 21:14):

Right, but that sucks for clients.... I as a server know the exact diagnosticreport and can link directly to it for any additional metadata available.

John Moehrke (Jun 30 2020 at 21:14):

In your third option you are itterating at .content[], not at url

Drew Torres (Jun 30 2020 at 21:14):

Right

Drew Torres (Jun 30 2020 at 21:15):

there are 2 contents the diagnosticreport if you are interested and the binary if you don't want/need the additional metadata.

John Moehrke (Jun 30 2020 at 21:16):

fourth option that I would prefer
DocumentReference.context.related
www.fhir.com/DiagnosticReport/123
DocumentReference.content.attachment.url
www.fhir.com/Binary/12345
DiagnosticReport.presentedForm.url
www.fhir.com/Binary/12345

Drew Torres (Jun 30 2020 at 21:17):

I can get behind that too.

Michele Mottini (Jun 30 2020 at 21:58):

that sucks for clients

I do not agree. It allows the client to process the content (either presentedForm or content) always as 'as is' data to be retrieved and stored without processing- much easier

Michele Mottini (Jun 30 2020 at 21:58):

(And we do write clients - not talking about 'in theory')

Drew Torres (Jun 30 2020 at 22:02):

I know you are both :-D I suppose you have never cared for any of the metadata that may only exists on disgnosticreport... or the discrete observation references that we are planning to support as part of cures updates then.

Michele Mottini (Jun 30 2020 at 22:04):

...we get those directly from the DiagnosticReport resource (?)...

Drew Torres (Jun 30 2020 at 22:12):

I guess this isn't coming across well here. When you query DIagnosticReport you have no hint that it could be a potential duplicate from a previous DocumentReference . If we return the link directly as part of DocumentReference you can now know that this particular DiagnosticReport is a duplicate of the documentReference, or make a determination to display discrete values because they may be available as part of that direct link instead of having to again search DiagnosticReport.