Health IoT is ubiquitous now. Cell phones, bracelets, watches, rings, and many other devices are constantly capturing health telemetry. The amount of data and the variance in formats and content call for a highly scalable and modern software stack.

For example, PGA golfer nick Watney noticed that his respitory rate was higher than normal overnight which resulted in his seeking a Covid test and testing positive.

Automation tools like business rules and business processes could be used to monitor and take automated action based on health data from IoT devices. Including capturing device data like that information that triggered Watney's positive test.

Quarkus is uniquely situated to process this data and in some cases provides the only native capability I know to perform the task. Business rules and bpm in a serverless microservice is an incredibly powerful and unique pattern delivered by Quarkus and Kogito.

The ability to deploy fast serverless microservices is key since the health data is bursty depending on user connections and time of day. And the ability to integrate business rules into that same architecture via Kogito is something that no other framework can provide in serverless environment out of the box.

What it does

The objective of the architecture is to create an efficient, serverless, and rules driven architecture that can be used to process health data telemetry from a wide array of devices and health data ecosystems and unify those diverse sources to allow for common processing and actions within a given population.

A rules driven approach gives enterprises the ability to customize data processing via decision tables (and in the future via business process management notation). Coupled with a serverless architecture allows for rapid deployment of new capability on Quarkus with little or no code changes.

For the Hackathon the system provides integration to a single source of health data in Google Fit. The rules and dashboard are setup to handle alerts and data from multiple sources.

How I built it

From a technical perspective the goal of the architecture is to create a set of services that allow an enterprise to process a diverse set of health data telemetry, evaluate that data in a highly customizable way (business rules and decision tables), and to take action and evaluate the data in a common environment. Quarkus enables those goals with out of the box serverless functionality and through integration with Kogito.

The population health architecture is composed of three services.

  • Health Extract Transform and Load (ETL)
    • Processes raw IoT device data and normalizes for rules processing and API invocation in decision services
    • Can be run in serverless mode with scheduled (pull) or event driven invocation (push)
  • Serverless Decision Services
    • The decision services is a Quarkus and Kogito microservice that executes business rules against API invocation from Health ETL or other actors who meet the API contract.
    • Decision services can be run in a serverless mode. The default implementation takes advantage of the amazon-lambda-http Quarkus implementation to allow the function to execute based on event invocation
    • Baseline rules are built using Excel based decision tables for easy consumption from business users
  • Population Health Dashboard
    • The population health dashboard is a Quarkus microservice that exposes the results of rule invocation in the Serverless Decision Services
    • In the default implementation the dashboard process Rewards and Alert data and exposes endpoints to store both
    • The dashboard takes advantage of the Quarkus ability to host a static site and exposes html and javascript via that capability using a bootstrap based dashboard

Challenges I ran into

There was a ton to learn! I ran into a few bugs in Quarkus and was able to open community issues for those. Getting Quarkus and Kogito to work correctly together in a serverless environment was especially challenging.

Integrating with Google Fit was also very difficult. The OAuth token flow for the Google APIs is ... challenging. However, I was able to use the Quarkus servlet capability and a servlet callback approach to fetch and store the refresh token.

Some bugs in Kogito were especially blocking.

Accomplishments that I'm proud of

I am especially proud of the fact that I was able to submit and get a PR merged to the Quarkus source. It is a small change but I hadn't used Quarkus a month ago and now I've got code in the source (about 3 lines).

Getting the end to end flow from Google Fit all the way to the dashboard in the period of time available I also think is a great accomplishment.

Using the Panache entity flow for fast persistence was also a great achievement and a great tool. The data storage for rewards and alerts was accomplished in an afternoon because of the efficiency of this tool.

Finally, this is the first lambda I've deployed to AWS and getting that running and live including Kogito and Quarkus was a great milestone in the project.

What I learned

  • Quarkus rest client
  • Quarkus lambdas
  • Quarkus Panache
  • Building native images with Quarkus
  • Kogito
  • decision tables
  • Google API OAuth flow
  • Google FIT APIs

What's next for Population Health

  • A service to automatically generate and deploy a lambda based on a user provided decision table (no code lambdas with Quarkus. Airtable raised $170M with less ;) )
  • Add authentication and protected endpoints
  • Integrate the dashboard APIs and expose the full range of APIs for the charts
  • Expand the integration to include more data from more devices
  • Refactor some of the rest client and model code to be shared across the services (learned this during the flow)
  • Rebuild the dashboard in a modern JS framework
  • Enhanced data input and data structures for the decision services API

Built With

Share this project: