Map PHI Paths Before Exposing Healthcare AI

Define PHI, ePHI, and the scope of the review

Before drawing a network diagram, define what the team means by protected health information. Under the HIPAA Privacy Rule, PHI is individually identifiable health information held or transmitted by a covered entity or its business associate, in any form or medium, subject to the rule's exclusions. Electronic protected health information, commonly abbreviated as ePHI, is PHI transmitted by or maintained in electronic media. This distinction matters because a healthcare AI data-path map usually focuses on electronic systems and therefore on potential ePHI.

Not every piece of health-related data is automatically PHI under HIPAA. Applicability depends on facts such as who creates, receives, maintains, or transmits the information, the role of each party, the activity being performed, and whether an exclusion applies. A developer should not decide that HIPAA applies or does not apply merely from the presence of a diagnosis, patient-like record, or healthcare customer. The responsible privacy and legal teams should evaluate the parties, data, purpose, and contractual relationships.

The U.S. Department of Health and Human Services provides an overview of the HIPAA Privacy Rule and protected health information. Use that guidance with your organization's counsel and privacy program rather than treating this tutorial as a legal classification.

HIPAA applicability is about relationships and activities

A data-flow review should identify whether each organization is acting as a covered entity, business associate, subcontractor, or in another capacity relevant to the workflow. The answer can affect contractual and operational requirements. HHS explains business-associate relationships and written arrangements in its business associate guidance. A diagram cannot settle that legal analysis, but it can reveal every party that needs to be evaluated.

Do not limit the party inventory to the obvious AI provider. Include relay services, cloud storage, observability platforms, identity providers, support tools, notification systems, backup destinations, model APIs, and vendors receiving error reports. A processor that sees only failed requests, logs, or encrypted records may still require analysis based on the actual arrangement and its access to information.

Use the recognized HIPAA de-identification methods

The HIPAA Privacy Rule describes two methods for de-identifying PHI: Safe Harbor and Expert Determination. HHS explains both in its de-identification guidance.

• Safe Harbor: the specified identifiers concerning the individual and certain related persons must be removed, and the covered entity must not have actual knowledge that the remaining information could identify the individual.
• Expert Determination: a person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods determines that the risk is very small that the information could be used, alone or with other reasonably available information, to identify an individual. The methods and results must be documented.

“Engineering approval,” removal of names, tokenization, masking, or a team member's informal judgment is not a third HIPAA de-identification method. Those techniques can be parts of a broader process, but the organization should record whether Safe Harbor or Expert Determination is being used and preserve the required evidence.

De-identification also does not answer every security question. A dataset may remain confidential, commercially sensitive, contractually restricted, or vulnerable to model memorization and linkage. Free text, medical images, filenames, dates, geographic details, device identifiers, and metadata deserve particular attention.

Connect the map to Security Rule risk analysis

HHS describes risk analysis as foundational to Security Rule compliance and explains that organizations should identify where ePHI is stored, received, maintained, or transmitted, identify threats and vulnerabilities, assess current security measures, determine likelihood and impact, assign risk levels, and document the analysis. See the HHS Security Rule risk-analysis guidance.

The data-path map supports that work by making assets, flows, actors, storage points, trust boundaries, and dependencies visible. It is not a complete risk analysis by itself. Organizations still need to evaluate threats, vulnerabilities, existing controls, likelihood, impact, risk disposition, and ongoing review.

For implementation-oriented guidance, consult NIST Special Publication 800-66 Revision 2, which provides guidance for implementing the HIPAA Security Rule. NIST guidance helps organizations translate regulatory requirements into a security program, but it does not replace HHS rules, organizational counsel, or a workflow-specific assessment.

Why healthcare AI connectivity starts with a data-path map

Teams often begin with a narrow question such as, “How can a remote developer reach this local AI API?” That question matters, but it arrives too late in the architecture process. Before selecting a tunnel or private network, the team needs to know what the endpoint receives, what it returns, which dependencies it contacts, what it records, who can reach it, and what happens when something fails.

A model-facing API can appear harmless in isolation. Its request may include patient identifiers, clinical notes, images, laboratory results, appointment details, audio, or other sensitive information. Its response may reproduce source material, generate a clinical summary, reveal retrieved records, or include debugging details. Headers, URLs, filenames, traces, callback payloads, and timing data can also disclose information.

The useful unit of analysis is the complete transaction path. It begins with the initiating person or system and continues through the public endpoint, relay, Localtonet client, target application, retrieval components, model runtime, data stores, observability tools, administrative interfaces, outbound integrations, and retention systems. Every change in system, network, identity, organization, or operational ownership should be visible.

This work must happen before an endpoint is made remotely reachable. A network path increases accessibility, but it does not establish permission to process data. It also does not provide the complete set of contractual, administrative, physical, and technical safeguards a regulated deployment may require.

Build an endpoint inventory and reusable mapping register

Start with a system diagram, but do not stop at boxes and arrows. Every arrow should become a register entry with a business purpose, owner, approval state, and shutdown condition. If the team cannot explain what crosses a connection and why it is necessary, that path is not ready for remote exposure.

