As part of our Patient Flow feature series this month, we spoke to Michael Shenouda, Director at Open Medical, to get his thoughts on the importance of capturing granular data during patient flows, examples of their solution in practice, and the learnings and challenges Open Medical can take forward.
To begin, can you tell us a bit about yourself and your role?
I’m an orthopaedic surgeon and my role at Open Medical is both as medical and commercial director. In my Medical Director role, I oversee most of the medical aspects of our technology, making sure that every technology that we publish and put to market is safe from a clinical perspective, meets the needs of patients and of our medical strategy. I also oversee our sales and marketing team, as well as our digital solutions team who are constantly working with our clients to look at different opportunities, new technologies and solutions, problems that they have that we can solve with our technology.
What service does Open Medical offer?
There are multiple strands to our offering. What we sell to clients really is the technology. But our offering is more than just the software itself, the software is really what we use to deliver the digital transformation.
In order to get to that stage, it’s really a case of working with the client on a case-by-case basis and providing a lot of consultancy. We look at their current process, which could be legacy processes on paper or use of an electronic patient records (EPR) system that they’re looking to get more out of, or we find in a lot of places that they have an EPR of sorts, but they still have manual processes running alongside it. In that case they’re looking for solutions to enhance the EPR offering but also make the manual processes more streamlined and governed. We work with them, we spend a lot of time during our sales cycle and in the implementation phase, to scope out exactly what their pain points are. What are their problems, what are their needs? What is it that the existing infrastructure is not providing for them?
One thing that I think we do quite well, really, is to direct the client to their own existing systems rather than our own, where we feel that that is the better solution. So for example, someone might say to us, “Can you also provide us this service or this software?” but if we see that doing that will actually fragment the workflow for another department or another division, we will say, “Actually, as much as we’d love to do that for you, you’re solving one problem but creating another for another department.” So that consultancy is very much an in-depth, thorough, two-way conversation between us and the client, and the key respective stakeholders.
Once we’ve got that, that’s when we can piece it together into our software technology and deliver the transformation on our platform. The service doesn’t stop at the implementation or the delivery of the software, we support users, train them, bring them up to speed, and then we offer an ongoing service for the life of the relationship with the client where we will provide their support requirements and any updates. Pathways can change – for example, one of our clients had a COVID risk assessment and naturally over the last two years, those assessments changed multiple times. So we will change it with them, adapt it with them, and continue to provide them with that service.
I guess one of the big advantages of doing it that way is that we do often get to iterate the technology with them. We feel strongly about delivering the best across healthcare. If one of our clients develops a new pathway or a new offering that we think would benefit another client, we actively go to the other client and tell them of the changes, and if it would benefit them we give it to them as part of the service. Then you’re allowing everyone to benefit from each other’s ideas and progress, and really taking shared learning and iterative improvement of pathways in the NHS to a slightly more elevated level.
Can you give some more detail on Open Medical’s patient pathway, and any examples of it in practice?
If you take a typical patient pathway, there’s a lot going on. For example, a patient sees their GP, and their GP says they’re going to refer them to the orthopaedic surgeon – they’ll see the patient, maybe send them for an investigation, for physiotherapy, and eventually they might decide that the patient needs a knee replacement. The patient then needs to be listed for the procedure but there’s a whole host of other things that need to happen – a health screening, pre-operative assessment, signing consent forms, an outcomes questionnaire. The patient needs to come for their operation, sign forms, check-in, there are swab tests, eventually the surgeon needs to record the operation notes, then they’ll get discharged and need a follow-up in six months. That’s an end-to-end patient flow. We try to make that as seamless as possible and we have the technology to cover that whole end-to-end space.
What we also do is break it down into modules to be able to fit into the requirements of a particular organisation, because not everyone is going to want the whole process covered. We’re working on a project now with the Royal National Orthopaedic Hospital (RNOH) – they started off by looking at their three biggest pain points which were referral management, digital consent and patient-reported outcomes. We worked with them to digitise those modular bits, and now we’re looking at adding the rest of the technology around pre-operative assessment and theatre planning.
With the work we are doing at RNOH, a key aspect is that all the referrals are coming in centralised to a single portal no matter where they are coming from. That single portal is customised on a team basis; what your foot and ankle surgeon needs to know, for example, is very different to what your shoulder surgeon needs to know.
We’re doing some interesting work with the RNOH psychiatry unit whereby patients who demonstrated that they may be at risk of suffering from anxiety or depression are sent, automatically, a separate questionnaire to dig into that a little bit more. If they score highly on that, they’re flagged up to a psychiatrist to review. So patients are getting psychiatry input for their mental health before they’ve had orthopaedic input for their physical health, which means that by the time they come and see the orthopaedic surgeon, they’ve already had a degree of treatment to help support their outcomes.
“You have to consider patient flow from the patient’s perspective and also the clinician’s perspective.”
Another interesting project we’re doing at the moment is in the dermatology space. We’re working with three trusts that all form the South East London teledermatology region. They wanted somewhere to centralise all of their referrals and a set way of managing all of the community dermatology referrals. Referrals are pulled directly from the national eRS system so that no-one’s having to put any manual information in there.
With patient flow, you have to consider it not just from the patient’s perspective but also from the clinician’s perspective. From their perspective, you don’t want to change the workflow for those who don’t need it to be changed. It goes back to the point about not fragmenting – all the GPs across all the country refer to secondary care through ERS. If we made some GPs in one region refer on our platform to dermatology, you’re creating fragmentation.
So instead we integrate with the national system. In doing so, we trigger a screening questionnaire to be sent to the patient with the questions that the dermatologist wants to ask. The dermatologist is then presented with the GP referral, the patient questions and the images all in one, and they can make an assessment. Based on the diagnosis, a letter is automatically triggered with information, leaflets, etcetera.
Both of those projects really were initially very consultancy-heavy, leading to the development of the solution and the configuration of our solution to their individual needs. In both cases, we’re looking at how we can optimise the patient flow, present the clinician with the right information at the right time, and arguably the most important bit is how we can get meaningful data at every single point of that journey, without making anyone do something that they wouldn’t already be doing.
Can you share some of your learnings?
One of the biggest learnings across all our projects is the balance between user-centric design and user ideals versus data structure, making sure that data is seamlessly captured and is comparable across pathways and even projects. This is something that we face quite often – being quite agile in the way we can build our system, often we do get people who want things done in a certain way, asking for things to be labelled or structured in a certain way. It’s about finding the balance because it can be done, and it might make the patient flow slightly easier for them in that situation, but arguably what you’ll lose is some of the data granularity and some of the data structure, the consistency across different projects and pathways. Is that worth it, for something that reads slightly differently?
It’s something that I think is really important in digital health generally, finding that balance between user requirements and the importance of data purity and data integrity. We’re actually working on a project with NHS England at the moment about user-centric design for digitising pre-operative assessment and digital consent. A lot of the conversations we’re having are about this – finding that balance between what the user wants, but delivering it in a way that doesn’t take away from the importance of the data’s purity and architecture.
How important do you think that your solution is in the formation of integrated care systems (ICSs)?
I think getting the process right in the space between primary and secondary care is going to be key to the integrated care sector. The gaps are in the community spaces in between where a patient is not quite suitable for secondary care but perhaps beyond what can be done in the GP practice.
One thing that we’ve seen is that very few systems fit into that space, because you require integration on both sides and you require integration not just from a technical perspective but also the integration of the workflows, and integrate the patient flow seamlessly from one to the other. Often, what you get are multiple fragmented processes.
Something that we’re doing in Lincolnshire at the moment is a musculoskeletal community project, trying to integrate that whole patient pathway from the moment that you see a GP up until the point that you are entering the hospital system. We’re having conversations about what the community pathway looks like – who are you seeing at what point? What information is being communicated to the patient at what point and how? Are they receiving that information in a way that they can manage tangibly and digest, or given a 70-page book that they’ll never read? Is that really delivering patient care that is suited to patient needs? What we want to try and do is to keep that community primary care hub model accessible – how can we keep it close to patients for them to seek help, provide that help in a medium that’s suitable, make sure that by the time the patient has progressed to seeing a surgeon, for example, all of that information is packaged in a way that the surgeon can view at a glance and know exactly what the starting point is for that patient.
“If you capture data in coded fashion, you can do more with it.”
Rounding up the interview, Michael shares some key thoughts for readers to take away.
In the trauma setting, a junior doctor will write notes – your injury, your mechanism of injury, your date of injury. They capture all that anyway, but they write it all in their own language. If you capture it in a coded fashion, you can do more with it – you can take it and look at all the injuries grouped by a certain characteristic and work out what the patient outcomes versus those grouped by another characteristic. You lose a lot of value if you don’t capture the data coded at the point of entry.
