- Industry: Healthcare IT (medical-coding reference and billing software)
- Organization: A healthcare-IT publisher whose medical-coding software is used by clinicians and billing teams nationwide
- Environment: Python web application on PostgreSQL with LDAP/SAML single sign-on and full-text search, dual-site high-availability clusters in two US data centers, now running on Google Cloud Platform
- Engagement: Full-stack hosting, development, and managed operations, client since 2010
- Services: Application development · Managed hosting & HA · PostgreSQL operations · 24×7 incident response
| 1,227 of 1,227 Emergency- and High-priority issues resolved: a 100% closure rate across roughly 2,850 tickets |
|---|
| 9 of 12 production emergencies resolved the same day they were opened |
| Zero customer downtime through real RAID, NIC, and power-supply hardware failures, absorbed by dual-site failover |
| Complete re-platform from legacy Java/JBoss to Python + PostgreSQL, delivered through a clean cutover with no user disruption |
| Annual incident-and-request volume down from a peak of ~780 tickets to under 25: a platform that now largely runs itself |
The Client
The client is a healthcare-IT publisher whose medical-coding reference product is consulted daily by clinicians and billing teams nationwide to select and validate procedure, diagnosis, and fee-schedule codes. The same platform powers white-label editions for major healthcare organizations, including a national health insurer. An outage does not inconvenience one company. It stalls coding and claims workflows across many. PostgreSQL is the system of record for the code sets, quarterly Medicare fee data, and licensing entitlements the entire product depends on.
The Challenge
Most consultancies are handed a database. This client handed us the entire platform: hosting, application development, authentication, search, monitoring, and the regulatory data pipeline.
The original stack, Apache fronting a JBoss/Java application, was showing its age. Application crashes were being band-aided with scheduled nightly restarts. Connection-pool exhaustion periodically blocked all logins. Un-rotated logs filled disks and took servers down. Quarterly regulatory data loads (Medicare fee schedules and code-set updates) were manual and error-prone, occasionally requiring emergency hand-entered corrections from late-breaking federal bulletins. Meanwhile the platform lived on aging bare-metal hardware whose RAID arrays, NICs, and power supplies were beginning to fail. In healthcare, every one of those risks converts directly into clinicians who cannot code and claims that cannot bill.
The Solution
We executed a multi-year modernization program while operating the production platform without interruption:
- Re-platformed the application from JBoss/Java to Python on PostgreSQL: schema normalization, a rebuilt fee-calculation engine validated by roughly 120 passing test cases, an integration API, and full-text search. Alpha releases went to customer testers before a clean legacy-to-modern cutover. The old login path redirected transparently, and a final legacy data update extended more than 1,500 expiring user accounts so no one fell through the gap.
- Delivered enterprise SSO for the national-insurer edition: SAML/Shibboleth federation with browser-matrix testing and a fallback login path. After a provisioning defect caused an access outage, we hardened attribute synchronization and put annual certificate renewals on a routine cadence.
- Built and battle-tested high availability: dual-site clusters with documented, rehearsed failover procedures and a quorum observer node added with no downtime. When hardware actually failed (a degraded RAID array, a failing NIC, a dead power supply), each event was absorbed by failover, including a power-supply replacement performed with zero downtime against a pre-synced standby.
- Matured operations: centralized logging with one-year retention and automated pgBadger reports, fleet-wide NTP, a fleet-wide unused-index cleanup shipped as a tagged release, session-limit enforcement added after a login-storm incident, same-day mitigation of an abuse run that hit one endpoint with ~570,000 requests in a day (versus ~3,000 normal), prompt responses to industry security events, and proactive PostgreSQL version advisories.
- Migrated the platform to Google, retiring the bare-metal footprint and moving backups to cloud snapshots. That quietly ended years of recurring storage-capacity and backup-failure churn.
The Results
Across more than fifteen years and roughly 2,850 tickets, every Emergency and every High-priority issue, 1,227 in all, was resolved, with 9 of 12 emergencies closed the same day. Hardware failures that would have meant outages elsewhere produced zero customer downtime.
The clearest evidence the modernization worked is the ticket curve itself. Annual volume fell from a peak of about 780 during the build years to fewer than 25 today, with no open incidents: a mature platform in inexpensive steady-state operation. The relationship keeps compounding. In the engagement's second decade, the client began onboarding another major healthcare organization onto a new white-label edition of the platform we built and run.
Why it Matters
A database consultancy that can also design, build, host, and operate the application around the database changes the economics of a niche software product. The publisher keeps its focus on content and customers while a single accountable partner owns the full stack. The proof is longitudinal: declining ticket volume, emergencies that close the day they open, hardware failures nobody notices.
That is the difference between a break-fix vendor and a partner. One shows up when things break. The other makes sure you stop noticing.