Why Health Data Platforms?
tl;dr: Health Data Platforms provide a robust foundation for separating the healthcare data from the applications. This opens up a completely new way to think about building and integrating software for healthcare. This is also the only sustainable way to make the healthcare data — which needs to survive for as long as the patient lives, outlive applications, which usually have an average lifespan of 10 years.
Why today's healthcare software sucks
Digital transformation in healthcare today has been slow and painful. Instead of providing better care, most of the time is spent by physicians on their computers causing burn out. Even more time is being spent on "integrating" data across multiple systems and applications. Most software today are expensive, hard to use, and are not flexible enough to accomodate the changing needs of an organization.
This is usually a symptom of how these software systems are built. Healthcare software today is usually on of the following:
- Custom built software tailored to a specific use-case of an organization
- Standalone software that works for a specific use-case, but not for others
- Mega-suites that have a "one size fits all" approach
Problems with Custom built software
While the custom software approach is great while starting out, it depends on the availability of resources and time to build and maintain the software. Over time, the software becomes complex and harder to maintain. Multiple "use-cases" pop up and multiple applications have to be built and maintained. The responsibility of development and maintanence of the software is usually thrown on the back of a "singular developer" in the dingy basement of a hospital, or the software development team starts growing and pulls resources away from what the organization is supposed to do - provide excellent care.
A more inscidious symptom of building applications triggered by use-cases is that the data gets fragmented across applications. The meaning of the data can get lost in the myriad of schemas and database technologies used by each application. Often the same data is represented in different ways in different applications. This makes it hard to query and analyse the data. This is a problem that is often not realized until it is too late. And the often, the time and effort required to "integrate" data across multiple use-case specific applications is prohibitively expensive.
Problems with Standalone software
The standalone software approach is great for organizations that have a very specific workflow in a specific department. While it is great for the specific use-case, it is often not flexible enough to accomodate other use-cases. Most of the time, the organization is forced to change their workflow to fit the software.
A single standalone application usually doesn't solve all problems, so organizations resort to a "Frankenstein" of multiple standalone software that is hard to maintain and use. The data is often fragmented across multiple applications and the same problems as above arise. While some applications adopt some forms of data standards like HL7v2, CCDA, or god forbid PDFs to talk to other applications, the integration of this data across applications is always lossy and leaves a lot to be desired.
Problems with Mega-suites
The mega-suite approach is great for organizations that mostly follow standard structured workflows, it is often prohibitively expensive. This is usually because the vendor of the mega-suite has to build and maintain all the features that are required by all organizations.
When the organization grows, and innovates new ways to provide healthcare, the mega-suite often falls short. Feature requests usually take a long time to be implemented, or not implemented at all. This usually results in sub-optimal workflows and frustrated practitioners. Some organizations are forced to build custom software to fill the gaps. This usually involves a very slow and expensive "integration" phase and leads to the same problems as above.
A more problematic fact about mega-suites is that entire business model revolves around making sure the data is locked into their system. Integration of applications or moving to another system is often expensive and lossy; usually by design. While most of the data is generated by the organization, the hours of work and effort by practitioners and staff, the data is often held hostage by the mega-suite vendor unless strictly legislated by law. While legislation can only go so far, the mega-suite vendors have a lot of leverage over the organization and can even prevent or charge an exorbitent premium for access to valuable information that could be used to improve healthcare or migrate to a new system.
Data essentially gets locked into the system and the organization is forced to stick with the mega-suite vendor and their integrated suite of software for the foreseeable future.
From Chaos to The Digital Health Platforms
The above mentioned problems are not new. They have been around for a long time. The solutions are not new either. Imagine if you have to switch your entire phone just to use a different app. That would be crazy right? But that is exactly what happens in healthcare today.
It is only in recent times that the value of the "Digital Health Platform" is being understood by the industry.
At it's heart, the idea of the Digital Health Platform is to to seperate the application from the data.
This is a simple idea, but it has profound implications. It is the same idea that has been used to build the internet, and in fact this very document you are now reading. The internet is a platform that allows anyone to build applications using "standard, vendor-neutral" HTML, CSS and JavaScript. The browser you are now using to read this could be Chrome, Firefox, Safari, or even Internet Explorer - all developed by different vendors. But the data retreived can be rendered by your browser, or any other application in the future that understands the standard.
Similarly, the Digital Health Platform is a platform that allows anyone to build applications using "standard" domain-specific data formats and APIs. The organization is free to choose between vendors (including free, open-source) that provides these standard APIs for storing, querying, importing and exporting healthcare data. This gives the organization full ownership of data.
The applications need to be built to work with the Digital Healthcare Platform and it's set of standard APIs. This means that the applications are built with interoperability at it's core, not as an after thought. This is a lot harder than building a standalone application since the application has to be built to work with the data, and not the other way around. However, the benefits of building applications that work with a Digital Health Platform far outweigh the costs in the long run. Anyone can build applications that work with the Digital Health Platform, and organizations are free to choose or build the best application for their needs without being locked into a vendor or spending exorbitent amounts of money on "integrations".
This will also mean that specific vendors can focus on building the best use-case specific application for a niche, and not have to worry about the tons of integrations and features that are required by all organizations.
All data is stored in a vendor-neutral format in the Digital Health Platform, and the applications are built to work with the data. This means that the data can be queried and analysed in a standard way. This also means that if times changes and switching vendors for the platform is necessary, the data can be migrated to another system without any loss of information.