Our Next Chapter
Over the past decade, we found ourselves with an increasing number of projects in healthcare technology. Maybe this is due to our location in Boston, a hub for both healthcare and technology. Or perhaps it was inevitable that we’d run into it eventually, given that healthcare is a $7 trillion global industry. Regardless, as technologists, we found a domain that has opportunity, purpose, and plenty of problems to solve.
We love building applications. In healthcare this is no different. However, we found ourselves in a world of extraordinary data inaccessibility and outdated means of data sharing (e.g. SFTP and nightly mailboxes with EDI files are still common). Also, user workflows were locked by the vendors of healthcare systems. So the status-quo was to build yet-another-thing that a doctor or nurse would have to open separately and sign in to. Unpleasant and undesirable to say the least for end users, and uninspiring for us to develop on.
Furthermore, we know patients own their data and can choose to share it as they see fit. We see use cases of sharing data when patients switch doctors, see a specialist, or or sign up for health and wellness applications. However, this data was also locked in the proprietary systems their healthcare providers use. Barriers of technology and lack of market incentives created a wall between patients and their property, their data.
Then a few years ago, something happened. It started with a contemporary take on a data exchange that existed outside healthcare for some time — a new resource-based web API called FHIR.
FHIR had arrived. An API for human health. A game-changer for the industry spanning technology, standards, and fostering a new inclusive community.
The amount of energy and excitement around FHIR, along with pressures from healthcare organizations and government agencies, all are converging. Now the big health software system vendors, such as EHRs, started to embrace and support FHIR. This led quickly to more seamless workflows via the SMART on FHIR project — which allows single sign-on and context passing using conventions and existing web standards. And these same standards are available to patients, using their patient portals provided by their healthcare provider. This enabling technology also allows us to move from a fee-for-service to a value-based care model, by making it possible to implement clinical decision support at the right time in the doctor’s workflow with the right context.
We are still at the onset of this massive change. We are at a point in time where the canonical transactional record systems that hold patient data are now becoming accessible for third party innovation and application development. Introduction of health application marketplaces are emerging (think Apple App Store or Google Play), promoting development and investment in product ideas for both clinical providers and patients.
As we ride this trend, we find ourselves investing more of our own time and energy into the FHIR ecosystem. We continuously learn, run meetups, and build open source tools. All of this is so we can increase our efficiency to help our clients create their applications.
We want to be sure building healthcare applications is accessible to the widest and most diverse population of developers possible; we believe diverse teams are more creative, more innovative.
To this end, we have embarked on a journey with an organization that includes one of the three people that conceived this human health API. A company that is 100% FHIR, committed to its growth and support for the global community, and driven to make health technology a better place.
We are building with Firely. A company based in Amsterdam, now opening in the US, with us in Boston.