Production shared platform capability / Case study

RTLS Processing and Reporting Services

Shared RTLS processing and reporting services supporting healthcare workflows in an event-driven environment.

Role
Architecture and implementation
Timeframe
2020–2026
Employer
TeleTracking
Technologies
Java / Spring Boot / MongoDB / Kafka / REST / Docker / AWS EKS

Initial scan

Healthcare RTLS events needed a shared processing boundary that could support application workflows and reporting.

  1. 01Shared processing

    Implemented shared RTLS processing services.

  2. 02Event-driven design

    Handled asynchronous events through a consistent service design.

  3. 03Workflow support

    Provided application-ready workflow context.

  4. 04Reporting integration

    Provided a shared boundary for related reporting needs.

Overview

RTLS observations can support healthcare workflows when applications receive useful context rather than raw integration details.

I designed shared RTLS processing and reporting services that provided that boundary in an event-driven environment.

The problem

Raw RTLS events did not directly provide the workflow context that downstream systems needed, including the next expected workflow step.

The events were asynchronous and could arrive out of order, so consumers could not depend on one ideal arrival sequence.

My role

I designed and implemented the shared RTLS processing and related event-driven reporting services.

Processing approach

The processing services established a shared boundary between incoming RTLS events and the applications that used them. The approach emphasized:

  • Event-driven input handling
  • Shared workflow context
  • Consistent outputs for application consumers
  • Clear separation between processing and reporting responsibilities

The implementation served as a reusable platform capability for healthcare workflow needs.

Reporting integration

Related reporting services used the same shared platform boundary instead of duplicating integration behavior in each consumer.

Operational effect

The shared services gave applications and reporting consumers a consistent way to use RTLS workflow context without each consumer implementing the same integration concerns.

What this demonstrates

  • Event-driven healthcare systems
  • Shared platform architecture
  • RTLS processing
  • Workflow and reporting integration
  • Reliability under asynchronous event delivery

Let's talk

Need someone who can take ownership when the problem crosses every boundary?

Open to remote software engineering and architecture opportunities in the United States.