Medical Information System
Built a secure platform for storing and analyzing sensitive medical data, achieving full regulatory compliance and processing over 500,000 patient records reliably
Overview
A comprehensive medical information system designed for healthcare providers to securely store, retrieve, and analyze patient data. The platform handled electronic health records, diagnostic data, lab results, and clinical analytics, serving multiple healthcare facilities.
Problem
Healthcare providers were relying on fragmented, partially paper-based systems that made it difficult to maintain accurate patient histories, perform cross-facility data analysis, or meet evolving data protection regulations. Existing digital tools were legacy JSP applications with no proper API layer, making integration with modern clinical tools impossible.
Constraints
- Strict compliance requirements for handling protected health information (PHI)
- Legacy JSP frontend that could not be rewritten within budget, requiring careful backend modernization
- High availability requirements as the system was critical for clinical decision-making
- Database schema migrations had to be backward-compatible to avoid disrupting active clinical workflows
Approach
We incrementally modernized the backend, introducing a clean REST API layer on top of the existing data model while maintaining the legacy JSP frontend for users not yet migrated to newer client applications. Flyway managed all database migrations with rigorous rollback scripts. Security was implemented at every layer: encrypted data at rest, TLS for all communications, role-based access control, and comprehensive audit logging.
Key Decisions
Used Flyway for all database schema evolution with mandatory rollback scripts
Medical data integrity is non-negotiable. Every schema change needed to be reversible without data loss, and the migration history had to be fully auditable for compliance reviews.
- Liquibase with XML-based changesets
- Manual SQL migration scripts tracked in version control
Maintained the legacy JSP frontend while building a parallel REST API
Rewriting the frontend would have doubled the project timeline and introduced risk for clinical staff who were trained on the existing interface. The REST API enabled new integrations and a future frontend migration without disrupting current users.
- Full rewrite with a modern SPA framework
- Server-side rendering with Thymeleaf to replace JSP
Implemented field-level encryption for the most sensitive patient data columns
While full-disk encryption covered data at rest, field-level encryption added defense-in-depth for fields like diagnosis codes and personal identifiers. Even if the database were compromised, critical fields remained protected.
- Rely solely on database-level transparent data encryption
- Application-level encryption of entire record payloads
Tech Stack
- Java 17
- Spring Framework
- Spring REST
- JDBC
- MySQL
- Flyway
- Apache Tomcat
- JSP (legacy frontend)
Result & Impact
- 500,000+ across multiple facilitiesPatient Records Managed
- 99.95% over the 3-year engagementSystem Uptime
- p95 under 200ms for record retrievalAPI Response Time
- Passed 4 consecutive compliance audits with zero findingsAudit Compliance
The platform became the backbone of clinical data management for the healthcare providers we served. Clinicians reported faster access to patient histories, the analytics module enabled data-driven insights that were previously impossible, and the audit trail gave administrators confidence during regulatory reviews. The REST API layer opened up integrations with third-party lab systems and clinical decision support tools.
Learnings
- In healthcare software, the audit trail is as important as the feature itself. Every data access and modification must be traceable to a specific user and timestamp
- Legacy frontend preservation can be a pragmatic choice when the alternative is disrupting trained clinical staff during patient care
- Field-level encryption adds meaningful security but requires careful key management and has performance implications for queries involving encrypted columns
Technical Deep Dive
The core technical challenge was designing a data access layer that could serve both the legacy JSP frontend and the new REST API without duplicating business logic. We introduced a service layer that encapsulated all medical record operations, with the JSP controllers and REST controllers both delegating to the same services. This shared layer enforced access control, audit logging, and data validation uniformly, regardless of the entry point. JDBC was used directly rather than an ORM to maintain precise control over query performance and to handle the complex medical data schema, which included hierarchical diagnostic codes, temporal lab result series, and cross-referenced clinical notes.
Database migrations were the most operationally sensitive part of the system. Every Flyway migration script went through a dedicated review process that included a rollback test on a production-mirror database. We established a policy that no migration could hold locks on clinical tables for more than 30 seconds, which meant large data transformations had to be executed as background jobs with progress tracking. Over the course of the project, we executed over 150 schema migrations without a single incident affecting clinical operations.
Security was layered throughout the architecture. Beyond field-level encryption for sensitive columns, we implemented row-level access control that restricted which patient records a given clinician could access based on their facility and department assignments. All API endpoints enforced authentication via session-based tokens with configurable expiration policies, and every data access event was written to an immutable audit log. This comprehensive approach meant that during regulatory compliance audits, we could demonstrate exactly who accessed what data and when, down to the individual field level.