Stream: implementers
Topic: the concept of a clinical email
Jens Villadsen (Aug 04 2020 at 07:57):
Hi all - I have a question in regards to modelling the concept of a "clinical email" in a message based infrastructure. It's essentially a message that can contain text about the given patient and the content is typically an epicrisis but is not restricted to that, so it's essentially free text. The message can be sent from both doctors, nurses and domestic helpers. Since it is essentially free text, I've been looking to use either the Communication resource or just the Basic resource. The reason that Basic could seem sufficient is that the addressing information is contained in the MessageHeader, which means that the recipient and sender information found in the Communication looks like it will be duplicated. Any guidance on this choice would be much appreciated.
Grahame Grieve (Aug 04 2020 at 07:58):
I would still use Communication. It might be duplicated but I wouldn't be surprised if some the values ended up being different as the process of messaging about the communications starts getting into multiple layers
Jens Villadsen (Aug 04 2020 at 08:05):
follow up question: I would like the free text expressed as markdown. Is it possible to constrain the payload.contentString to markdown, or does that require an extension?
Jose Costa Teixeira (Aug 04 2020 at 10:26):
I think you cannot constrain it directly. You can create a custom data type
Jose Costa Teixeira (Aug 04 2020 at 10:35):
I had a (similar?) challenge when I needed to make Communication a string with 320 characters max
Grahame Grieve (Aug 04 2020 at 10:36):
markdown is tricky. After all, mark down is just a fancy string. So you can put markdown in there, and say that it's markdown in your implementation...
Grahame Grieve (Aug 04 2020 at 10:37):
but which element are you asking about?
Jens Villadsen (Aug 04 2020 at 12:25):
Communication.payload.contentString
Grahame Grieve (Aug 04 2020 at 12:27):
well, you could although you could also use ContentAttachment with type = text/markdown
Jens Villadsen (Aug 04 2020 at 12:28):
hmmm .... good point
Jens Villadsen (Aug 04 2020 at 12:28):
Jose Costa Teixeira said:
I had a (similar?) challenge when I needed to make Communication a string with 320 characters max
I've made such restriction by using FhirPath image.png
Jens Villadsen (Aug 04 2020 at 12:31):
Grahame Grieve said:
well, you could although you could also use ContentAttachment with type = text/markdown
That seems like a pretty sane way to do it. It won't be directly readable however, as it would then be base64, but I guess I'll just have to live with that
Lloyd McKenzie (Aug 04 2020 at 15:44):
There's also an extension that allows you to provide a markdown expression along with (or instead of) a string: http://build.fhir.org/extension-rendering-markdown.html. (Instead of is less interoperable)
Jens Villadsen (Aug 10 2020 at 11:37):
Lloyd McKenzie said:
There's also an extension that allows you to provide a markdown expression along with (or instead of) a string: http://build.fhir.org/extension-rendering-markdown.html. (Instead of is less interoperable)
do you have any examples of where it has been used?
Jens Villadsen (Aug 10 2020 at 11:45):
Grahame Grieve said:
I would still use Communication. It might be duplicated but I wouldn't be surprised if some the values ended up being different as the process of messaging about the communications starts getting into multiple layers
back to Communication: The description of Communication states:
"It does not represent the actual flow of communication"
Me and the team at @MedCom FHIR Team are a bit puzzled about that sentence. I am in the need of building a profile on a message bundle with patient, messageheader, (communication) and so on - and the content of the text part of the message could eg. be that the the nursing home would like to ask the elderly's practitioner about parts of the medication in the patients journal or contents about the latest discharge report, so the text of the message that would go into the Communication resource would be "Hi [doctor dolittle] - we've asked [the patient] and she wasn't all keen on taking the new substance due to ... " or "The discharge report says that [the patient] should not lie down more than 8 hours a day. How should we proceed ...". Does such content belong in a Communication?
Jens Villadsen (Aug 10 2020 at 11:46):
ain't that the "actual flow of communication"?
Grahame Grieve (Aug 10 2020 at 12:37):
That sounds like a @Lloyd McKenzie-ism, and I think it means, the actual transmission level e.g. using a twilio API for sending an SMS
Grahame Grieve (Aug 10 2020 at 12:37):
that technical stuff isn't part of the Communication resource, which speaks about the human level of what happened
Jens Villadsen (Aug 10 2020 at 13:09):
@Grahame Grieve I really have no idea of what you just said. Can you agree to that the example texts that I wrote would be within the intended definition/scope of what could be the content of eg. Communication.payload.contentString?
Grahame Grieve (Aug 10 2020 at 19:24):
yes definitely
Jens Villadsen (Aug 10 2020 at 20:56):
May I then suggest a rephrasing of some of the text on the Communication resource as the text confused at the very least 5 non-native english speakers entirely. At least 2 people had the idea that the resource was about the act of sending the information itself.
Grahame Grieve (Aug 10 2020 at 20:57):
Sounds like a good idea to me. Make a task?
Jens Villadsen (Aug 10 2020 at 20:57):
sure
Jens Villadsen (Aug 10 2020 at 21:30):
@Grahame Grieve https://jira.hl7.org/browse/FHIR-28235
Ole Vilstrup (Aug 18 2020 at 05:22):
Following up on the above discussion, the team @MedCom FHIR Team has elaborated a bit over the discussion and our approach and we would like to add the following:
The Danish messaging standard ClinicalEmail serves several purpose, where being a traditional email is just one of these.
1. ClinicalEmails are standalone messages serving the need of communicating between clinicians email-style
2. ClinicalEmails are somehow the glue that can qualify almost every message flow
a. Questions and answers regarding the understanding of a former message
b. Further information in relation to a former message
3. ClinicalEmails are also clinical observations carrying both the narrative around a condition of a patient and an observation on the exact condition thus also carrying the observation in itself, for instance like a discharge letter, and therefore in these matters also part of the medical journal itself.
ClinicalEmail messages are heavily used in the Danish healthcare sectors and has a long history 15-20 years back in time, and should it be invented just now with FHIR, it would probably have been differentiated out as a lot of difference profiles instead of just one, just because FHIR will approach these different needs in many different ways, almost one for each use case mentioned above and all the others, which I haven’t mentioned. We see it much more as a clinical document rather than an email/text message, which serves a complexity of functionality and therefore also should have the flexibility to serve those.
Therefore our approach for ClinicalEmail has been to work with the Composition resource, although very narrow with only the observation text and a file attachment for a starting point, but planning to allow for more complexity over time as Danish Healthcare grows and matures with FHIR.
Discharge Letters in FHIR are using the Composition resource, we believe this is the closest FHIR example we can think of in regard to the use of the ClinicalEmail.
It is our believe, that when receiving messages like Discharge Letters and ClinicalEmails, these message types are handled very similar in most IT-systems, and therefore will ease the task of receiving and handling them being as similar as possible.
Jens Villadsen (Aug 18 2020 at 10:30):
I don't see how the use of Composition is a better fit. Since the profile on the message bundle is profiled itself, there is plenty room for specifying relevant observations and attachments. Setting that content inside the Composition creates and unnessecary convolution, IMHO.
Grahame Grieve (Aug 18 2020 at 11:23):
Sounds like a Communication with a reference(Composition) as it's content to me
Vassil Peytchev (Aug 18 2020 at 13:37):
This sounds like mixing several concepts that might result in a sub-optimal solution. Different types of purpose (communicating between clinicians email-style vs. discharge letter for example) usually means that you need different type of content.
A discharge letter is a typical example of a clinical document, and as such it's purpose and existence is useful beyond the act of communicating between clinicians. Communication between clinicians is not always a clinical document.
Orthogonal to that is how the content is made available to the proper consumers at the right time (which is not always just moving bits from point A to point B). One of the major strengths of FHIR is the RESTful API, and I hope that it is not being ignored.
Ole Vilstrup (Aug 21 2020 at 08:54):
@Vassil Peytchev I agree with your comments on mixing several concepts. Our challenge here is legacy from our old message regime based on UN EDIFACT and a widespread use of these mixed conecpts. Our first approaches into FHIR in MedCom are 2 "old" standards needing an update, and instead of continuing in the old message regime, we want to move to FHIR. This will draw the old use into the FHIR world, but as I see it, over time we will transition all our old message regime standards to FHIR, where new approaches to the paradigmes these messages cover. In these steps we will be able to implement the FHIR way of handling these concepts and thereby little by little narrow down the use of the ClinicalEmail. The whole discussion around this has at least for me clarified, that we need to redefine the name of this message, as it brings in too much confusion around its use, especially in the english based FHIR world.
Transitioning into FHIR is also transitioning the mindsets around the old way of approaching different concepts, and our approach is somehow also to have respect for our legacy and giving time for maturing into these new mindsets, which also include ourselves in MedCom, the Danish standardization organisation for healthcare messaging.
Vassil Peytchev (Aug 21 2020 at 14:20):
Based on this, we still have the following different pieces:
- an existing messaging system
- different content is being exchanged using the existing messaging system
I think the point that is being made is that while the transition to FHIR needs to be gradual and allow for adoption based on existing exchange patterns, the different content needs be represented based on the appropriate purpose of FHIR resources, and not based on the exchange mechanism.
Examples of different content:
- A discharge letter is a document - a DocumentReference pointing to (or containing) a CDA document or PDF, or a FHIR Bundle of type document with Composition and related resources in the Bundle.
- A message from one provider to another with, or without attachments, is most likely Communication, the awkward definition of the resource not-withstanding.
The content can get from point A to point B in different ways, for example:
- Using the existing messaging infrastructure
- Using FHIR Messaging
- Using SubscriptionNotification to alert point B to retrieve the content from point A
And among all that, if the intent is to transition to more ubiquitous use of FHIR, it is good to keep in mind how these resources will work once everyone supports FHIR servers, e.g. how will the discharge letter for patient X will be made available by hospital A to properly authorized clients using the FHIR RESTful API?
Ole Vilstrup (Aug 21 2020 at 15:00):
@Vassil Peytchev I appreciate your input and we will take it into considerations going forward
Lloyd McKenzie (Aug 23 2020 at 22:38):
In general, we don't encourage the use of Communication to 'wrap' the sharing of information - you just send the relevant information. So if you want to send a prescription, you post a MedicationRequest, you don't post a Communication that points to or contains a MedicationRequest. That's what the original sentence was trying to convey. However, if you're replicating the notion of email, then Communication is a reasonable resource to use.
Last updated: Apr 12 2022 at 19:14 UTC
