Why Quarkus?

Our platform is built on top of high-quality, commercially supported open-source assets as much as possible. This gives us access to a wide variety of capabilities that meet our cost constraints. From the backend service perspective, our preferred language is Kotlin, so naturally we gravitate toward JVM-centric open-source projects. Obviously, Quarkus fits the requirement perfectly.

We decided early on, given the types and volume of workloads we'd need to run, that Kubernetes was the right choice. Using Kubernetes provides many benefits including customer isolation and horizontal and vertical scaling. Additionally, Quarkus's advanced Kubernetes support has been one of the reasons we've been able to build our platform out at a very fast pace and contain costs. We deploy native GraalVM builds that allow us to pack our Kubernetes cluster more densely as well as benefit from fast startup times and use fewer resources when compared to traditional Java builds. An added benefit of these native builds is that we deploy them using the Quarkus micro docker image. The Quarkus micro image is, as the name implies, very small. The small size and lean composition significantly reduce our security exposure.

During the platform's inception phase, we elaborated on a few key technical considerations that we believed would help differentiate us from our competitors. For one, we wanted to be as real-time as possible. We didn't want delays in information processing. We aimed to deliver real-time analytics dashboards and up-to-the-second patient information directly to our partners within their preferred workflows. Much of healthcare interoperability is still accomplished using older approaches like file transfers, fax machines and telephone calls. That works but is very inefficient when considering approaches like event streaming, so taking an event-driven mindset when building solutions was important to us.

For our use cases leveraging a hosted Apache Kafka infrastructure looked to be the easiest approach to provide us with an event-driven foundation. Kafka serves as the central nervous system of our healthcare platform. It enables the real-time, fault-tolerant and scalable exchange of events among different services and systems. Kafka's durability and high throughput ensure that no critical information is lost, making it an indispensable part of our architecture. Leveraging the Kafka extensions that Quarkus provides has allowed us to quickly assemble solutions, like streaming ETL pipelines, that transform incoming batch file data as well as real-time data from hospitals and health information exchanges to event streams that are further transformed to various healthcare standard and non-standard formats. The ETL processors use both the Quarkus Kafka streams and Smallrye Reactive Messaging extensions depending on need. We also leverage the Quarkus Redis extension from within the ETL processors to enrich the incoming messages when necessary. The resulting transformed data is then available to multiple services for use case-specific processing.

As is typical in many healthcare interoperability scenarios, we need to handle standard healthcare formats, like HL7v2, Clinical Document Architecture (CDA) documents and Fast Healthcare Interoperability Resources (FHIR), as well as non-standard custom data formats. Quarkus's tight integration with Apache Camel gives us easy access to numerous exchange protocols and data formats. The great part of that is how easily Camel extensions can be integrated with other Quarkus ecosystem extensions. This has helped us really focus on business logic and let the various Quarkus extensions take care of all the protocols and data formats we deal with. As mentioned, we consume data in many formats but when we expose APIs to B2B partners we prefer to use FHIR as the exchange format. The Camel Quarkus FHIR extension gives us out-of-the-box FHIR interoperability and message transformation capabilities.

We started our journey with Quarkus very early on. Our first production deployments used Quarkus version 1.3.0. The Quarkus ecosystem has matured a lot since then and added an impressive array of additional capabilities which we've been able to take advantage of along the way. For us, the improvements in dev mode and testing stand out. We've taken advantage of the Live Coding feature from the very beginning. The new dev-ui has added yet another very valuable tool that provides great insight when trying to resolve issues during development. One of the enhancements we appreciate the most is all the work that's been done to improve the testing experience. The recently added Kafka Companion test library is a great example of that. We're able to quickly develop complex testing scenarios in our test packages without a lot of setup. Using the Kafka Companion library has helped us simplify our test code.

Conclusion

Our journey to build a next-generation healthcare platform using Quarkus, Kafka, Kubernetes, Apache Camel, microservices and streaming ETL is a testament to the power of modern technology in revolutionizing the healthcare industry. Our event-driven approach, coupled with real-time data processing and embedding our products within existing workflows, will empower healthcare professionals to deliver better patient care, enhance operational efficiency and ensure data security and compliance.

As we continue to develop and refine our platform, we look forward to making a positive impact on the healthcare ecosystem, ultimately improving the lives of patients and healthcare providers alike. The future of healthcare is collaboration, and we are excited to be at the forefront of this transformation.