Entrazure
Three constraints that make this sector different
PHI does not tolerate ambiguity. Every place patient data lands has to be known, segmented, encrypted and logged. “We think it is only in the main database” is the sentence that precedes a breach notification. The architecture has to make the data path legible.
Your customers audit you. For digital health companies, the blocker is rarely a regulator. It is the first hospital or payer that sends a 200-line security questionnaire before signing. That questionnaire is an architecture document in disguise, and answering it well is a revenue event.
Clinical time is the scarcest resource. Automation and AI have obvious value here, but anything that adds a step to a clinician’s day dies within a month regardless of how well it performs.
What we build for healthcare
- HIPAA-ready Azure landing zones: PHI segmented into its own subscription boundary, encryption and diagnostic settings enforced by policy, private endpoints on every data service, and access reviewed on a schedule rather than on memory.
- Audit evidence produced by the pipeline: access grants, changes and deployments recorded as they happen, exportable per control, so SOC 2 and HIPAA reporting stops being a quarterly scramble.
- AI grounded on clinical and operational data: retrieval that respects record-level permissions, inference inside your tenant, full prompt logging, and an explicit boundary on what the system may do.
- Integration with clinical systems: EHR, scheduling, billing and patient-facing applications connected through APIs and events with retries and contracts, replacing nightly file transfers nobody monitors.
A concrete scenario
A care organization holding patient records across several sites wants an assistant that answers staff questions from its own documentation and case history. The model is the easy part. The engagement is spent on: which documents may be surfaced to which role, how consent and record-level permissions propagate into retrieval, where inference runs, what is logged, what the assistant is forbidden to do, and how a clinician can tell what a given answer was based on. That work is what makes it deployable rather than demonstrable.
Regulatory context we design against
HIPAA (US), SOC 2 Type II, Quebec’s Law 25 and Canadian provincial health privacy legislation, and GDPR where European data is involved. Data residency is enforced at the management group level, so a new subscription cannot silently place patient data in the wrong region.
Questions we get
Can Azure be HIPAA compliant?
Azure can be configured to support HIPAA compliance, and Microsoft will sign a BAA covering in-scope services. Compliance is not a property of the platform, it is a property of how you configure it: which services you use, how PHI is segmented, encrypted and logged, and who can reach it.
We are a small digital health company. Is this over-engineered for us?
Not necessarily, because the requirement scales with the data rather than with headcount. A ten-person company holding PHI faces the same regulatory exposure as a hospital, with less capacity to absorb an incident. We scope down the architecture, not the controls.
Our first enterprise customer is asking for SOC 2. Where do we start?
With the architecture, not the questionnaire. Most of a SOC 2 audit asks how change is controlled, how access is granted and reviewed, and how it is evidenced. If those are enforced by policy and pipeline, the audit is a reporting exercise. If they are manual, it is a nine-month project.
Can AI touch clinical data?
With deliberate boundaries. We build retrieval that respects existing record permissions, log every prompt and response, keep inference inside your tenant, and design the interface so a clinician remains accountable for the decision. What the system may and may not do is written down and enforced, not implied.