# What'sApp for the NHS - how do we solve in an open way (Friday question) **Category:** [open forum](https://openhealthhub.org/c/open-forum/9) **Created:** 2017-07-07 08:21 UTC **Views:** 5912 **Replies:** 38 **URL:** https://openhealthhub.org/t/whatsapp-for-the-nhs-how-do-we-solve-in-an-open-way-friday-question/1080 --- ## Post #1 by @paultargett **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](https://www.theguardian.com/technology/2017/jul/05/doctors-using-snapchat-to-send-patient-scans-to-each-other-panel-finds) and BBC article on [WhatsApp](http://www.bbc.co.uk/news/technology-40507440) 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 --- ## Post #2 by @gary.kennington 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 --- ## Post #3 by @paultargett 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. --- ## Post #4 by @dunmail 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. --- ## Post #5 by @paultargett 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. --- ## Post #6 by @pacharanero The [Matrix](https://matrix.org/) 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_. --- ## Post #7 by @dunmail 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. --- ## Post #8 by @mayfield.g.kev 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? --- ## Post #9 by @mayfield.g.kev 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 --- ## Post #10 by @paultargett 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 --- ## Post #11 by @paultargett 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. --- ## Post #12 by @mayfield.g.kev 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) --- ## Post #13 by @paultargett 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. --- ## Post #14 by @mayfield.g.kev 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). --- ## Post #15 by @paultargett 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. --- ## Post #16 by @dunmail 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! ;) **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. 6. context Required key, but value not known. Could use default e.g. 394777002 Health encounter site--NOT LISTED --- ## Post #17 by @mayfield.g.kev 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). --- ## Post #18 by @mayfield.g.kev [quote="dunmail, post:16, topic:1080"] 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: [/quote] The full ValueSet is http://browser.ihtsdotools.org/?perspective=full&conceptId1=999000391000000109&edition=uk-edition&release=v20170401&server=https://prod-browser-exten.ihtsdotools.org/api/snomed&langRefset=900000000000508004 (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????? --- ## Post #19 by @paultargett 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. --- ## Post #20 by @mayfield.g.kev 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. --- ## Post #21 by @mayfield.g.kev Did you have all the profiles in CareConnect for IHE-MHD. Is DocumentReference the only one missing? --- ## Post #22 by @dunmail [NRLS Document Reference](https://data.developer.nhs.uk/fhir/nrls-v1-draft-a/Profile.RecordLocator/nrls-documentreference-1-0.html) has a *required* binding to the NHS valueset, so there is only one option! CareConnect Patient makes birthdate and gender mandatory, so doesn't work when all we know is the NHS number. --- ## Post #23 by @mayfield.g.kev Yes technically you are correct, but the ValueSet is incorrect it should be an expansion not a list of includes. The intent is to use the same SNOMED subset that HL7v3/ITK used. We had issues trying to get the correct expanded ValueSet, you get inconsistencies across a number of TRUD downloads. ihtsdo matches the UK SNOMED RF2 and I believe that is correct. I'll double check tomorrow though. [I'd be keen to get push DocumentReference as a CareConnect profile using NRLS as a start] --- ## Post #24 by @dunmail Kev: Sounds like there are a couple of real world implementations on which we could base a CareConnect DocumentReference profile. Do we need some sort of minimal patient/organization profiles to set a minimum standard for referenced resources (in England) e.g. a Patient with mandatory NHS number, Organization with ODS code? --- ## Post #25 by @iDrSunny Good afternoon all. I am just re-igniting this thread as there was a twitter thread going on this and Marcus was kind enough to invite me here. I have, so far, dedicated over 3 years of my life to this very topic. I have ended up creating a solution and been really mindful of every governance challenge so that it doesn’t ever land the NHS or any organisation in hot water. We have pivoted during these three years in how we do things having taken all these considerations into account. I know some people are out there trying to do this but they do not understand the seriousness of what is being built. Not really wanting to discuss that on an open forum. However, what we have also realised, after deploying it to over 210 people in an organisation - from ward clerks right the way through to consultants and in the community, is that the software is the least of your worries. The right team is needed for the rest of what comes after. Which can not be open sourced. Also open sourcing will work to a certain degree - you can make the open source chat engine fine. But really understanding how communications should work post the pager era is a major challenge and not one for an open source solution in my honest opinion. My team will be sharing some of these learnings at GIANT and possibly at KingsFund as well. --- ## Post #26 by @MatthewVita [quote="iDrSunny, post:25, topic:1080"] But really understanding how communications should work post the pager era is a major challenge and not one for an open source solution in my honest opinion. [/quote] Hello Dr. Bansal, Would you say the basis of this statement is with the challenges of the clinician to clinician communications or with patient to clinician communications? Thank you, Matthew Vita --- ## Post #27 by @iDrSunny Hi Matthew, I would say that my statement holds true for both if I am honest. Best wishes Sandeep --- ## Post #28 by @pacharanero Thanks @iDrSunny for sharing your insights, really helpful to understand the work you've already done in this area. I didn't understand why you feel that an open source solution wouldn't work though - could you explain your rationale for this statement a little more please? [quote="iDrSunny, post:25, topic:1080"] But really understanding how communications should work post the pager era is a major challenge and not one for an open source solution in my honest opinion. [/quote] I understand what you're saying - that the cultural and organisational aspects of this huge business change are the difficult parts, and writing the chat engine relatively trivial. But surely a free solution that any trust can implement would go some way towards getting everyone rapidly onto a system that is secure and user friendly. The business change management stuff is something that people such as yourself would provide as a paid service around this. Whatever we end up with for messaging in trusts, the 'winning' solution needs to get enough trusts on board that they win a significant mindshare among clinicians - and free & open source would seem to be the quickest route to ubiquity. (It's also the *only* route to genuine security) Marcus --- ## Post #29 by @paultargett Hi, I started this thread over the summer. What I thought was interesting about the response to the thread was it became a discussion about document oriented protocols - which may work. The IHE document exchange protocol for mobile devices seemed to be the spec referenced. However, I'm not sure if using IHE pulls you into a closed source solution at some point. I was interested in having a JSON RESTFUL standard that allows messaging applications to interoperate. There would also need to be registry of users to know where to route messages. Before we are finished we may re-invent email. There would need to be controls over how people joined and the governance - of course. Originally, I thought that there needed to be an open interface definition for this to work across systems. I can't see a one solution working in the NHS culture and having an open messaging interface would work. So let any number of closed and open source solutions bloom but all use the same protocol for messaging. PT --- ## Post #30 by @iDrSunny I completely understand your point about market security and this is why the NHS needs to really understand who they are working with on this and why. Once you see our pipeline and the patents we are working on and why, you will understand how open sourcing the chat will go some way like you said, but you will face many issues as you look to combine different organisations together. For example the governance around who can share data with whom. It becomes a minefield. Then, by the time that is built and adopted, actually the technology will have shifted many folds. For example, the way we interact and communicate, will it remain as a text based input? You have to truly trust the people that will underpin such a piece of work I completely agree. Best wishes Sandeep Dr Sandeep Bansal MBBS PgDip Founder and CEO Medic Creations sandeep@mediccreations.com | +44 (0) 7800633716 LinkedIn | Twitter --- ## Post #31 by @paultargett Sandeep, I think we agree with you on the complexity but a closed solution just follows the path of broken projects and companies in the NHS space. It's easy to get a pilot in one Trust, or area, but it's hard to get the next project and sustain the solution. You will also see the struggle that pure open source projects are getting the NHS. So a solution that allows closed and open solutions to interoperate is key to success in this environment. It allows those already in place to build in the functionality and new entrants in to the market. I am a supporter of both models in delivering solutions but an approach that is built around a closed environment will have limited flight time. Paul --- ## Post #32 by @iDrSunny I agree with you on that Paul. Like I said, it really matters who the NHS works with from an external perspective and how aligned each party is. --- ## Post #33 by @pacharanero The most interesting possibility I've come across that seems to provide just this interoperability that you describe @paultargett is [Matrix.org](http://) - it's a standard for decentralised, self-hostable, interoperable chat. I've had a chance to play with it and it's really rather good - each 'node' can choose to federate with other networks or not, and a decentralised user registry. It solves some of the issues we have. There are a range of connectors and apps already available to link it with existing solutions, it's got encryption built in, and it's free and open source. I'd love to get some funding together for a trial in the NHS, any interested organisations can contact me via this forum. Marcus --- ## Post #34 by @paultargett It's a shame there isn't support for this as part of the FHIR profiles as then it could be come an INTEROPEN project. Apperta may be an option for funding a project like this. I would be keen that the funding is made to setup a federated messaging service, i.e. there doesn't need to be a central body. It's something that could be performed with a blockchain approach with trusted repositories joining the network. I believe there is a London Accelerator that has had money to do messaging. I'm sure that's going to have an open API to it and probably a place to start? PT --- ## Post #35 by @MatthewVita Not to detract from the thread too much, but I would like to throw something out there. The https://rocket.chat/ team has been doing amazing work in the messaging space. It's open source, self hosted (probably can be HIPAA friendly), and has a great set of user clients. As it stands, the solution won't satisfy all of the requirements being discussed here (notibly patient-doctor communications, linkage with an EMR, and calls). However, it may be useful to reach out to that team to see if they'd like to work together on something. Over on the OpenEMR project, we've been using RocketChat for a good amount of community interactions without any issues. -m --- ## Post #36 by @pacharanero +1 for [Rocket.chat](https://rocket.chat) - it's the most mature and featureful of the open source Slack clones. For internal clinical use it would satisfy the requirements we have for most NHS uses. We don't really have any requirement for clinician-patient messaging in most situations, so Rocket.chat would be a good fit for many NHS organisations. --- ## Post #37 by @MatthewVita Cool! I'm already running a handful of open source projects in my project's space, but maybe someone here can reach out to the Rocket Chat team to coordinate development efforts. A great opportunity! Wish I had more time to help :) --- ## Post #38 by @Thaddealf Really interesting project, i suppose to think that it can actually work. Seems to require a lot of time to be developed and implemented! :wink: But's worth it! --- ## Post #39 by @paultargett [quote="MatthewVita, post:37, topic:1080"] Rocket Chat [/quote] @MatthewVita Rocket Chat looks very interesting. What would make this even more interesting is if it supports an open message interface. Looking at the docs it wouldn't be hard to integrate that. I think the key point is that providers / trusts could use this if they wish or develop in their platforms but could use an openAPI to communicate. PT --- **Canonical:** https://openhealthhub.org/t/whatsapp-for-the-nhs-how-do-we-solve-in-an-open-way-friday-question/1080 **Original content:** https://openhealthhub.org/t/whatsapp-for-the-nhs-how-do-we-solve-in-an-open-way-friday-question/1080