HIPAA work has to be designed like an operating environment, not a demo.

When a workflow touches PHI, we scope the boundary, choose the deployment path, and build the controls around it: local air-gapped infrastructure, AWS HIPAA-eligible services under the right agreements, or a defined split between the two. We already do this for Dexzyle and Taliswitch.

Request a workflow review See the deployment paths

Start with where PHI lives

Before any AI or automation, we define where PHI lives, who can access it, which vendors are in scope, what gets logged, how documents move, and where human review happens.

Scope the boundary first

What data is in scope, which systems touch it, and whether the workflow can be isolated, de-identified, or fully contained.

Make the workflow auditable

Access control, encryption, audit logs, retention rules, exception handling, and review queues matter more than a polished interface.

Treat compliance as an operating model

HIPAA readiness lives in agreements, architecture, user permissions, incident process, and document handling discipline, not in a generic secure-AI claim.

Deployment paths

The right answer depends on who owns the infrastructure, how strict the PHI boundary is, and whether outside services are allowed at all.

Local or air-gapped

Document handling, indexing, search, and processing stay inside a local or isolated network. Model choice, updates, and logging are designed local-first.

Good fit: strict internal security rules and tightly controlled document movement.

AWS with HIPAA-eligible services

Built on AWS services that fit the use case, aligned with BAA coverage, encryption, IAM, network segmentation, key management, logging, and backups.

Good fit: teams that want managed infrastructure and easier operations than a fully local deployment.

Hybrid boundary

PHI stays inside one system boundary while downstream workflows receive only the minimum data they need, through de-identification, tokenization, and field-level mapping.

Good fit: integrations that should not expose whole document sets to every service.

Business Associate Agreements

We execute BAAs when the engagement requires it and document responsibilities across you, the platform, the cloud provider, and any supporting vendors.

Good fit: any engagement where hosting, support access, or workflow participation creates business associate obligations.

Controls we put in place

What has to exist for a HIPAA-sensitive workflow to behave responsibly.

Access and user boundaries

  • Role-based access and permission review
  • Restricted admin and support access paths
  • Production and non-production data kept apart

Encryption and storage

  • Encryption at rest and in transit
  • Scoped storage locations and retention rules
  • Backups matched to the actual risk

Audit trails and exceptions

  • Event logs for document and workflow actions
  • Review queues for low-confidence or unusual cases
  • A record of who changed what and when

Vendor and service review

  • Every integration mapped to the data it touches
  • Minimum-necessary data movement
  • BAA coverage aligned to support responsibilities

Where we already do this

Senior Insight and Dexzyle

EHR/eMAR and healthcare communication.

Cloud infrastructure, data systems, and HIPAA-sensitive integrations for resident care, medication management, and document handling in senior living communities.

seniorinsight.com

Taliswitch

Secure care-team workflow.

Secure messaging, prescription visibility, document context, integration boundaries, and audit-friendly workflows for care teams.

taliswitch.com

Experience in HIPAA environments does not make every workflow automatically compliant. It means we know how to scope the environment, limit exposure, choose vendors, and run the controls the use case actually needs. For specific workloads, see HIPAA-compliant document search and OCR to SQL pipelines.

What it takes

  1. Scope the workflow and PHI boundary

    Identify the documents, systems, users, vendors, and handoffs. Decide what is in scope and what should be isolated, redacted, or kept out entirely.

  2. Choose the deployment pattern

    Local, air-gapped, AWS, or hybrid, based on risk tolerance, integration needs, and who will support the system day to day.

  3. Implement controls around the pipeline

    Permissions, logging, secrets management, encryption, backups, retention, review paths, and support boundaries.

  4. Document ownership and agreements

    Who owns operations, which vendors are in scope, where BAAs apply, and how incidents, access requests, and changes are handled.

Request a workflow review

Tell us what the workflow is, which systems hold the PHI, and any constraints you already know about, like no outside internet or an existing AWS account.

  • We reply by email with an honest answer on whether a pipeline is the right fix.
  • If it is, the next step is a scoped pilot on your real documents.
  • Denver, Colorado. We sign Business Associate Agreements where PHI is involved.