Did you have all the profiles in CareConnect for IHE-MHD. Is DocumentReference the only one missing?
NRLS Document Reference 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.
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]
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?
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.
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
Hi Matthew,
I would say that my statement holds true for both if I am honest.
Best wishes
Sandeep
1 Like
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?
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
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
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
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
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.
The most interesting possibility Iāve come across that seems to provide just this interoperability that you describe @paultargett is Matrix.org - 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
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
1 Like
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
+1 for 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.
1 Like
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 
Really interesting project, i suppose to think that it can actually work. Seems to require a lot of time to be developed and implemented! 
Butās worth it!
1 Like
@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
1 Like