Patient flow analytics platforms occupy an interesting position in the HIPAA landscape: they process real-time patient location and encounter data that is unambiguously PHI, but the clinical operations teams using that data often haven't engaged IT security in the same way they would for an EHR implementation or a billing system. This creates compliance exposure that is worth understanding before procurement.
What PHI Is Actually Present in Patient Flow Data
The HIPAA Privacy Rule defines protected health information (PHI) as individually identifiable health information that relates to a person's past, present, or future physical or mental health or condition, the provision of health care, or payment for care — and that is transmitted or maintained in any form. Patient flow data streams contain PHI across multiple categories that meet this definition.
At minimum, a patient flow analytics platform processing real-time ADT feeds from your EHR will handle: patient name (from encounter registration), date of birth (from the encounter record), the fact of a current hospital encounter and its location (bed assignment), timestamps of clinical events (arrival, triage, admission, discharge), and diagnosis-related codes or flags if the ADT message includes clinical detail. The HL7 ADT A01 admit message, for example, includes PID (patient identification) and PV1 (patient visit) segments that contain name, date of birth, visit type, assigned location, and attending provider identifiers. This is PHI in the HIPAA sense — there is no question.
The PHI scope in a flow analytics platform is narrower than in a clinical documentation system or an HIE, but it is real and legally significant. Any vendor that receives, accesses, creates, or maintains PHI on behalf of your organization is a business associate under 45 CFR Part 160 and Part 164, and is required to sign a Business Associate Agreement (BAA) before receiving that data.
BAA Requirements: Non-Negotiable Baseline
A BAA is not a courtesy or a risk-transfer formality — it is a legal requirement for any relationship in which a third-party vendor receives or accesses PHI on behalf of a covered entity. Under the HIPAA Security Rule, covered entities are required to obtain satisfactory assurances from business associates that the business associate will appropriately safeguard PHI, documented in writing through a BAA that meets the regulatory requirements of 45 CFR §164.308(b) and §164.504(e).
For patient flow analytics vendors, the BAA should address: permitted uses and disclosures of PHI (patient flow operations, clinical analytics for the covered entity — not resale or secondary use); security safeguards the vendor will maintain; breach notification obligations; the requirement to return or destroy PHI at contract termination; and the vendor's agreement to comply with applicable portions of the HIPAA Security Rule in their handling of ePHI.
We're not saying that a BAA alone constitutes sufficient vendor security diligence — it doesn't. But we are saying that any patient flow analytics vendor that cannot or will not execute a BAA before accessing your ADT or FHIR data should not receive that data under any circumstances, regardless of their security posture claims. BAA execution is the legal floor, not the ceiling.
HIPAA Security Rule: The Three Safeguard Categories
The HIPAA Security Rule at 45 CFR Part 164 requires covered entities and their business associates to implement safeguards across three categories to protect electronic PHI (ePHI). Understanding these categories helps hospital IT teams evaluate vendor security claims with appropriate specificity.
Administrative safeguards include security management processes (risk analysis, risk management), workforce training, and contingency planning. For a patient flow analytics vendor, administrative safeguard questions include: Has the vendor conducted a documented HIPAA risk analysis of their platform? Do they have a security incident response procedure? How is PHI access provisioned and deprovisioned for their employees?
Technical safeguards include access controls, audit controls, integrity verification, and transmission security. For a flow analytics platform receiving ADT feeds or FHIR R4 data, relevant technical questions include: Is data encrypted in transit (TLS 1.2 minimum, TLS 1.3 preferred)? Is data encrypted at rest? Does the platform maintain audit logs of data access at the record level? Is access controlled through role-based permissions that limit which users can see which patient location data?
Physical safeguards address the physical security of systems processing ePHI — data center access controls, workstation security, media disposal. For a cloud-hosted SaaS platform, these questions translate to: Which cloud infrastructure provider is used? Is that infrastructure at minimum SOC 2 audited? What data residency commitments are in place for data at rest?
Mediflowly is designed with HIPAA Security Rule administrative, technical, and physical safeguards in mind, and BAA execution is standard for all health system customers. We support your HIPAA program rather than creating a parallel compliance obligation you have to manage separately.
De-Identification: When and Whether It Helps
Some patient flow analytics use cases can be served with de-identified data, and de-identification removes the PHI designation, eliminating HIPAA obligations for that data set. HIPAA provides two methods for de-identification under 45 CFR §164.514:
The Safe Harbor method requires removal of 18 specific categories of identifiers, including name, geographic data smaller than state level, dates (other than year) related to individuals, and several others. For patient flow analytics, Safe Harbor de-identification is difficult to achieve while retaining operational utility because operational flow data depends on specific dates and times (the timestamp of an ED arrival is an individually-associated date) and on bed location specificity that falls below the state-level geographic threshold.
The Expert Determination method allows a statistician to certify that remaining identifiers have a very small risk of re-identification. This method is more flexible but requires documented expert analysis. Epic's Cosmos de-identified research platform uses an Expert Determination approach for population-level research queries, but that use case is distinct from real-time operational analytics where you need current, non-anonymized encounter data to manage live patient flow.
The practical implication for most patient flow analytics implementations is that de-identification is not a useful simplification strategy for real-time operational use cases — you need identified PHI to manage live census and make real-time bed placement decisions. The appropriate framework is a properly executed BAA with a vendor whose security architecture is designed with HIPAA safeguards in mind, not an attempt to de-identify data before it reaches the analytics platform.
Vendor Evaluation Checklist for Hospital IT Teams
Based on the HIPAA framework above, an IT or CISO-level evaluation of a patient flow analytics vendor should include at minimum:
- BAA availability: Does the vendor offer and execute a BAA before data access? Can the BAA be reviewed and negotiated by your legal team?
- Risk analysis documentation: Has the vendor conducted a formal HIPAA Security Rule risk analysis? Can they provide a summary or attestation?
- Data handling practices: Where is PHI stored? What data residency commitments are in place? Is PHI used for purposes beyond operational analytics (e.g., model training, aggregated benchmarking)?
- Breach notification procedure: What is the vendor's breach detection and notification process? What is the timeline for notifying the covered entity in the event of a discovered breach?
- Subcontractor chain: Does the vendor use subcontractors who access PHI (e.g., a cloud hosting provider with data access, a third-party monitoring service)? Are subcontractor BAAs in place?
- Data deletion at termination: What is the process and timeline for PHI return or destruction when the contract ends?
These questions should be answered before any PHI flows to a vendor — before a pilot, before a proof of concept, before a demo using live patient data. A vendor that is well-prepared for these questions will have documented answers. One that pushes back or deflects should not receive PHI access until they can provide substantive responses.
Practical Guidance for the Procurement Process
At Mediflowly, we treat HIPAA security and BAA execution as preconditions to any data integration — not as an afterthought in the contract process. We're happy to provide our security documentation and BAA template for review by your IT security and legal teams before any commitment. If you want to understand our data architecture in the context of your specific EHR integration environment, reach out to request a technical conversation with our implementation team.