PFLB is a performance testing company for healthcare applications. We load test EHR, patient portal and billing systems on synthetic or anonymized data, measure where they degrade, and verify the fix before clinicians feel it. Founded in 2008, with 150+ engineers, 300+ companies served and a SOC 2 Type II report.
Thousands of healthcare professionals can log in at once when a shift starts, and the morning rush adds scheduling appointments, patient records and lab lookups on top. Software that cannot respond quickly at peak hours holds up patient care.
Flu season and public health emergencies push patient portals and telemedicine platforms well past normal demand. Spike testing shows how the system behaves in a sudden surge and how it recovers.
Response time in a records and billing system depends on data volume and distribution. A database structure change can cause performance degradation that a single-screen check never shows.
Healthcare platforms exchange data with lab systems, pharmacies, payers and legacy software. One slow interface can stall a clinical workflow, so the test has to include it, or an emulator that behaves like it.
How the Engagement Runs
Critical clinical workflows, the peak you plan for, integrations, constraints and your decision deadline, on a 30-minute call within one business day of your request.
Who connects and how, where the test data comes from, what telemetry is available and which outside systems get an emulator. The standard engagement is designed to run without production access or live patient data.
User mix, arrival rate, shift-change bursts and batch windows, built from your analytics and your clinical experts' knowledge of a real day, then approved by your team.
Our engineers write the scripts, build data generators and emulators for the outside systems, and run a baseline to confirm the package behaves on your test environment.
We run the agreed load, stress, soak or spike scenarios and line the results up with system telemetry, so each bottleneck comes with evidence you can reproduce.
One re-run of the approved workload after your fix, because the first run produces the list of limits and the second produces a number you can trust.
One Documented Clinic-Network Engagement
All three figures come from one load testing engagement for a network of clinics, hospitals and diagnostic centers. The client is confidential.
One load testing engagement and one test automation engagement, both published
A clinic network planned new architecture under its medical information system. PFLB tested the thick client over RDP on an anonymized copy of the production database, reported the limits, repeated the test after the fixes and returned the server count.
Read full case
Test automation rather than load testing, in a regulated lab: nightly runs caught a performance decrease after database changes, and the client used PFLB's reports as supporting documents for yearly US Department of Health and Human Services certification.
Read full case
The questions a security review raises first, answered on this page so the call can focus on your system.
Named PFLB engineers in the US, the UK and Iceland connect to your test environment by VPN or bastion host, under a mutual NDA and an MSA with a security exhibit.
Synthetic records built for the load profile, or your data anonymized first. The clinic-network engagement ran on an anonymized copy of the production database.
PFLB has a SOC 2 Type II report, shared under NDA on request.
Tell us which system you need to test and what peak you plan for. A performance engineer answers within one business day and you agree a time for the call.
It models how clinicians, patients and connected systems use the application, generates that load on a test environment and measures where response time, errors and availability start to fail. PFLB names each bottleneck with evidence, hands your team the priorities and re-runs the same workload after the fix. Since 2008, 150+ PFLB engineers have run performance testing for 300+ companies, including a clinic network whose medical information system was sized for 3,000 users.
For healthcare providers, a slow system delays care, not only a transaction. Clinicians need quick access to patient histories and lab results. Performance testing ensures the expected load has been measured before patients depend on it. It does not replace functional or clinical validation, which is a separate part of healthcare software testing.
Load testing simulates expected traffic under real world conditions. Stress testing exceeds expected volumes to find the breaking point. Spike testing shows what a sudden surge does. Endurance testing runs a sustained load to find memory leaks and slow decay. Scalability testing shows how capacity grows when you add users, facilities or cloud resources, so cloud scalability is measured rather than assumed. The written scope states which of these your system needs.
The key performance indicators are response time per workflow at p95 and p99, throughput, error rate, system availability and server saturation in the same run. There is no single universal target: opening a chart and an overnight claims batch need different limits. Your clinical and IT owners approve the pass and fail criteria before the first run, so faster response times are judged against numbers agreed in advance.
Through terminal sessions rather than HTTP. In the clinic-network engagement, the main load was user activity over RDP on terminal servers running the thick client. Scripts mimicked the most important user operations, LoadRunner generated the load, profiles came from the customer's expert evaluation data, and the deliverable was the number of terminal servers for the maximum load. That is hardware sizing as an engineering result.
The test runs on synthetic records built for the load profile, or on an anonymized copy of your production database. A copy keeps the real data volume and distribution, which is what drives response time in patient records, while removing patient identity. Our test data management team builds generators when the data must satisfy clinical constraints. When a project could touch patient data, we raise it early and agree the handling in writing before the contract.
Yes, as written scope, and PFLB has no published healthcare case on these interfaces yet. FHIR is an HTTP API and HL7 v2 is usually message traffic over TCP, so the method matches what we built for a bank's card-processing migration: an in-house ISO 8583 emulator plus emulators of external systems over JDBC and SOAP. Emulating labs and payers means the test never touches a live partner.
Device bench and safety testing are outside this service. Where medical devices send data to a server, we can load test that server side, including the interfaces and databases that receive it. Device verification stays with your regulatory and engineering teams.
Before every major release, architecture change, new facility rollout or known seasonal peak. Teams that ship often gain most from continuous testing inside the development cycle: the LIMS client releases every 2 to 3 weeks and its autotests run every night. Scripts are delivered to your repository, and continuous monitoring after go-live catches what the test did not model. Your team can also run its own tests on the PFLB Platform.
Ask for a published case on a system like yours, a sample report, and how the vendor will model real world scenarios rather than a flat user count. Ask what data the test runs on, who gets access, and whether the scope includes a re-run after your fix. Ask for an independent security attestation: PFLB's is a SOC 2 Type II report, available under NDA. A good vendor also tells you what it has not done.
Because that is the published evidence. The medical information system engagement is a direct load testing case, and the LIMS case is test automation in a regulated lab. The areas under "What We Test" describe possible scope; the written proposal fixes what each engagement covers. Other high-load work is on the cases page, including banking systems with similar availability demands and integration depth.
