What'sApp for the NHS - how do we solve in an open way (Friday question)

open forum
1

Public messaging apps with patient data is a problem

3 years ago we built secure messaging into our platform for sending pictures and messages, people were interested but we seemed to struggle to make a case for adoption.

I’m aware of a number of other apps that have tried, and the NHS has recently supported https://www.medcrowd.com/ via the London Accelerator. The recent reports and news about use of SnapChat and BBC article on WhatsApp are building a case for a solution.

As we speak there will be NHS England / Digital people, local trusts, software companies all about to embark on procurement and software build to solve this. I haven’t began to think about the other nations or even this that other places in the world may have solved this…?

How do we solve this given the eco-system of the NHS?

My question is this: are these proprietary solutions bound to fail in the NHS as the NHS struggles to purchase one thing that gets adoption. Should there be an open approach that provides a secure way of exchanging instant messages between users that allows each vendor or NHS development team to do their own thing, or purchase a solution that is using the standard?

I’m imaging a solution not dislike the Banks payments systems where the open service provides a distributed backbone for secure messaging . The application providers are the hosts and need to store and manage the messages. That would mean that the messaging can be distributed and not require a single service to host the backbone. There would need to be a service discovery solution for users but again that can be distributed and there are standards.

In our implementation we encrypt a key to the AES payload of every message with the public key of the receiving user. The patient is tagged, and we provide access to video and images all encrypted with AES and using public private keys. There are many different approaches to this and standards. But the key is the messages going between services have encrypted payloads and its down the to host applications to manage local security. This would allow differentiation and competition.

Authenticating users

Authenticating who the user is will be key, but again there’s a simple process of restricting the users to NHS.net emails initially and having a signup process that involves the users verifying who they are via email. I can also see a care.data type media blow out on this too. So a common open solution would need to satisfy this too, but not get caught up in the OpenID / verify kind of debates.

Consent / GDPR is a big consideration

There are some serious GDPR considerations here too. A doctor who signs up to WhatsApp is doing so in their personal capacity, then using the service as part of their NHS contracted / employed role. So that’s not good from a GDPR view point. How will a patient be able to ask who has had access to there information. Clearly sending images, video or text about a person is identifiable. So what ever solution would also need to manage subject access requests, and also I guess have to have no memory of messages its self but rely on the host systems storing this information.

So can we do some thing as a community are the considerations above so big that it stops it working and by the time we’ve done all this isn’t it just like email in the end?

Happy Friday.

PT

2

Looks like DOCMAN 10 is now offering a solution to this knotty problem. We also developed an In house App, but take up was not adopted with our local Acute Trust. Image capture was secure, no data was left on the device, and images could then be workflowed through Sharepoint on premise instance.

See

http://www.docman.com/docman-10-works/ for the Docman offering

IT Operations Manager
NHS South Devon and Torbay CCG
Pomona House
Torquay
TQ2 7FF
Tel: 01803 652583
Mob: 07500127083

3

Gary, yes this looks like a good solution too. I think there’s the issue right there. If we could get DocMan and others to adopt an interchange standard then we would be away! I would think that there is a FHIR profile we could use for this too.

4

We’ve wrapped DocMan’s proprietary API to align with the IHE MHD profile (which builds on the FHIR REST API). This allows us to retrieve/view files in a DocMan repo.

Given access to the underlying APIs (as ever ;)) it would be easy to extend the capability to post Documents as well.

1 Like
5

That’s interesting. So for DocMan this could be an adaptor into an wider solution and then be one of many solutions to be part of a wider service.

6

The Matrix project looks like it could be a solution to secure, decentralized communication that doesn’t tether those comms to a single platform. It doesn’t (yet) perhaps solve all of the issues such as GDPR responsibilities to be able to identify all comms about a particular patient and remove on request, or (for admin/organisational staff) FOI requests.

This is the kind of thing that the NHS really needs to put some thought into, and perhaps build as extensions to an existing standard.

One thing’s for sure, if the NHS-provided solution isn’t good enough, doctors will continue to vote with their feet and do what they need to do in order to provide good care for their patients. The fact they are willing to defy NHS ‘command and control’ by using apps not authorised for those uses is actually a good thing - it demonstrates how far doctors will go to provide care for patients and how the care of the patient is their First Concern.

7

Absolutely - most areas I talk to are creating a community of federated information repositories of which DocMan could be one. Standard interfaces (FHIR/IHE etc) allow new repositories to be quickly added. Exchanges coordinate the sharing of information, allowing definition of data sharing agreements, x-org audit/security etc.

8

Building on @dunmail comments. A number of trusts are basing document exchanges (FHIR messaging) based/influenced on IHE MHD.

The National Record Locator Service has also been influenced by this https://data.developer.nhs.uk/fhir/nrls-v1-draft-a/Chapter.1.About/index.html

@dunmail are you using the DocuementReference profile from NRLS?

9

The pattern behind NRLS expects this kind of behaviour https://developer.nhs.uk/library/architecture/integration-patterns/registry-repository/ which majority of trusts follow with Document Repositories (e.g. DocMan) with word/pdf/tiff documents