Separate interfaces by purpose

A prediction API is not equivalent to an administrative dashboard. A callback receiver is not equivalent to a detailed health endpoint. A model service processing synthetic cases is not equivalent to a retrieval component connected to live clinical records.

Document interfaces separately even when they share one process or port. If the application cannot separate them technically, record that coupling as a risk. Exposing one listener can make every route on that listener reachable through the same network path.

Use a mapping register that supports approval and shutdown

The register should be detailed enough for a reviewer to reconstruct the flow without guessing. Use one row for each distinct transfer. Split a flow when its data, caller, authorization, processor, storage, or retention behavior changes.

Record normal, error, and administrative paths

Include what happens when the model times out, a database rejects a query, a callback fails, or an integration returns malformed data. Error handlers may send payload fragments to logs or external monitoring tools. Retries can duplicate messages. Dead-letter queues and temporary directories may preserve data longer than the primary workflow.

Record derivative data such as embeddings, summaries, labels, thumbnails, extracted entities, cached responses, and search indexes. A changed representation is not automatically non-sensitive or de-identified. Whether a derivative can be linked to an individual depends on its content, surrounding information, and reasonably available data.

Mark trust, transport, encryption, and retention boundaries

A trust boundary exists wherever assumptions about control, identity, data handling, or accountability change. The boundary may be technical, organizational, or operational. Mark it directly on the diagram and reference the relevant mapping-register rows.

Represent the Localtonet path explicitly

For a public tunnel, draw the complete sequence rather than one generic “internet” arrow:

1. The remote caller and its identity or lack of identity.
2. The assigned public URL or public host and port.
3. The Localtonet relay selected from currently available product options.
4. The outbound connection established by the Localtonet client.
5. The client device and its device-specific authentication token.
6. The configured local IP address and port.
7. The target healthcare AI application and all routes on its listener.
8. Downstream model runtimes, databases, retrieval systems, identity services, and vendor APIs.
9. Logs, traces, queues, backups, alerting systems, and other retention destinations.

Annotate each segment with only the protection that has been verified. Localtonet HTTP and File Server process types serve content at a public HTTPS address, and File Server documentation states that TLS is terminated at the tunnel edge. That product-specific fact must not be generalized into an unsupported claim that every hop of every tunnel type provides end-to-end application encryption. Record where TLS terminates, how traffic continues to the local target, and whether the application adds its own verified transport protection.

Evaluate authorization separately from transport

Reachability, encryption, authentication, and authorization solve different problems. A protected transport does not decide which patient records a caller may access. A login does not prove that a user may invoke every route. A private mesh does not authorize every participant to use every reachable service.

For each endpoint, record how callers authenticate, whether identities are individual or shared, how authorization limits operations and records, how credentials are stored and rotated, and how access is removed. Apply least privilege at both the network and application layers when the architecture supports it.

Choose between local-only, private mesh, and public access

Assign an exposure scope only after the inventory is complete. The safe default for an unreviewed interface is local-only. Remote reachability should exist because a documented user or integration needs it, not simply because it is convenient.

Keep unresolved and administrative interfaces local

Keep an endpoint local when its data classification is unresolved, remote access has no documented requirement, authentication is absent, administrative and user routes cannot be separated, or the team cannot explain its logs and dependencies. Local-only is also appropriate during early development while security behavior changes frequently.

Use private mesh access for a controlled device audience

Localtonet VPN Manager provides a free private mesh VPN with granular firewall rules and can bridge local LANs. It may fit a workflow where known devices or networks need private connectivity and arbitrary internet clients do not need to initiate requests.

Private mesh access still requires an explicit design. Define participants, destinations, permitted ports, application authorization, administrative ownership, offboarding, and firewall rules. Standard HTTP, TCP, UDP, combined UDP/TCP, TLS, and File Server tunnels are not VPN functionality. VPN Manager is our private mesh feature.

Use public access only for a reviewed public requirement

A public HTTP tunnel may fit a reviewed development API, demonstration, callback receiver, or web application that must receive internet-originated traffic. Begin with synthetic data or data de-identified through a documented Safe Harbor or Expert Determination process. The application still needs suitable authentication, authorization, validation, safe error handling, and data minimization.

Select a raw TCP, UDP, combined UDP/TCP, or TLS tunnel only when the application protocol requires it. Do not assume HTTP-layer protections exist for a raw port. Before exposing a database, message broker, model runtime, vector store, or management protocol directly, consider whether a narrow application API can provide the required operation with less access.

Worked example: remote review of an AI summarization API

Consider a local AI service that summarizes clinical notes for a developer demonstration. It exposes an inference route, an administration page, API documentation, and a health route on one local listener. The model uses a local runtime, while application logs record request bodies for debugging.

The initial request is to let a remote product reviewer test the service. The example below deliberately uses synthetic records. It does not authorize ePHI and does not claim that the architecture is appropriate for production.

