Representation of e-mail and social media exchanges

Introduction

In recent discussions, the idea has arisen that e-mail, but also Facebook or Twitter posts/chats are becoming increasingly interesting as a source of secondary clinical information. This could include patient-provider communication (usually in addition to face-to-face or telephone encounters), but also contact person-provider communication (e.g. when it comes to family members asking questions on behalf of juvenile or elderly patients), provider-provider communication (professional consultations) and even patient-patient communication (groups for sharing patient experiences).

We believe there should be a standardized way to model this type of exchange, most likely as an Act with classCode INFRM, with the source and destination of the exchange marked as participants. The next question then becomes how you identify these participants. An obvious way would be to simply identify them via their e-mail, Twitter or Facebook accounts (whichever applies). This would make an application interface (plug-in) between the messaging/social media application and the clinical application quite simple (although privacy and security would certainly be a major concern). Of course these can be treated as telecom addresses, but the question then arises whether social media (Twitter, Facebook, etc). are covered by RFC 1738? Alternatively, we could treat this as true IDs, in which case there needs to be an OID (preferably universally used) for e-mail accounts (separate OID for each provider?) and for the major social media… Has this ever been discussed in HL7?

By the way, I think there is a very real marketing opportunity here too. There is reality where social media are increasingly used (whether appropriate or not) for the abovementioned type of communication. Some of that information exchange is certainly relevant for inclusion in a patient’s EHR (and/or PHR). I think Facebook and Twitter might be seriously interested in investigating their role in the healthcare arena. Before you know it, we could have them join our ranks as active participants (and benefactors ;-) in HL7 development. HL7 cannot direct which media are used for healthcare exchange, but it should certainly support any media that are used in practice. In this case, we see media that were not intended for healthcare use per se, becoming more and more important as an exchange mechanism. The boundary between healthcare and social media is becoming flexible and we should be prepared for that.

Security issues

Peter Hendler:

There is a huge problem with this and patient privacy. There is no way we (USA) would ever be able to discuss any clinical information with patients on non secure social media. Not even for them to tell us about head ache or for us to tell them to take an aspirin. No Personal Health Information (PHI) ever over any non secured channel.

Maybe in other countries it would be allowed but we are not allowed to use any non secured system for any PHI what so ever, and the fines are $250,000 for every single breach.

Tom de Jong:

Well, first of all, I’m not suggesting that Twitter or Facebook make for a safe communications channel to exchange clinical information. But fact is that in many countries there are experiments (sometimes controlled by authorities, but usually spontaneous) to give electronic communications a place in the dialogue between patients and providers. The most common example are doctors that allow patients to ask them questions via e-mail (in Holland this is perfectly allowed, even when the e-mail is not sent over a secure channel). But we also have a use case where a nursing home allows family members to communicate with staff via social media. That’s information that could very well be relevant for the patient’s record.

It’s hard to predict what these experiments will lead to, but the fact that a channel is deemed unsafe has rarely stopped developments in the past. That’s what people said of the phone 100 years ago. If it’s convenient, I’m sure it will be used. The challenge is then to make the channel safer.

Klaus Veil:

I agree with Tom - I think there is no suggestion to use Social Media for official exchanges of Personal Health Information (PHI). Other countries also have patient privacy legislation and penalties ...

However, there is a growing use of Social Media for access and authorisation (eg OAuth for accessing the Blue Button: http://motorcycleguy.blogspot.com.au/2012/09/abbi-security.html, OpenID, etc.) which we cannot ignore.

Also, end users are increasingly using their Social Media worlds to communicate what they wish to share, often on a one-to-one basis. I see many people now use Twitter Direct Messaging and Facebook Messages (which even support attachments) instead of e-mail and SMS/Texts. So if we are OK with people communicating one-to-one via e-mail/SMS/Texts, we need to be prepared for the same one-to-one communication via Twitter's and Facebook's e-mail equivalents.

So Tom has given a good heads-up for HL7 to look at new communications channels that are already being quite widely used and I agree that we need to seriously look at this.

Peter Hendler:

Your probably right, and it will be developed in other countries (then the USA) but we could be prosecuted for making PHI breachable. We can't email our patients at all. We have secure portal using HTTPS. Our patients leave us questions, and we leave them answers. The regular email is involved to the extent that the patient will receive and email limited to the information, "you have a message". Then they log into the secure portal. Unsecured Email, Twitter or anything is strictly prohibited from containing any medical information.

I suppose we could use Twitter to send the message "you have a message" and then they'd have to log in securely to the https portal.

How to model e-mail and social media exchanges

kljkjlkjlk

How to identify the authors in the exchange

http://twitter.com/@GrahameGrieve

The registry is at http://www.iana.org/assignments/uri-schemes.html. This is not authoritative.

Initial but Rejected Solution

Analysis

The presence the need for "paired" attributes - two flavors of author participation, paired mood codes like EVN.CRT, two flavors of statusCode - are prima facia evidence that there are two different states present that are been collapsed into one. I submit that the distinction is between Acts that are "normal" and will represent real world artifacts (INT, EVN, GOL) and acts that are an "abstract definition" of that reality like "DEF", "CRT", "EVN.CRT". From eMeasures, it has become clear that criteria must exist in all moods and involve all reasonable participations. There seem to be similar requirements for DEF Acts. That being the case, this is not manageable so long as DEF and CRT are mood codes and so long as Act attributes and associations must be relegated to either document characteristic or not.

Recommendations

Two recommendation items were added before 2009-09-21. These have been moved to a Previous Recommendations subsection. What follows was developed subsequent to that date.

New Act Attribute - abstractionCode

Add a new attribute to Act with a sort order that places it immediately after moodCode. The name is "abstractionCoe" with definition like "Determines whether the the Act is a normal act that will instantiated in real record elments or is an abstraction that defines or creates criteria about such normal acts."

This attribute should be Mandatory.

There should be three codes: "NORMAL", "DEF" and "CRT". with a default value of "NORMAL".

Changes in ActMood

Remove DEF, CRT and EVN.CRT from ActMood. The remaining codes in ActMoodPredicate should be considered as candidate abstractions. Initial analysis suggests that both GOL and RSK are in fact "normal" moods as they have assigned subjects, times that are expected, etc. (Phrased another way, one can envisage a DEF for a Goal.)

Changes in "Rules"

• For all Acts whose abstractionCode is "NORMAL", the rules according to DocumentCharacteristic, and existing RIM definitions apply.
• For all Acts whose abstractionCode is not "NORMAL", every attribute, and association of that Act is interpreted as being part of the criterion or definition.
• In order to document the life cycle and responsibilities surrounding a set of elements not in "NORMAL" mood, these classes must stem from a "NORMAL" class (such as RQO) that packages these elements.

Previous Recommendations

[1] Document characteristic attributes: Current thinking is to assume that in EVN.CRT mood, no properties are documentation characteristic. Gunther suggests that we may need to split Act.statusCode into an Act.actStatusCode and an Act.recordStatusCode.

[2] Vocabulary binding: Current thinking is to include a local code, which in the local code system reflects a value set.