Data Flow Analysis vs. Threat Modeling in Healthcare

If you only map ePHI, you know where it goes. If you only model threats, you may miss where it goes. You need both.

I’d sum it up like this:

• Data flow analysis shows where ePHI is stored, processed, and sent
• Threat modeling shows how those paths could be attacked, misused, or broken
• In healthcare, this matters because breaches and downtime hit both data and patient care
• In 2025, OCR reported 772 large healthcare breaches, affecting about 139,721,832 people
• Ransomware disrupted care in 44.4% of documented cases, with downtime costs estimated at $1.9 million per day

So if I’m reviewing a new app, device, API, or vendor, I’d use a simple rule: map the data first, then test the map for risk.

Quick Comparison

Here’s the plain-English takeaway: a DFD is the map, not the answer. I’d use it to trace EHR data, device feeds, cloud APIs, imaging systems, and vendor handoffs. Then I’d run threat modeling to check spoofing, tampering, disclosure, denial of service, and privilege misuse across those same paths.

That’s the core decision this article helps answer.

sbb-itb-535baee

Data Flow Analysis in Healthcare Applications

Data flow analysis maps how ePHI and related clinical data move through applications, APIs, databases, devices, and third-party connections. It gives teams the map. Threat modeling stress-tests that map. In plain English, this means writing down every component that touches ePHI and every handoff between those components.

What Data Flow Analysis Maps and Documents

A healthcare DFD shows external entities, processes, data stores, data flows, and trust boundaries - things like patients, vendors, EHR modules, APIs, databases, and mobile caches. An interface labeled "HL7 v2 ADT message" gives a security team something concrete to work with. The same goes for "FHIR R4 REST API using OAuth 2.0 / SMART on FHIR access control." FHIR guidance also calls for secure in-transit exchange using TLS 1.2 or newer ^[3].

Trust boundaries matter a lot here. These are the points where data moves from one admin or security domain to another, like from a hospital network to a cloud SaaS vendor. If those boundaries are clearly marked, security teams can spot control handoffs right away. This visibility is essential to transform healthcare third-party risk management from a manual exercise into a scalable process. The diagram becomes far more useful when it reflects actual clinical workflows instead of a neat-but-empty system sketch.

Healthcare-Specific Use Cases

Data flow analysis works best when teams trace ePHI through end-to-end clinical workflows. In an EHR setting, that means following a patient record from registration through ordering, results, coding, and billing. Each step touches a different system and often requires managing third-party risk across multiple vendors. The data may move through HL7 v2 interfaces, internal database calls, FHIR APIs, or SFTP feeds.

Imaging environments often get missed in app-focused reviews because biomedical engineering teams or niche vendors run them instead of core IT. A DFD for imaging should trace DICOM data from the acquisition modality through the PACS/VNA archive to diagnostic viewers and any AI diagnostic tools that process those images ^[2].

For IoMT, the map should follow clinical parameters from bedside devices - such as infusion pumps and patient monitors - through local device networks and gateways into central systems that feed the EHR or alarm management platforms. That map is a big step forward, but it still doesn't answer the security side of the story.

What Data Flow Analysis Does Not Answer on Its Own

A DFD shows where data goes and where boundaries sit. What it does not show is how an attacker might use those paths, whether controls hold up, or which crossings deserve the most attention. For example, a diagram may show that a FHIR API uses TLS. But it won't tell you if TLS is set up the right way, if certificate handling is solid, or if the app layer has access controls that do any real work.

Data flow analysis is also static by nature. It captures a point-in-time view of system connections, not the moving parts that show up after deployment - like credential theft, lateral movement, or cloud misconfiguration. That's where threat modeling comes in. It starts with the map and asks what could break, what could be misused, and what an attacker would go after next.

Threat Modeling in Healthcare Security

Data flow analysis gives you the map. Threat modeling takes the next step and asks: who could attack this, how would they do it, and what happens if they get in? It helps teams spot likely points of failure, judge the damage, and connect each risk to a control.

In healthcare, that work goes beyond confidentiality, integrity, and availability. It also has to account for patient safety, not just data protection, but care delivery. That’s the big difference. A security failure here doesn’t just expose records. It can delay treatment, interrupt systems, or affect clinical decisions. The next move is to pressure-test that map against attack paths that could happen in practice.

