We build your healthcare data lake. You keep control.
Services · Healthcare data engineering
Netspective engineers HL7 v2, FHIR R4 and C-CDA ingestion pipelines inside your own AWS account or Azure subscription. Your KMS or Key Vault keys encrypt the data, your IAM or Entra ID policies decide who can reach it, and the Terraform or OpenTofu code that builds it lives in your repository.
What you own, and what we do
You retain 100% ownership of every asset in this table from the first day of the engagement. Netspective works inside your tenant under named roles you issue and can revoke.
| Asset | Owner | Netspective's role |
|---|---|---|
| AWS account or Azure subscription and tenant | Customer | Works inside it under named, least-privilege roles you issue and can revoke. |
| Root encryption keys (AWS KMS or Azure Key Vault) | Customer | Never holds, exports or escrows root key material. |
| Identity and access policies (IAM or Entra ID) | Customer | Proposes least-privilege policies; you approve them and can remove any Netspective principal at any time. |
| Infrastructure code (Terraform or OpenTofu) and its state | Customer | Commits modules to your repository; state lives in a backend you own. |
| Pipeline code: ingestion, validation and transforms | Customer | Commits every pipeline to your repository. |
| Documentation, data dictionaries and runbooks | Customer | Delivers them in your repository, not in a Netspective portal. |
| Data, including PHI | Customer | Processes it only inside your tenant, for the contracted purpose. |
What Netspective builds and runs in your tenant
Clinical ingestion pipelines for HL7 v2, FHIR R4 and C-CDA
Interfaces that receive HL7 v2 ADT and ORU feeds, FHIR R4 bundles and C-CDA documents, land them in object storage you own, and record lineage from each source message to the stored record.
Schema validation and transforms
Each message is checked against its HL7 v2 message structure, FHIR R4 profile or C-CDA template before it is accepted. Failures go to a triage queue with the reason attached instead of into the lake; accepted data is normalized into query-ready tables.
Optional operations under your roles
After go-live, our engineers can monitor ingestion, triage validation failures and run key rotation through your KMS or Key Vault policies, using roles your team issues and can withdraw. You can take any of this work in-house whenever you choose.
Your exit path
Every engagement keeps an exit package current from the first sprint, so you can move operations in-house or to another vendor at any time, with no vendor lock-in. The package contains five parts:
- Inventory. Every account, role, key and repository, generated from the infrastructure code's state rather than kept by hand.
- Access-revocation runbook. The ordered steps to remove every Netspective principal and rotate any secret our engineers have seen.
- Rebuild proof. A recorded
terraform planortofu planrun from your repository that reproduces the environment with no Netspective-only inputs. - Operations runbooks. Ingestion monitoring, validation-failure triage, key rotation, backup and restore, and incident response, written for your team or another vendor.
- Knowledge-transfer plan. Named sessions and the artifacts each session covers.
What the exit package does not depend on
None of the five parts needs a Netspective account, tool or licence to use. Any tooling we bring that is not assigned to you is named in the statement of work, with a licence that survives the end of the engagement.
Delivery experience
Engagements are described by the type of organization, not by client name, until each client approves being named.
Regional Health Information Networks
Live clinical ingestion and validation for regional health information networks
Netspective engineers have built live, high-volume clinical ingestion pipelines and HL7 v2 and FHIR validation engines for regional health information networks, and run cloud data operations for them.
- High-volume HL7 v2 ingestion pipelines
- HL7 v2 and FHIR validation engines
- Cloud data operations
Compliance is shared: the controls you can verify
HIPAA obligations stay with your organization, and no architecture removes them. Each party carries out a defined part, so we state the split and name the controls you can check.
| Party | Responsible for |
|---|---|
| Cloud provider (AWS or Azure) | Physical security and the HIPAA-eligible services covered by your Business Associate Agreement with them. |
| Your organization | Your HIPAA obligations, access approvals and workforce policies, and the keys and policies in your tenant. |
| Netspective | The pipelines, validation and controls named in the statement of work, built only from HIPAA-eligible services, with evidence you can review. |
- HIPAA-eligible cloud architecture: only services your cloud provider lists as HIPAA-eligible, under your Business Associate Agreement.
- Auditability: CloudTrail or Azure Activity Log and data-access logs retained in storage you own; every infrastructure change traceable to a commit.
- Customer-managed access controls: IAM or Entra ID policies you own and approve; every Netspective role can be revoked.
- Data sovereignty: data, keys and region selection stay in your tenant.
How each engagement documents the split
Each engagement maps every control to the party that operates it in a responsibility matrix delivered with the runbooks, so an auditor can see who runs each control and where its evidence is kept.
Request an architecture discovery
Tell us about your sources, volumes and cloud, and an engineer will scope the discovery with you. Email sales@netspective.com or use the contact page to book a call.