By Eugene Kuznetsov, Co-Founder of Commure
We believe that a big part of the problem with US healthcare today is the lack of innovation in everything outside of medicine itself, and especially the legacy software that runs America's hospitals. Healthcare needs better software at its very core, starting with better software for doctors and eventually for everyone involved. The backbone of innovation in today's world is digital and virtual: the twin forces that have transformed many sectors of our society, not always for the better, but always decisively. Commure has been building a way to harness this power and to do so responsibly, and we are finally ready to talk about it.
What are we announcing today?
We are really excited to be launching a developer platform and a broad set of APIs and SDKs that developers can use to build modern medical software using open standards. Notably, we built it in close collaboration with health systems to make sure that it both met their security, privacy, safety and regulatory requirements and yet greatly simplified things for developers. This announcement is only a small-yet-important part of Commure's ultimate offering, but it's a crucial step towards delivering on our company's mission of better software for doctors (and nurses and patients).
This is already deployed in production at major US health systems. This is a first for a FHIR-native platform -- meaning one where all of the data is encoded and processed using an open standard (HL7 FHIR) instead of closed and proprietary APIs. It brings modern tech and open API principles to healthcare and enables anyone to use contemporary programming languages and frameworks to build healthcare applications. We also believe we have solved many of the hard problems that any engineer building for this space has to overcome.
For whom did we build this dev portal and platform? The way to build this new software layer is by combining the best parts of Silicon Valley innovation and medical safety expertise, and it's not something that any one company can do on its own: it must be an open, safe, secure ecosystem with hundreds or thousands of specialized teams solving their parts of the problem. That’s part of why we started by working with hospitals and physicians to help make sure the foundation was responsible-by-design.
Once these security and safety controls are in place, innovation in medical software can come from hospital innovation teams, from established vendors, from young inventors, from doctors-who-code, and from innumerable others. What is essential is that all of this growing human and financial investment does not do harm and is not wasted -- that it has a fair chance to make a positive difference on a level playing field.
With that context of why and for whom, I am going to talk a bit more about the technical details of the what. Commure’s stack is a combination of REST APIs on Rust, React.js on TypeScript and containers on Kubernetes. Many software engineers will find most of these either already familiar or on their "list of things to learn in 2020". However, FHIR may be less familiar to those without recent healthcare IT experience.
What is FHIR and why FHIR-native?
The international HL7 standards non-profit created FHIR as an open standard for a comprehensive "healthcare API". Consisting of over 150 different "resources" and numerous operations in a comprehensive JSON REST API, the FHIR standard can be used to express everything in health, from lab results to billing information. Just as important, all of the major technology vendors have pledged support, as have all of the major EHR vendors and the US government. By developing for this open API, applications can be built faster, cheaper and in a way that they interoperate with each other. Unlike past efforts at creating a single API standard for healthcare, FHIR is both technically modern and vendor-independent: there is no lock-in for those using it in their applications. Commure was built with FHIR from the ground up -- what we call "FHIR-native" -- which provides important technical advantages.
Let's now return to the question of why we have chosen to spend more than two years in stealth mode before revealing just a part of what we are building. Many companies have to launch early so they can get their first customers or investors, but Commure already has both. So from Commure's first days, the founders decided to avoid publicity before we had things that were real, before having software someone could touch and use. Healthcare innovation has already had too much hype and false hope -- instead, it requires patience and credibility, and those are easier if one builds before announcing.
I saw no need to write here about the many problems with the US healthcare system: there are whole books written on the subject, from every possible political and professional perspective and I doubt I could say it better. However, it may seem strange to suggest that fixing software is key to improving healthcare, instead of government policy reforms or specific medical breakthroughs. But it's only counterintuitive if one hasn’t spent time digging into it. Every practicing doctor I know complains about their EHR, every patient is frustrated with their patient portal, every hospital CEO is looking for a path to improvement, and everyone is looking for trustworthy information about what works and what doesn't.
So this is what we’ve been building and why. I couldn’t be prouder of the team, and I look forward to developer feedback on this initial public release and there is much more to come. Our long-term goal with this developer platform is to make better software for doctors - and ultimately everyone - by enabling every developer to quickly build and responsibly deploy FHIR-native applications. We believe that better software for healthcare created by everybody will make healthcare better for everybody.