10

Yes, I think the NRLS will be a good service when its in operation. Is it about locating patients only, that’s my reading. Where here I think we are talking about a service that’s exchanging messages between users who are caring for people. We also have to cope with people that have the same email address across multiple services. So you would want a solution to work for the user where it doesn’t matter if they are on solution X or Y. IHE MHD looks interesting

11

Marcus, hi, the key would be to make subject access requests the role of the host service using the messaging service. The messaging service wont retain any information just provide a method of locating and passing a message.

Not sure I can get 100% behind your last point. I’m all for independence of thought and action. I see this as a clear requirement statement that’s about wanting to do this in an easy way that isn’t a burden on their ability to deliver care. I’m also thinking this is for any health and social care professional. I want to wider the stakeholder group to include the community nurse who’s visiting a patient with an ulcer and wants a specialist view quickly with a photo.

12

NRLS is currently about locating patients (care) documents.

Messaging can be a loaded term, do you mean sending text messages to people involved in a patients care (working on a CarePlan). Or sending messages around about the CarePlan (i.e. performed this intervention [changed dressing] on patient 123 which is working on the ulcer care goal of the CarePlan)

13

Yes we are talking about how do we provide a WhatsApp link service that allows vendors or dev teams in the NHS to have their own host services but be able to communication in a common way. I started the thread as we have developed a messaging solution within out RIVIAM service but I know that we wont rule the world and I don’t expect any solution too. If there’s an open way that allows services to communicate securely then why not do that? It will be about patients between clinicians.

14

You’ll find a related conversation here https://interopen.ryver.com/index.html#forums/1125161 (and yes it may not look like it).

I’ve worked in three ways working with documents (photos or images).

  1. Sending the document from A to B (it’s roughly the IHE XDS provide and register functionality)
  2. Sending a notification from A to B which contains a URL where the document is (this is very similar to NRLS register a document). So B knows a document exists and if they want to read it, they can.
  3. Provide an API so people can search for a document (this is very similar to NRLS search for a Patients documents/records).
15

I think the IHE standard looks interesting but as I understand it a provider would need to use the Document Exchange service?

Your option B is what we’ve implemented. My preference is to AES256 encrypt the document and store it in a document store, and that could be anywhere (in theory). The AES256 keys are then encrypted with the public key of the receiving party. That way we keep the payloads down to a minimum and avoid having multiple copies of a document(s) floating about. I’m not sure in this use case the open API service would need to support search. It’s effectively supporting a many -to- many messaging service that has a default encrypted text payload and then an array of linked documents (encrypted) with keys in the payload.

16

Kev: Not using NRLS DocumentReference - we’ve got a profile based on the MHD specs. It’s pretty close to both, but there are a few issues that would need addressing:

1. type
Required binding to: http://fhir.nhs.net/ValueSet/correspondencedocumenttype-1-0
However, this only allows: End of Life Care Coordination Summary, which I guess means we have a National End of Life Care Coordination Summary Locator! :wink:

2. author
Use Ref(Organization) as underlying data don’t allow Ref(Practitioner)

3. securityLabel
Required key, but value not known. Could default to N/normal

4. content.attachment
We provide more than one attachment. metadata is provided inline (attachment.data) underlying document by ref (attachment.url)

5. content.attachment.size
Not provided as we’re doing some inline transforms for legacy formats. Probably just work.

  1. context
    Required key, but value not known. Could use default e.g. 394777002 Health encounter site–NOT LISTED
17

All 3 are viable. Imagine your involved in an accident and ambulance crew creates some documentation.

  1. ED department gets sent the documentation
  2. GP may get a notification and can view documentation if they need to.
  3. Allows other careProviders access to the accident documentation (they would access if they think the information is relevant)

Encryption is down the line, we’ve mostly gone down the paperless 2020 in our own ways storing documents in TIFF, PDF, word, etc formats and using our own metadata. It doesn’t really matter how these docs move around (xml, json, IHE XML, FHIR, openEhr, etc), transferring between formats is relatively trivial. Main issue is the metadata and some formats are difficult to work with (e.g. TIFF).

18

The full ValueSet is SNOMED International Browser (if that link works)… Search SNOMED for 900000000000508004 and you should find all the document types. It did take a while to work that one out…

Terminology Server anyone???

19

Agreed, but where we are dealing with an image then we prefer not to embed in the message but move out to a store encrypted. I’m keen that this is discussed as I think some of the discussion around FHIR and messaging assumes higher level encryption on HTTPS level where actually where we are dealing with images of people I think the asset needs to be protected. So we base64 encode, AES256 and then transport the keys wrapped with RSA.

20

We had similar issues:

  1. type - full set of codes was fine for us but needed mapping
  2. author - we were only dealing with our own docs so not a problem but can see org would be useful.
  3. securityLabel - yes was an issue
  4. content.attachment - one was ok for us (we may have issues with TIFF’s though but wanted to push them being combined into a single pdf)
  5. size - we didn’t use the field and no requirement for it.

We also needed to subdivide by health service - we knew which service provided the doc but facility code in much detail… so either class or facility-code.