Building and Running a Healthcare Platform in the Cloud
I recently presented at the Healthcare track of the London Innovation Series, an event organised by Amazon Web Services in cooperation with Future Cities Catapult. It was a great event which focussed on bringing people together in London to work on the future of UK cities and U.K. Citizen services. There were a range of talks covering big data in the cloud (as is mandatory at events like this), compliance in the cloud, IOT and of course lots of sessions on server-less (justified given the transformation this will lead to).
I spoke about our journey over the past couple of years in helping move Evolve to the cloud, the process we adopted and the challenges we faced. It was interesting while preparing for this talk to reflect back over the past couple of years and trying to pick out some of the highlights and challenges, so I wanted to write some of these down for anyone who was not able to be there on the day
Why did we move to the cloud?
It’s obvious, but on-premise software requires on-premise hardware and this hardware needs to be provisioned, managed and maintained, in most cases by our customers. The management and maintenance can be a difficult responsibility for our customers to take on and the provisioning process often introduces delays when we are trying to get our software rolled out. We would rather be talking to clinicians about how they use our software as opposed to talking to IT departments about setting up SQL Server clusters. This problem can often be exaggerated by resourcing constraints making it difficult to get people with the necessary skills to focus on the infrastructure, leading to longer rollouts and compromises around non-functional quality attributes such as availability, scalability and reliability. When we are talking about mission critical applications used to deliver patient care, compromising in these areas is not acceptable.
Another challenge with on-premise software is managing the upgrade process each time new versions of software are made available. Each time we added a new feature to our software or addressed a defect this has to be deployed individually to each of our customers, creating a latency between the software being available and the software being used by clinicians. We wanted to make this latency period as small as is practical and ensure that when we release software all our customers reap the rewards at the same time. Multi-tenant cloud is the only way to achieve this.
Where did we start?
Once we made the decision to move to the cloud we didn’t simply execute this as a technology project. We took a step back and evaluated at all aspects of the business from our sales and marketing strategy through to our technology strategy. We drew a lot of inspiration from Crossing the Chasm, the famous book by Geoffrey Moore and subsequently enlisted the help of the Chasm group to help guide us through their methodology for companies like us. If you run a business and are interested in building disruptive mainstream products, take the time to read this book.
Adopting FHIR
Fast Healthcare Interoperability Resources (FHIR) is the latest standard from HL7. In short FHIR combines the best bits of previous HL7 standards but is optimised for modern mobile applications that demand open, REST-full api’s that support easy integration with other healthcare systems and enable flexible analytics. We took a really big bet on FHIR. When we first started using it two years ago it was still a very early draft but we could clearly see the benefits and made a decision that the risk was going to be worth the reward. We subsequently based our platform around FHIR and our secure, pure cloud multi-tenant FHIR service is something we are very proud of but more importantly is something that is delivering us and our customers real value, today. However, adopting FHIR it is not something that comes without its own set of challenges, the main one being the continuing evolution of what is still a draft standard. This is part of the deal when you are an early adopter. We acknowledge this and have processes in place to deal with it, but if FHIR is to ensure mainstream adoption and avoid a trough of disillusionment it needs to deliver against its roadmap to v1 as quickly as possible and minimise the breaking changes that are introduced along the way.
Cloud-only?
In early 2014 we started working on our cloud strategy. As with our mobile strategy (iOS-only) our cloud-only strategy when published was quite controversial with many people questioning the reasoning behind this approach. We listened to this feedback and spent quite a bit of time investigating products and technology options that would give us the flexibility to run on-prem, hybrid or public cloud. In the end, there were two many layers of abstraction, too many compromises and not enough benefit so our strategy remained unchanged. It was however a valuable exercise helping ensure we consciously went through the decision making process. Looking back now I am very happy our decision was the right one and you can read more about why in one of my other blogs.
Build, Buy or Partner?
We made a clear decision to ensure we maintained complete focus on doing the things we are good at, which is building world class healthcare applications and for anything else we would buy or partner. This has led to some great partners but more importantly has helped us get to market quicker. Some partners that deserve special mention include iNTERFACEWARE Iguana as the platform for our Connector Framework, Alfresco for our ECM and BPM services, AlertLogic to extend our own Web Ops capability with best of breed security as a service and FHIRBase as the back-end to our FHIR Service. We would be no-where today if we tried to build these components ourselves. It can be tempting to build everything yourself but focus on what you are genuinely good at first.
Software Architecture
In moving Evolve to the cloud we needed to remember why we were doing so in the first place and it was clear that to deliver against our goals we needed to re-engineer many of our core platform components from the ground up, optimised to leverage native cloud technology. The specific technology choices we made in doing so are a separate piece in itself (hopefully by one of our world class Product Architects) but some higher level design decisions deserve special mention
Key principles. Before we lifted a finger we needed clarity on the core principles that would help guide us as we made decisions along the way. We came up with three principles
- Security, performance and data integrity are our main goals. Anything that limits our main goals must be optional
- All components must be horizontally scalable and elastic. See above for anything that limits this
- Automate everything. See above for anything that limits this
Open by default. We adopted an open by default principle spanning all aspects of our platform; all the way from third party software to technology standards. This has resulted in a move from things like Windows, SQL Server and proprietary API’s to things like Linux, Java, PostgreSQL, open source products (such as Alfresco and FHIRBase) and open API’s using standards such as FHIR, oAuth and BPMN. There are many reasons for choosing open first. We believe in trying to create a community around the things we use so everyone can benefit together, but we also want to create a platform that is easy for developers to build against and integrate with. Open source also gives us a lot more control — we can see what is going on in the code, helping our developers understand more about it and we can make changes if we need to. Some people say open source is not secure, but for these reasons (among others) I don’t subscribe to this view. Of course there are challenges and we need to make sure we have processes in place to manage things like security vulnerabilities in the libraries we use but these are all out weighed by the benefits.
Micro vs mono. We adopted a micro(ish) services approach. We wanted more control over how we build, deploy and manage the different components within our platform so we have created a small number of services to support this. We don’t have 100’s of services and don’t see the need for this. We have realised the benefits we set out to achieve but as can often be the case with micro-services we have had our fair share of challenges, such as when our Web or iOS applications introduce dependancies between services leading to challenges around things like performance. If you are considering using micro-services, ensure you do it for the right reasons and not just because you have heard this new term on the crowded streets of software architecture.
So it’s been quite a journey and that’s just a very quick peek at some of the highlights. Thanks to AWS for inviting me to talk at the future cities event — it was a great opportunity to reflect back on our journey over the the last couple of years.