Decision for the example

The first decision is local-only because the inference, administration, documentation, and health routes share one listener, and request-body logging creates an unnecessary copy. The team separates the demonstration API onto a dedicated listener, removes payload logging from the approved path, verifies authentication and authorization, and tests with synthetic records.

After those changes, the team considers the audience. If the reviewer can join an approved set of private devices, a private-mesh design may provide the narrower network scope. If the reviewer cannot join that mesh and public HTTPS access is a documented requirement, a public HTTP tunnel may be approved for the dedicated demonstration listener.

The decision record states that production records and ePHI are prohibited. A future request to connect an electronic health record, use real clinical notes, add an external model provider, or enable payload logging triggers a new risk, privacy, contract, and architecture review. The synthetic demonstration approval cannot be reused for that expanded workflow.

Run a pre-exposure healthcare AI review

This workflow is an architecture and risk-review aid, not a regulatory validation. Adapt approvals and evidence requirements to your organization.

Map Localtonet only after selecting the access model

With Localtonet, the client runs on a device that can reach the selected local service. It establishes an outbound connection to a Localtonet relay, so inbound router port forwarding, firewall changes, a public IP address, or separate VPN setup are not required for a standard tunnel. Depending on the tunnel type, the result is a public URL or a public host and port.

This solves a connectivity problem. It does not decide whether an endpoint should be public, whether ePHI may cross it, whether the application's authorization is sufficient, whether contracts are required, or whether the complete workflow meets healthcare obligations.

Public HTTP access for a reviewed web endpoint

For an approved public web service, an HTTP tunnel points to the reviewed local IP address and port. HTTP tunnels support Random Sub Domain, Custom Sub Domain, and Custom Domain process types, all serving content at a public HTTPS address. Check current documentation before configuring custom-domain DNS because exact requirements are not established here.

Ensure the target listener contains only the routes intended for the public audience. If inference, administration, debugging, metrics, and documentation share a listener, separate them before exposure.

Private access through VPN Manager

When the intended audience is a controlled set of devices or connected LANs, VPN Manager may be the better design. It provides a private mesh VPN with granular firewall rules and can bridge local LANs. Application authentication and authorization remain necessary.

High-level Localtonet tunnel lifecycle

The following is a conceptual lifecycle common to standard tunnels, not an exact protocol-specific dashboard procedure. Fields differ by tunnel family and current product version. Use the current Localtonet documentation for the chosen protocol and obtain server or region values from the dashboard rather than copying old values.

Protocols, options, relay regions, and capabilities can vary by plan, client version, or current product availability. Confirm those details before a production change.

Verify, troubleshoot, and stop on unexpected behavior

Verification must prove both connectivity and containment. A successful response confirms only that a path exists. The important question is whether the path exposes exactly what was approved and rejects every unauthorized or out-of-scope request.

Verify the local target before starting remote access

Test from the Localtonet client device. Confirm that the configured local IP address and port respond, the expected application version is running, and the listener contains only approved routes. Exercise successful and denied requests with synthetic data. Inspect responses, application output, logs, traces, caches, queues, temporary files, and downstream calls.

Verify from the intended remote audience

Start the approved tunnel or private-mesh path and test from a representative remote device. Confirm the expected protocol and endpoint. Test missing identity, invalid credentials, insufficient permission, malformed input, unsupported methods, missing headers, and invalid callback signatures where relevant.

Enumerate reachable routes rather than checking only the intended path. Confirm that administration, framework diagnostics, API documentation, file browsers, metrics, detailed health information, and unrelated virtual hosts are not reachable. For raw-port access, verify that the selected port belongs to the expected service.

Use explicit pass and stop conditions

Operate the approved path without expanding its scope

Treat the map and register as operational records, not one-time design artifacts. An approved endpoint can become unsafe when its application, data, audience, model, or dependencies change.

Assign ownership, expiry, and re-review triggers

Assign an owner to every tunnel, private-mesh rule, public endpoint, application credential, log destination, and vendor integration. Record why it exists and when it expires or must be reviewed. Stop or delete temporary access when the demonstration, test, or integration ends.

Re-run the review when a service adds routes, accepts new files, starts processing production data, connects to a clinical system, changes model providers, introduces retrieval or tools, adds monitoring, or moves between environments. A synthetic-data demonstration approval must not silently become authorization for live clinical use.

Plan investigation and shutdown

Define who can stop the tunnel, disable application credentials, isolate the host, preserve evidence, contact vendors, and notify internal responders. Shutdown criteria should include unexpected ePHI, unapproved callers, unknown destinations, exposed administrative routes, failed authorization, unresolved encryption boundaries, or behavior outside the approved register.

Localtonet provides platform-wide Token/Tunnel webhooks that report Connected or Disconnected changes for a token or tunnel in a selected Token Group. The request contains an identifier, action date, type, and status. These connection-state events are distinct from File Server file-event webhooks and must not be presented as healthcare audit logs, request logs, or records of patient-data access.

Frequently asked questions