You may have thought that changing GP practices would be a relativity straight forward process, this article takes a look at my own personal experience – and how that wasn’t quite true. This led me to reflect on why the process is so slow, inefficient and difficult to complete.
To begin with I looked online for my local GP practice, a step in the right direction I thought. However when I tried to drill into the selected GP practice there wasn’t much information available in terms of online registration, instead I could only find the manual process documented.
This meant that instead of being able to quickly and easily complete an online form, or email my local GP practice, I instead had to formally visit and request that myself and my family be moved to this new practice. You can imagine my surprise when I was presented with:
- A bundle of paper forms to be filled out
- A pair of forms per member of family (5-10 pages per person)
- 3-4 days estimated lead time
- No possible way of checking status apart from ringing up the practice
This experience left me wondering why we couldn’t get a better patient experience, and this is just one example I have experienced where an improved patient experience would be beneficial – for both patients and healthcare professionals across the NHS.
Having been involved with designing, architecting and delivering technology solutions for over a decade I couldn’t help but feel how technology can help in alleviating some of the frustrations and challenges discussed above. What really made me want to write article was a workshop myself and my colleague Bobby ran for a large healthcare software provider looking to provide GPs the ability to move away from paper based records for registering patients to online patient record system. This is a government led initiative which is being rolled out across the country.
As you can imagine the scale needed for this is fairly huge and with wider funding challenges it needs to be cost efficient, not to forget various requirements and challenges facing the NHS in transforming an old legacy IT estate to meet today’s user expectations.
It is while in the workshop it resonated with my experience and how technology could fundamentally make a massive difference to patient journeys across the NHS. Through improvements to technology we could transform how we consume and interact with our day to day interaction with our health services, providing services to go with our ever connected life styles.
Moving up the cloud services stack to PaaS – Introducing OpenShift
Increasing level of expectation from citizens, patients and consumers of technology has forced governments as well as private sector to transform and Cloud has been the fundamental force behind this transformation. Cloud has completely changed the way software is developed in the cloud native world, it has changed business and organisations culturally it ought to if not already done.
Cloud takes care of the NFR (Non-functional requirements) enabling your developer community to focus on the developing and innovating the core functionality of a application. This is where a Platform as a Service (PaaS) form of cloud deployment is required.
As you go up the value chain in the cloud deployment stacks (i.e. IaaS, PaaS and SaaS) you raise the abstraction layer from the underlying infrastructure. There is a increased move towards (scale-out) containerisation and rightly so in my opinion as with traditional methods of delivering (scale up) and developing software are not suited to scale, and pace of delivery that is required for the requirements and challenges we are trying to address today.
The PaaS tier takes care of the underlining provisioning, scaling, resiliency, Load Balancing, capacity providing your developer community with the ability to simply execute, maintain, innovate, release, test, configuration, change your application suite.
Red Hat OpenShift workshop – Cloud Native Software development
The app is in essence, a simple PHP application. However, there are some elements to it which meant that we hit some struggles on the way.
The biggest challenge was that to truly show the power of OpenShift, we’re harnessing the power of the “Source to Image” builder (S2I). What this does, is allow the developer to give OpenShift a GitHub URL, and have their app magically deployed.
Whilst on onsite with the client, the first issue was that OpenShift was automatically generating a Jenkins Pipeline build, but it was failing. The S2I builder had found a Jenkinsfile in the GitHub repository, and was trying to run the pipeline. That is very clever, but not required at this stage, so we had to manually override the build type in the command. The three build types are source, docker or pipeline. If the build-type is not specified, and OpenShift finds a Jenkinsfile or a Dockerfile, it will assumed a build-type of pipeline or Docker, respectively. Otherwise, source will be used.
Once past this issue we made great progress and setup redis and mysql containers as well as the main web container.
The next issue arose when we needed to configure PHP to use redis as the session storage handler, rather than it’s default location. Unfortunately, the S2I builder doesn’t support overriding the session handler, and we are trying to create the most elegant solution possible.
The solution was to contribute to the open source repository, where the PHP S2I image sits. The client informed us of all the other variables the may need too, so that we cold configure the builder in one fell swoop. The pull request is here.
Whilst waiting for this, we completed the setup of the application, keeping the sessions out of Redis for the time being, and were able to login and use various components of the system.
Essentially we were able to deploy the application with 2-3 OpenShift commands, and pending the pull request being accepted by RedHat/SCL, we will also be able to use the Redis service fully.
Update: The Pull Request has been accepted and merged into the main branch, so we are now in a position to go back to the client and finish off this workshop, very exciting!
Linking it back to patient outcomes
In my example at the start of the article, I talk about the patient experience and the struggles to fulfill fairly standard outcomes – one of them being moving from one GP practice to another.
I wanted to link the above with how technology can be utilised to deliver better outcomes for patients in particular the workshop we conducted. IT provides a clear example how technology can make a difference in particular with the development of software, and thus having a direct impact how we the patients consume healthcare services.