Stream: implementers
Topic: How to capture plaintext
Patrick Werner (Mar 20 2018 at 14:25):
We are currently facing the problem how to represent textual notes in FHIR. (e.g. for supportedBy(any) fields). The only option we currently are seeing is to save textual notes inside of a Binary resource. With the downside to be forced to base64 encode plaintext, which feels kind of strange to us as it introduces a transformation step for plaintext which shouldn't be necessary.
Patrick Werner (Mar 20 2018 at 14:27):
One solution to this problem would be to allow content to be a string if contentType equals text/plain
Lloyd McKenzie (Mar 20 2018 at 14:51):
The two solutions that have been discussed are Observation and DocumentReference
Stefan Lang (Mar 20 2018 at 14:53):
As far as I remember from the New Orleans WGM, this is an ongoing discussion at the moment.
John Moehrke (Mar 20 2018 at 15:16):
a DocumentReference pointing at a Binary. Where the Binary holds the text... Although when you upload the Binary it must be encoded inside the Binary resource structure, the same is not true when you retrieve it. If you retrieve it using http mechanisms that indicate you can accept the mime-type that the Binary content is natively known as, you will just get that native encoded content.... So if you have purely text, you will get back purely text; it will not be wrapped in a Binary, it will not be base64 encoded... (unless of course you ask for it in FHIR form) see http://build.fhir.org/binary.html#rest
Eric Haas (Mar 20 2018 at 15:24):
This is a key question for clinical notes. And John has explained the technical details using DR but I don't think we have come up with single way to do this going round and round a few times. DR is really a reference to the thing and not the thing itself which is unsatifying.
Stefan Lang (Mar 20 2018 at 15:29):
What I took from New Orleans on the point of "notes" is mainly, that it is not even clear, what "note" means exactly.
It may be a formal clinical document containing many clinical details, or just an attachment to something like a Condition, Procedure or whatever. This makes it hard to have a single method of representing/storing/transmitting "a note".
Eric Haas (Mar 20 2018 at 15:35):
Yes we have discussed this many times in PC and circle around the question of "what is a simple free text note". Lloyd forgot to mention ClinicalImpression although I'm in favor of a slimmer 'Evaluation' resource instead of overloading Observation even more.
John Moehrke (Mar 20 2018 at 15:36):
The proposal is that there would always be a DocumentReference.... where the DocumentReference could point at the various encodings. This only solves the 'how would I find notes''. It does not solve the 'where do I put this note', except to say 'where ever you put it, you must also create a DocumentReference.... which is why it is very unsatisfying.
John Moehrke (Mar 20 2018 at 15:36):
I understood a FHIR Connectathon track was going to focus on further refinement... right?
Eric Haas (Mar 20 2018 at 15:40):
and Argonaut project as well
Patrick Werner (Mar 20 2018 at 15:56):
The thing itself could be a Binary, pointed to by Attachment/DR.
BUT it feels strange to Base64 encode plaintext. Of course it works, but it is wasted traffic & disk space. Therefore the idea of supporting plaintext directly in the Binary resource.
Grahame Grieve (Mar 20 2018 at 19:15):
Connectathon track write up: http://wiki.hl7.org/index.php?title=201805_Clinical_Notes_Track
Brian Postlethwaite (Mar 23 2018 at 00:02):
Or the narrative in a Basic resource of some sort. ;)
Dave Barnet (May 21 2018 at 14:55):
I also have the requirement to send plain text in a message (along with structured data). I've read the Connectathon write up (201805 Clinical Notes Track), which said it was going to test DocumentReference & DiagnosticReport. I can only see a write up of DocumentReference, the Argonaut Clinical Notes HomePage doesn't seem to link to anywhere useful (for me to view the Clinical Notes profiling) & Clinical Notes don't seem to have made it onto the US Core Implementation Guide site yet. From what I can see, to send some plain text, you create a DocumentReference, use DocumentReference.type to say what sort of plain text is being transmitted, you convert your plain text to base64 and put that in DocumentReference.content.attachment.data and set DocumentReference.content.attachment.contentType to "text/plain". Does that sound about right? - or has the thinking moved on? (perhaps to along the lines of Brian's thoughts of having a Basic resource with an Annotation & type code extension)
Lloyd McKenzie (May 21 2018 at 15:19):
@Brett Marquard
Brett Marquard (May 21 2018 at 15:32):
The write-up on clinical notes will improve significantly in June -- we have been trying a few different approaches out.
Brett Marquard (May 21 2018 at 15:33):
Your understanding of our current approach is correct (DocumentReference.content.attachment.data and set DocumentReference.content.attachment.contentType to "text/plain". )
Brett Marquard (May 21 2018 at 15:35):
DiagnosticReport is a bit tricky -- it's not clear all vendors will expose through DocumentReference. We agreed to focus our energy on these five types:
Discharge documentation (18842-5)
Consultation (11488-4)
History & Physical (34117-2)
Progress note (11506-3)
Procedures note (28570-0)
Brett Marquard (May 21 2018 at 15:36):
This summary presentation to patient care last week might be helpful.
Michael Donnelly (May 21 2018 at 20:10):
@Dave Barnet If an example would help, we've got a set of Postman requests you can check out: https://www.getpostman.com/collections/80389c641f9570e2745b
Michael Donnelly (May 21 2018 at 20:11):
The attachment content in there is base 64 encoded plaintext.
Michael Donnelly (May 21 2018 at 20:11):
You have to use the native Postman client (not the Chrome app) for these to work.
Dwight Walker (Jul 08 2018 at 14:45):
I am guessing that raw text would be loaded in Postman.
Last updated: Apr 12 2022 at 19:14 UTC
