A hospital has no quiet hour. Clinical, messaging, and diagnostic systems run continuously, the records inside them are protected health information, and the database most likely to need work is usually the one nobody will agree to take offline.
US-based DBAs. HIPAA delivery experience.
Why it matters
There is no safe time to work on these systems and no acceptable way to lose what is in them.
A system goes in, it works, it becomes load bearing for patient care, and from that point leaving it alone wins every time. Indexes are not rebuilt, versions fall behind, and access lists grow by addition and never by removal.
The backup job reports success every night without anyone establishing what a restore from it would actually produce, or how long it would take. Nothing in that picture looks like a problem until it is one.
A clinical application slowing at shift change, an auditor asking who holds read access to a table of patient records, or a restore attempted for the first time on the day it matters. All three are avoidable on a schedule.
The database problem in healthcare is that there is no safe time to work on the systems and no acceptable way to lose what is in them. Clinical, messaging, and diagnostic platforms run around the clock, protected health information under HIPAA governs who may reach the data and what the audit trail has to prove, and the environments carrying the most risk are often the ones that have run untouched for years. Fortified Data manages and assesses those environments on Microsoft SQL Server, Azure SQL, Oracle, PostgreSQL, and MySQL, with maintenance planned against clinical load rather than against the clock.
Healthcare environments accumulate a particular kind of debt. A system goes in, it works, it becomes load bearing for patient care, and from that point every argument for touching it loses to the argument for leaving it alone. Indexes are not rebuilt, versions fall behind, access lists grow by addition and never by removal, and the backup job reports success every night without anyone establishing what a restore from it would actually produce.
None of that shows up in monitoring, because monitoring reports on the system as configured. It shows up when a clinical application slows at shift change, when an auditor asks who holds read access to a table of patient records, or when a restore is attempted for the first time under pressure. The work below is aimed at all three, and it is scheduled around care delivery rather than around a change calendar.
The platforms are the same ones Fortified Data runs everywhere. What the sector changes is when the work can happen, what it has to prove, and which failure is unacceptable. Either of two assessments is a fixed-scope way to start: a database health check of performance, availability and recoverability, or a database security assessment of access control, encryption and auditing.
There is no window that is safe by definition, so patching, index maintenance, and statistics work are sequenced against measured activity and the shift pattern, not against a Sunday night slot that suits the calendar.
Under HIPAA, who can reach the data matters as much as whether the data is available. Privileged accounts, service accounts, and standing read access are reviewed on a cadence rather than configured once and inherited.
Backups are verified and restores are actually run, because a failed recovery on a system holding patient records is a reportable event and not an inconvenience. What the restore produces, and how long it takes, is established before it is needed.
Audit and change history grow until something is done about them, and trimming them to reclaim space is a compliance decision rather than a housekeeping one. The retention choice is made explicitly and documented as it is made.
The database rarely fails on its own. Messaging and integration platforms move clinical data between systems, and their databases are assessed and monitored alongside the applications everyone already watches.
Clinical records, imaging, and device output grow in a shape that does not resemble a transaction system. Storage and performance forecasting is done against measured consumption in the environment itself rather than against a general growth rule.
Obligations at the database layer
HIPAA is written about protected health information, not about database engines, so the work is translating an obligation into a configuration and then into evidence. Most of what an assessor asks for at the database layer comes down to the same question in six forms: who can reach this data, what happened to it, and can you show me.
Fortified Data maintains those controls continuously and records them as the work is done, rather than reconstructing a year of evidence in the month before an assessment. Where a control cannot be met as the environment stands, it is raised as a finding with a remediation route and an effort estimate, not left to be discovered by someone else.
Delivered result
One engagement, reported as the client measured it. Every figure here is stated once in shared.json and read from there, so this page cannot disagree with the same claim anywhere else on the site.
Healthcare
The client is not named under the terms of that engagement. A separate engagement, for a healthcare communications platform, is written up in full: read the case study.
Assessment and delivery are done by US-based DBAs and consultants, with a named Strategic Account Manager, Pod Lead, and Primary DBA. There is no offshore escalation path for an environment holding protected health information.
The engagements below include a messaging platform under pandemic load and an FDA-regulated test rig that has run for years without a shutdown. Planning work around an availability constraint is the normal case here rather than the exception.
Reporting is written for the people who answer to an assessor or a board as well as for the people who run the systems, with each finding rated for severity and costed in effort.
Delivered work
Described as far as the terms of each engagement allow. Client names are withheld.
A healthcare messaging client came to Fortified Data with recurring stability problems. We stabilized the environment, raised server availability to 99.995%, and made sure the platform could scale to carry the demand COVID-19 put on it.
A client needed help scaling platforms regulated by the FDA: racks of artificial hearts pumping fluid matched to the viscosity of blood, running more than eight years without ever being turned off once. Fortified Data optimized the stability and performance of the line of business running that testing, inside a custom design built to meet the FDA’s expectations.
A large Meaningful Use project needed an entire platform created while a data migration was already under way. Fortified Data built it and designed the analytical metrics that satisfied the Meaningful Use requirements, rather than delivering the platform and leaving the reporting to be solved afterwards.
Yes. Fortified Data manages and assesses database environments holding protected health information, including clinical messaging platforms and FDA-regulated test systems. Access control, encryption, audit trail retention, and privileged account review are treated as continuous obligations with documented evidence rather than as one-time configuration.
Fortified Data plans maintenance against measured clinical load rather than against a fixed calendar slot. Patching, index and statistics maintenance, and configuration changes are sequenced into the periods where activity on that specific environment is lowest, staged where the platform allows it, and agreed with the clinical owners before they run. Where a change genuinely cannot be made online, the constraint is raised early enough to be planned around rather than discovered on the night.
Microsoft SQL Server, Azure SQL, Oracle, PostgreSQL, and MySQL, running on premises or in AWS, Microsoft Azure, and Google Cloud. A mixed estate is covered under one agreement and reported in one document rather than split across separate platform reviews.
Yes. Fortified Data has optimized the stability and performance of the line of business running an FDA-regulated test platform, inside a custom design built to meet the FDA's expectations for that environment. The constraint on that class of system is that the design cannot be changed casually, so the work is planned around what the validated configuration permits.
Backups are verified and restores are performed rather than assumed. Fortified Data establishes what a restore actually produces and how long it takes, documents the recovery point and recovery time the environment currently supports, and reports the gap where that is short of what the organization believes it has. On systems holding patient records, an untested backup is among the most common serious findings an assessment returns.
Usually not. Most of what users experience as a slow clinical application is query, indexing, configuration, or resource contention at the database layer, and it can be addressed without touching the application or its vendor support position. Fortified Data measures where the time is actually going before recommending anything, and says plainly when the answer is in the application rather than the database.
The first conversation covers which systems cannot stop, which obligations reach the data, and when a restore was last tested. An assessment answers all three with evidence rather than assurance.
Let us show you what's possible.
Two ways to start
US-based DBAs. HIPAA and SOC 2 delivery experience.