Recent healthcare ransomware has caused record losses, long downtime, and patient-safety risk ^[1][6].

How the Threat Modeling Process Works

Teams usually begin with security and safety goals: protect PHI, keep systems up, and avoid disruption to care. From there, they model the system with architecture diagrams and data flow maps. Once that picture is in place, they use a framework to sort threats in a structured way.

A common choice is STRIDE:

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

CMS's handbook maps STRIDE to DFD elements and guides impact and likelihood scoring ^[8]. For privacy-focused risks, such as linkability between patient records or policy noncompliance, LINDDUN adds another lens ^[7][9].

After that, the team ranks threats by likelihood and impact, then ties them to mitigations. That can include multifactor authentication for remote access, encryption in transit and at rest, network segmentation to limit lateral movement, least-privilege permissions, and logging to support detection and response. In healthcare, those controls also need to work in the middle of clinical use. If a safeguard slows care or creates friction at the wrong moment, that tradeoff matters.

This is why threat modeling depends on a solid map but does more than document the system. It turns the map into a set of risk decisions.

Healthcare Scenarios Where Threat Modeling Adds Value

Threat modeling pays off most in settings with messy trust boundaries and several ways an attacker could move through the system. Healthcare has a lot of those.

Telehealth platforms bring identity-spoofing risk. An attacker might pose as a clinician or patient to get into video visits or related records. When STRIDE is applied to the authentication flow, that kind of gap tends to show up fast.

EHR integrations bring tampering risk when lab results or medication orders move between vendor systems. Threat modeling helps teams ask a plain but important question: if data changes in transit or at rest, would any control catch it?

Cloud-hosted clinical tools can expose PHI through information disclosure, especially when data sits in shared environments or moves through third-party APIs. That forces teams to pin down who can access the data, when they can access it, and whether logs would show misuse.

Connected medical devices carry the most direct patient-safety impact. FDA guidance recommends doing cybersecurity risk assessment and threat modeling throughout the device design process and including threat modeling documentation in premarket submissions ^[4][5]. For devices such as infusion pumps or remote monitoring systems, threat modeling can surface risk in remote maintenance channels, weak segmentation, or unsafe assumptions about trusted internal traffic.

The pattern stays the same in each case: map the system first, then test that map for abuse paths.

Data Flow Analysis vs. Threat Modeling: Key Differences and Overlap

Different Goals, Inputs, and Outputs

Data flow analysis shows where PHI goes. Threat modeling takes that same map and checks how it could be abused and what to do about it. Put simply: one tracks movement, the other checks risk.

Where the Two Methods Overlap in Practice

Both methods start from the same place: the DFD.

In day-to-day healthcare work, threat modeling usually begins with the same diagram used in data flow analysis. That DFD traces the PHI path across EHR systems, lab orders, vendor connections, medical devices, and APIs. Threat modeling then pressure-tests that path for leakage, tampering, and other attack routes.

This matters most anywhere PHI handling touches API calls or third-party vendor relationships. Once the map is in place, teams can ask STRIDE-style questions like:

• Where could PHI leak?
• Where could data be changed without anyone noticing?
• Could a vendor SFTP feed to billing be tampered with?

If the data flow analysis misses something, the threat model will miss it too. That could mean undocumented apps, hidden connections, an undocumented vendor connection, or a device-to-cloud data flow. In plain terms, STRIDE-style analysis is only as good as the DFD underneath it.

Common Misconceptions to Avoid

A common mistake is treating a DFD like a finished threat model. A diagram is the foundation, not the threat model. Teams still need to do the hard part: list threats, sort them, score likelihood and impact, and choose controls.

The reverse mistake is just as risky: running STRIDE or a similar review without a solid data flow diagram first. In healthcare, that gap can leave blind spots in places that matter most. Device-to-cloud data flows, vendor-managed integrations, and PHI transfers between organizations are easy to miss when the underlying map is weak. A DFD by itself doesn't go far enough, but threat modeling without a DFD skips paths that should have been checked.

How to Use Both Methods Together in Healthcare Risk Management

Once you have the map and the threat list, the next move is to use both methods in one shared workflow.

A Practical Workflow for HDOs and Vendor-Connected Environments

