Engineering Transparency
Every engineering choice documented, debated, and validated. Browse the decisions that shape a production healthcare platform.
Problem Statement:
HDIM clinical services needed to maintain immutable audit trails, enable temporal queries (state at any point in time), support event replay for data corrections, and provide complete forensic capability for healthcare quality measures. Traditional CRUD patterns with UPDATE/DELETE statements make it
Problem Statement:
HDIM had a single monolithic Kong/Spring gateway service handling all API requests (general-purpose, admin, clinical, FHIR) with duplicated authentication logic, mixed domain concerns, and inability to apply domain-specific optimizations. This created code duplication, poor scalability, and made it
Problem Statement:
HDIM required an enterprise event streaming platform to enable asynchronous microservice communication, event replay capability, and guaranteed message delivery. The system needed to support publishing events from one service and consuming them in multiple services reliably.
Problem Statement:
HDIM needed database isolation strategy for 29+ microservices. Shared database would create coupling; separate database servers would be expensive and complex. PostgreSQL supports multiple logical databases per instance—enabling service isolation with single infrastructure footprint.
Problem Statement:
HDIM requires a FHIR R4 compliant server for storing and serving clinical resources (Patient, Observation, Condition, MedicationRequest, etc.). The implementation must support:
HDIM had mixed database migration approaches (Flyway in some services, no migrations in others) creating inconsistency, version control issues, and unsafe schema changes. Needed standardized migration tool with rollback support for production safety.
Problem Statement:
HDIM's 28 microservices require asynchronous communication for:
Traditional sequential development (one team per week) was too slow for healthcare delivery timelines. HDIM needed concurrent team execution (RED-GREEN-REFACTOR cycles) to accelerate feature delivery while maintaining quality.
HDIM requires a primary database for:
Backend services needed authentication without performing repeated JWT validation or database lookups. Validating JWT in every service creates bottleneck; trusting gateway headers is more efficient.
HDIM requires caching for:
HDIM had 51 microservices communicating via HTTP, Kafka, and direct calls. Tracing a single user request across all services was impossible without manual log aggregation. Needed automatic trace propagation and visualization.
HDIM requires a backend framework for 28 microservices that provides:
HDIM serves multiple healthcare organizations (tenants) with strict isolation requirements. Patient data from Tenant A must never be visible to Tenant B. Required database-level isolation enforcement.
HDIM's 28 microservices require an API gateway to:
HDIM caches Protected Health Information (PHI) in Redis for performance. HIPAA regulations require reasonable safeguards for PHI; indefinite caching violates compliance. Need to balance performance with security.
HDIM uses shared modules (authentication, audit, persistence) to provide cross-cutting concerns. These modules use @AutoConfiguration with @EntityScan and @ComponentScan that force-register entities and beans in every consuming service. When a service has its own database that doesn't contain the ta
HDIM needs a sustainable content distribution workflow for LinkedIn — the primary channel for reaching healthcare payers, ACOs, and clinical quality leaders. Manual posting is inconsistent; fully automated posting is reputationally risky for a pre-revenue startup. A middle path is needed: AI drafts,
HDIM's data source connectors (EHR connector, CDR processor, CMS connector) and evaluation engine (CQL engine, care gap service) were implemented as independent services. Data could be pulled from external systems but had no automated path to FHIR persistence or downstream quality measure evaluation
Architecture decision record
Architecture decision record
Architecture decision record
Architecture decision record
Architecture decision record
Architecture decision record
Architecture decision record
Architecture decision record