Start with a complete inventory of every application, database, medical device, vendor integration, and API that stores, processes, or transmits PHI. Then build Level 0 and Level 1 DFDs that show entities, processes, data stores, flow direction, protocol, and sensitivity. Mark trust boundaries anywhere PHI moves from one security domain to another.

After the DFD is done and reviewed, apply STRIDE to each DFD element. Score each threat by looking at technical severity, likelihood, and clinical impact together. For every threat, document the attack scenario, the mapped control, and the residual-risk status.

From there, feed threat registers, risk ratings, and mitigation plans into secure development reviews, change management, and the enterprise risk register. Update the DFDs and the threat model any time a new vendor integration, device, or application comes into the mix.

How Teams Should Divide Responsibilities

This only works when ownership is crystal clear. Each team needs a defined part in the same assessment cycle.

A clear RACI tied to business owners, not just IT, keeps accountability clear across vendor-connected environments.

Where Censinet Fits

After the assessment, teams need one place to track what they found and what happens next. Censinet RiskOps™ gives HDOs a central place to track and act on findings from data flow analysis and threat modeling across applications, devices, vendors, and enterprise risk.

Conclusion: When Each Method Matters Most

After looking at scope, overlap, and use cases, the day-to-day choice is pretty simple. Data flow analysis shows where PHI goes and where trust boundaries sit. Threat modeling pressure-tests those paths for attack, misuse, and failure. One shows the route. The other checks the risk.

When you use both, a data map turns into a ranked mitigation plan. A detailed flow map can expose missed links, like an undocumented SFTP feed to a billing vendor. Threat modeling then turns that gap into a specific attack scenario. In practice, that’s how a diagram becomes something a team can act on.

Both methods support HIPAA Security Rule risk analysis under 45 C.F.R. §164.308(a)(1)(ii)(A). ^[10][11] But neither one, by itself, covers the whole job. Together, they do.

The Short Decision Rule

Use this rule when a new app, integration, or vendor enters the environment:

• Use data flow analysis when you need to see where PHI is stored, how it moves across systems, how third-party risk is managed, and where trust boundaries exist.
• Use threat modeling when you need to see how those systems and flows could be attacked, which scenarios carry the most risk, and which controls need to be added or tightened.

Take a new remote patient monitoring platform. Start by mapping device-to-cloud links, EHR integration, and APIs. Then use threat modeling to test the exposed paths: look at ransomware aimed at back-end databases, API abuse, and stolen vendor credentials, then assign mitigations that protect patient safety and continuity of care.

Skip data flow analysis, and your threat model rests on missing facts. Skip threat modeling, and your data map stays just a map instead of becoming a ranked mitigation plan.

In healthcare, the first question is where the data goes. The next one is what could happen there.

FAQs

Can I do threat modeling without a DFD?

Technically, yes - for a high-level assessment.

But in healthcare, Data Flow Diagrams (DFDs) are generally a must for threat modeling that works in practice.

They show how PHI moves through systems. Just as important, they highlight trust boundaries - those points where data crosses from one security zone to another.

Without a DFD, it’s easy to miss vulnerabilities. You can also overlook risks tied to clinical workflows, which is where a lot of the trouble tends to hide.

How often should healthcare teams update DFDs and threat models?

Healthcare teams should treat Data Flow Diagrams (DFDs) and threat models as living artifacts, not one-and-done paperwork.

They need updates any time the system changes in a way that affects risk. That includes shifts in system architecture, clinical features, data types, trust boundaries, or device configurations.

Regular reviews help too. In many cases, a quarterly review makes sense. It gives teams a chance to deal with new threats, newly disclosed vulnerabilities, regulatory changes, and shifts in the environment of use before those issues pile up.

Which teams should own data flow analysis and threat modeling?

Data flow analysis and threat modeling should be owned through a cross-functional effort that brings together IT, cybersecurity, engineering, clinical, and regulatory teams.

Manufacturers carry primary responsibility across the medical device lifecycle. But in practice, solid ownership depends on shared input. Cybersecurity and engineering teams need to work closely with clinical specialists so risk scoring reflects patient safety, not just technical severity. In healthcare delivery organizations, oversight often sits with vendor risk committees.

Related Blog Posts

• Best Practices for Threat Modeling in Healthcare IT
• STRIDE Framework for Healthcare IT Threat Modeling
• How STRIDE Enhances Medical Software Security
• Risk Assessment in Healthcare Threat Modeling