Why event streaming for healthcare is different from other industries
A clinical integration team usually starts with a familiar problem: point-to-point interfaces between the EHR, the laboratory system, pharmacy, and bedside or device systems, each built one feed at a time, each with its own mapping and its own failure modes. The short answer is a self-hosted Kafka-based backbone, with HL7 v2 and FHIR adapters at the edges, running in the organization's own data center or cloud account. The hard part of that design is not throughput. It is deciding which messages carry protected health information (PHI), who may read each topic, how long each class of event is kept, and how a reviewer proves all three. Hospitals and clinics typically move a few event types first (admissions, orders, results) and find that the payloads are where the risk sits.
HIPAA does not offer a certification that an organization can buy and display. The HHS position is that no Security Rule standard requires certifying compliance, and the Office for Civil Rights judges the organization on complaints, compliance reviews and audits. That means the evidence for a streaming platform has to be documented controls: a data inventory showing which topics contain ePHI, unique identities for each producer and consumer, TLS and authorization settings, log retention, and a record of who changed what. Confirm with your privacy and security officers whether each topic is a business associate flow or a covered entity flow, because that determines which contract terms under 45 CFR 164.314 must reach the operator and any subcontractor. Those contract terms are a decision to make before the first topic is created.
Platform choice matters less than most vendor conversations suggest. Kafka, Pulsar, NATS and RabbitMQ can all carry clinical events, and the decision that protects patients is how access and audit are designed: which service accounts hold which ACLs, whether consumers are limited to the care relationships they need, whether minimum necessary data is enforced in the message or in a downstream service, and how audit records of access are kept and reviewed. Ask any implementation partner to walk through these decisions for one real interface before discussing cluster sizing. The answers will show whether the team has treated the stream as a clinical record flow or as plumbing.
Which HIPAA and related obligations shape the streaming build
This table maps each obligation to what it asks of topics, ACLs, TLS and logs in a healthcare streaming build. Read each row as a design input to settle before brokers are configured, not as a compliance finding. Scope questions such as whether your streaming platform is covered depend on your own role under HIPAA and should be confirmed with counsel.
| Obligation | What it means for the streaming build | Evidence an assessor or auditor will expect |
|---|---|---|
| HIPAA Security Rule scope (45 CFR 164.302) | Any topic carrying ePHI that a covered entity or business associate creates, receives, maintains or transmits falls in scope, including broker logs and replicas holding that data | Data flow diagram showing which topics carry ePHI and which systems produce or consume them |
| Unique user identification (164.312(a)(2)(i)) | Each producer, consumer, connector and admin needs its own identity, so avoid shared service accounts for HL7 or FHIR feeds | Principal inventory mapped to named systems and owners, with no shared credentials |
| Emergency access procedure (164.312(a)(2)(ii)) | Document how an authorized person reaches topics during an outage without bypassing ACLs, and log that access | Written break-glass procedure and records of its use |
| Automatic logoff (164.312(a)(2)(iii)) | Applies to admin consoles, Kafka UIs and connector dashboards that show PHI-derived messages | Configured session timeouts on administrative tooling |
| Encryption and decryption (164.312(a)(2)(iv)) and transmission security (164.312(e)) | Use TLS between clients, brokers and tools, and confirm encryption at rest for broker storage and backups | TLS configuration evidence and key management records |
| Audit controls (164.312(b)) | Broker authorization and client activity should be logged and retained under your policy, separated from PHI payloads where possible | Sample of retained logs showing who read or wrote which topic |
| Business associate contracts (164.314(a)(2)(i)) | If a partner operates or hosts the platform, the contract must require Security Rule compliance, flow terms to subcontractors and require incident reporting | Signed agreement covering the streaming platform and any subcontractor with access |
| Access control and MFA (CNIL, Hopital Prive de la Loire, 3 September 2026) | The CNIL fine, under GDPR Articles 32 and 34, cited external access without VPN or MFA and access ignoring care team need to know, so scope ACLs to clinical roles and require MFA for remote admin paths | Role-to-topic matrix, MFA records for remote access and periodic access reviews |
| NIS2 health sector (Annex I) | Healthcare providers and certain medical device and pharmaceutical manufacturers in the EU fall within the health sector of high criticality, so confirm whether your streaming dependencies are in NIS2 scope | Documented scope determination and incident handling procedure for the platform |
What PHI looks like inside topics and why payload design matters
The most consequential decision in healthcare streaming is what goes into each message, because every copy of that message lands on brokers, replicas, connector outputs and backups. An HL7 v2 ADT or ORM message carries the patient name, date of birth, medical record number and visit details in pipe-delimited segments such as PID and PV1, and a FHIR resource such as Patient, Encounter or Observation carries the same identifiers in JSON or XML. Device events from infusion pumps, monitors or lab analyzers often add a device serial number or patient location. PHI also appears outside the payload: a message key set to a medical record number, or a header carrying a patient identifier for routing, is readable by anyone who can read the topic. Before a topic is created, list every field in the key, headers and value, and mark which are ePHI under the HIPAA Security Rule.
Minimize what is copied. A common design publishes an event that says an encounter was updated and carries a resource reference, such as a FHIR logical ID, so consumers fetch details through an authorized API that applies consent and access checks. Where consumers need full content, limit the payload to the fields they use and tokenize or pseudonymize identifiers that routing does not need. Schema registries help enforce this, since a schema can reject fields that a topic should never carry, but they also keep every schema version, which matters for deletion. Retention and deletion interact here: a patient's data may be needed for a deletion or amendment request, yet topics are immutable logs with a retention period. Confirm with your privacy and records teams how a deletion request reaches data already written to a log, and whether the answer is to keep PHI out of long-retention topics in the first place.
Which open-source platforms fit healthcare event streaming and why
Healthcare event streaming needs a backbone for moving clinical events, a FHIR layer for standard resource access, a gateway that controls who reaches those interfaces, and a clear boundary for tools that should stay away from PHI. The cards below cover each role and the licensing or version checks that affect the decision.
Apache Kafka as the event backbone
Kafka is the most common choice for the backbone that carries admissions, orders, results and device events between systems. The Apache License 2.0 applies, and the project itself offers no paid edition, so cost sits in your own operations or a partner's support. Supported releases are 4.3.1, 4.2.2 and 4.1.2, and since 4.0 Kafka runs only in KRaft mode, so any ZooKeeper-based cluster must migrate first. Brokers and Kafka Connect require Java 17. Confirm the upgrade path from your current version before you commit.
HAPI FHIR as the FHIR store and API
HAPI FHIR is a Java library and JPA server for HL7 FHIR clients and servers, licensed under Apache 2.0. It supports DSTU2, DSTU3, R4, R4B and R5, so the version you need should be decided against the interfaces your partners actually use. For production, the JPA server supports PostgreSQL and Microsoft SQL Server, not MySQL. HAPI FHIR does not provide a complete security layer, so access rules, consent and audit logging must be designed and tested on top of it.
APISIX or Kong for API access control
An API gateway sits in front of FHIR endpoints, REST services and any HTTP interface that exposes clinical data, enforcing authentication, rate limits and routing before a request reaches the application. Apache APISIX and Kong are both licensed under Apache 2.0. Gateway policy does not replace resource-level authorization inside the FHIR server, so the two layers must be designed together. Check which plugins you need and whether they are in the open-source edition.
Node-RED or n8n for bounded integration
Node-RED (Apache-2.0) and n8n (Sustainable Use License, with .ee files under an enterprise license) are useful for small flows such as device gateways or notifications that carry no PHI. Using n8n for internal business use is governed by its Sustainable Use License, and any feature marked .ee needs a separate enterprise license. Keep these tools out of the main clinical data path, restrict their credentials and network access, and confirm the license terms with counsel before deployment.
Kafka access control and TLS
Kafka offers SSL and SASL for authentication, with GSSAPI, PLAIN, SCRAM and OAUTHBEARER mechanisms, and TLS for encryption in transit. Security is optional in Kafka, so clusters can run with unsecured listeners unless you disable them. In KRaft, ACLs live in the cluster metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Verify that setting is false in your clusters before any PHI topic goes live.
Audit logging and retention evidence
HIPAA's technical safeguards call for audit controls and unique user identification, and event platforms produce much of the evidence an assessor will sample. Kafka topics are not an audit log by default, so decide which events are written to a separate, access-restricted store and how long they are kept. HAPI FHIR's BALP audit logging and the AuthorizationInterceptor can contribute to this record. Ask your compliance lead to define retention per data class before the first topic is created.
How to set access control and retention for clinical topics
Authentication decides which clients, brokers and tools can establish a session with the cluster at all. Apache Kafka supports SSL (certificate-based client identity) and SASL, and the Kafka security overview documents five SASL mechanisms: GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. For clinical systems, the choice usually follows the identity platform the organization already runs, and each option carries different credential handling and rotation work.
- Disable unauthenticated listeners: Kafka security is optional, so a cluster can run with plaintext or mixed listeners. Confirm that every listener that carries clinical topics requires authentication.
- Use mutual TLS where services are fixed: Certificates tie each interface engine or integration service to a known identity, which supports unique user identification.
- Pick SASL/OAUTHBEARER for workforce or service identity: If the identity provider already issues tokens, this can reduce long-lived shared secrets. Confirm token lifetimes with your identity team.
- Avoid shared accounts: Each source system, consumer group and administrator should have its own identity so that audit records show who did what.
- Plan credential rotation before go-live: Write down who rotates certificates and SASL secrets, how often, and how consumers reconnect.
Before you approve a design, check which mechanism your clinical source systems can actually use, since some legacy interface engines support only a subset.
Authorization decides what an authenticated identity may read, write or administer. In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. Kafka's documented default is that resources without ACLs are restricted to super users, unless the setting allow.everyone.if.no.acl.found is set to true. Keeping that default and granting access explicitly per topic and consumer group is the usual starting point for clinical data.
- Keep allow.everyone.if.no.acl.found at its restrictive default: Do not enable it to make a test work and forget to revert it. Treat any change as a reviewed configuration change.
- Grant per-topic, least-privilege ACLs: An admissions producer should write only to its own topic, and a results consumer should read only the topics it needs.
- Limit super users to a named break-glass group: Record who holds this role and review it on a fixed schedule.
- Separate producer, consumer and administrative roles: Platform operators rarely need to read patient-level payloads, so their access should be explicitly narrower.
- Align ACLs with the need-to-know model: Work with clinical and privacy owners to define which care teams and integrations may see which event types.
Ask the implementation partner to export the ACL set and walk through it with you, because ACL drift is one of the most common findings in access reviews.
Encryption covers two different exposures. Encryption in transit protects payloads moving between clients, brokers and tools, and Kafka supports SSL/TLS for this. Encryption at rest protects the stored log segments on broker disks, backups and snapshots, and in Kafka it is generally provided by the storage layer, the operating system or the infrastructure platform rather than by Kafka itself. Confirm which layer your environment uses, because the answer changes who holds the keys.
- Require TLS on every clinical listener: Confirm that inter-broker traffic and client traffic both use TLS, not only the external listener.
- Use an approved certificate authority and key lifecycle: Document issuance, renewal and revocation, and test renewal before expiry.
- Encrypt volumes and backups: Ask your infrastructure team which encryption mechanism applies to broker disks, snapshots and backup repositories, and where the keys are held.
- Restrict key access: The people who can read decryption keys should be a narrow, logged group that is separate from application administrators.
- Account for field-level encryption: If only specific fields such as identifiers should be protected within the payload, that design is an application decision that must be made and tested by the integration team.
Be precise with auditors about which layer provides each control, since a claim of encryption at rest that cannot name its key owner will not hold up.
Retention determines how long events stay in a topic and how they are removed. Kafka retention is configured per topic, and it is a technical setting that must reflect the organization's record policy rather than a default. Clinical events may serve several purposes at once: operational replay, downstream reconciliation and audit. Each purpose can justify a different period, and deletion of the events is a separate decision from the retention of the source record in the EHR or other system of record.
- Set retention per topic from the record schedule: Map each clinical topic to the retention rule that applies to the data it carries, then configure it explicitly.
- Separate replay retention from audit retention: Short-lived topics for replay should not be treated as the audit record. Decide where the long-term evidence lives.
- Document deletion behavior: Explain what happens to events, consumer offsets and backups when the retention period ends.
- Control log and backup copies: Retention applies to replicas, mirrors and backups as well as the primary cluster, so include them in the schedule.
- Avoid payloads that outlive their purpose: Minimizing what is published, such as sending a reference instead of full content, reduces the data that retention must govern.
Retention and deletion periods must be confirmed with your legal and privacy teams, and they should be tested in a non-production environment before they are applied to live clinical topics.
How a healthcare streaming rollout moves from one interface to production
The sequence takes a healthcare organization from an inventory of clinical interfaces to a set of live, access-controlled streams, one interface at a time, with a documented rollback for each. Durations depend on how many interfaces are in scope and how many systems each one touches.
Inventory interfaces and classify PHI
The team lists every interface in scope, including the source and destination systems, message types such as HL7 v2 ADT, ORM, ORU or FHIR resources, the owner of each feed and the consumers that depend on it. Each data element is then tagged by sensitivity, so the team can see which topics will carry ePHI, which carry only operational metadata, and which must not be streamed at all. The output is an agreed interface register and a PHI classification that security and clinical leadership both sign off on.
Confirm business associate and vendor terms
Before any ePHI reaches a new component, the organization confirms that the contracts cover it. Where DeployOpen or another partner will operate, configure or access the platform, the business associate agreement must require Security Rule compliance, flow the same terms to subcontractors that handle ePHI, and set incident reporting duties. Legal and compliance review the open-source license terms of each component as well. The output is a list of signed agreements matched to the systems that will touch ePHI.
Stand up a non-production cluster
The team builds a non-production Kafka cluster in the organization's own cloud account or data center using KRaft mode, since Kafka 4.0 supports only KRaft and ZooKeeper-based clusters must migrate first. Brokers, Kafka Connect and tools run on Java 17. The chosen Kafka release is taken from the supported versions on the downloads page, and the team confirms the upgrade path it will need later. The output is a reproducible environment with versions recorded and a baseline health check.
Build adapters and FHIR mapping
Engineers build the producers and consumers that move messages between clinical systems and topics. HL7 v2 feeds are translated into event payloads, and where a FHIR API is the target, mapping is done to FHIR resources, using a server such as HAPI FHIR where it fits the architecture. Payloads are kept to the minimum fields each consumer needs, and schemas are versioned. The output is tested adapters with documented mappings, reviewed by clinical informatics staff who know the source messages.
Implement ACLs and TLS
The team turns on TLS between clients, brokers and tools and configures a SASL mechanism that the organization's identity service supports. Authorization is set with ACLs so each service account can read or write only the topics it needs. Kafka restricts resources without ACLs to super users unless the cluster is configured otherwise, so the team confirms that default and records any exception. The output is a configuration baseline and an access matrix that maps each topic to the services and people allowed to use it.
Run access and audit tests
Testers attempt the access the matrix should block, including reads from unrelated services, unauthenticated connections and access by administrators outside their role. They confirm that audit logs capture authentication, produce and consume activity needed for investigations, and that log retention matches the policy agreed in the first phase. Any failure returns to the build phase. The output is a test report with each finding closed or accepted in writing by the data owner and the security lead.
Cut over one interface at a time
Each interface moves to production separately, with the legacy path kept available. The team runs both paths in parallel for a window agreed with the clinical owner, compares message counts and content, and then switches the consumers. A written rollback procedure describes how to revert to the legacy feed if a message loss or ordering problem appears. The output for each interface is a completed cutover record that names the decision maker and the rollback test result.
Hand over operations
The partner transfers runbooks, monitoring dashboards, alert thresholds, upgrade and patch procedures, backup and restore steps, and the incident response contacts. Operations staff run a supervised period in which they handle routine tasks while the partner is available for escalation. Open items, such as planned Kafka upgrades and certificate renewals, are recorded with owners. The output is an accepted handover package and a list of recurring tasks the organization will own from that point.
Evidence auditors and regulators ask for, and which component produces it
This table maps the evidence a HIPAA assessor, HHS Office for Civil Rights investigator or HITRUST assessor may ask for to the streaming or FHIR component that produces it. Read each row as a question to answer before go-live and again at each review. DeployOpen prepares this evidence, but independent assessors and HHS decide whether the organization conforms.
| Evidence | What it shows | Component that produces it |
|---|---|---|
| Kafka ACL definitions | Which principals may produce to, consume from or administer each admissions, orders, results or device topic | Kafka StandardAuthorizer, with ACLs stored in the KRaft metadata log |
| TLS and SASL configuration | Encryption of traffic between clients, brokers and tools, and the authentication mechanism used | Kafka listener and security configuration files, reviewed against the security overview |
| Access review records | Who holds broker, topic and FHIR server access, when it was granted and when it was last confirmed | Identity provider exports, Kafka ACL dumps and HAPI FHIR authorization rules, reviewed on a set schedule |
| BALP audit logs | Who read or changed FHIR resources, and when, in a format the Basic Audit Log Pattern defines | HAPI FHIR server with BALP audit logging enabled, shipped to a central log store |
| Retention settings | How long topics, audit logs and FHIR data are kept and how they are deleted | Kafka topic retention configuration, log store retention policy and FHIR data lifecycle procedures |
| Security incident records | Detection, triage, containment and reporting of incidents, including potential breaches of unsecured PHI | Incident ticketing system fed by broker and FHIR server alerts, with the handling procedure attached |
| Business associate agreements | Written terms requiring a vendor or subcontractor to meet the Security Rule and report incidents | Contract records held by the covered entity or business associate, not by the software |
| Risk analysis and risk management records | How ePHI flows through topics and APIs were assessed and which controls were chosen in response | Data flow diagrams, topic inventory and risk register maintained by the organization with DeployOpen input |
| Backup and restore test results | Whether topics and FHIR data can be recovered within the objectives the organization set | Backup job logs and dated restore test reports for brokers and the FHIR database |
What healthcare teams ask before building event streaming in-house or with a partner
What drives the cost of event streaming for healthcare?
The main cost drivers are the number of interfaces, the amount of PHI flowing through topics, the high availability design, and the skills available in-house. Each interface adds mapping, testing and monitoring work, so a count of source and target systems is the first thing to agree. Infrastructure costs recur (compute, storage, backups, and redundant sites), while design, build, hardening and handover are typically one-time. Ask any partner for a quote that separates these components, lists which interfaces are in scope, states who runs the platform after handover, and names the test and evidence deliverables. DeployOpen does not publish prices, and a quote follows from a written scope.
How long does a healthcare event streaming rollout take?
Duration depends on scope, not on the platform choice alone. The timeline is driven by how many admissions, orders, results and device feeds are in scope, how many interface owners must validate message mappings, whether the design includes multi-site resilience, and how long security and clinical reviews take. A narrow first phase covering one or two high-value flows can be planned separately from later waves. Ask for a phased plan with milestones, dependencies on each interface owner, and acceptance criteria for each wave. DeployOpen agrees timelines in writing as part of a fixed-scope engagement before work starts.
What does the health system need to provide during the project?
The work depends on several named people, and the project plan should name them early. Interface owners for the EHR, laboratory, pharmacy and device systems must confirm message types, field mappings and acknowledgment behavior. The security team must approve network paths, identity sources, encryption settings and access roles for PHI in topics. Clinical staff must sign off on flows that affect care, such as result routing and order status. Compliance and privacy leads should review retention and the business associate terms that apply to any vendor with access to ePHI. Ask the partner to list these roles and the hours each needs per phase.
Can our internal team run a self-hosted Kafka platform for clinical data?
Some teams can, but the question is whether the team has the capacity for on-call, upgrades, security administration and monitoring on a continuous basis. Operating a broker cluster involves capacity planning, certificate and access management, topic governance and backup and restore testing. Many organizations combine internal ownership of day-to-day operations with a partner for design, hardening, runbooks and periodic reviews, or they sign a support retainer. Assess your current staff against these tasks, and ask a partner to document the operating model, handover steps and the skills your team would need before taking ownership.
Does HIPAA certify our event streaming platform?
No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Compliance readiness means implementing the administrative, physical and technical safeguards in 45 CFR Part 164 Subpart C for the ePHI your systems handle, keeping evidence of that work, and executing business associate contracts where required under 45 CFR 164.314. Any statement that a platform is HIPAA certified should be treated as a red flag.
How are Kafka upgrades handled without disrupting clinical interfaces?
Upgrades follow the vendor's supported path, and the plan should be written before any change. The Kafka downloads page lists 4.3.1, 4.2.2 and 4.1.2 as supported releases, and the time-based release plan states that rolling upgrades are supported from each release in the past year to the latest version. Apache Kafka 4.0 supports only KRaft mode, so ZooKeeper-based clusters must migrate first, and KRaft clusters older than 3.3.x should move to 3.9.x before 4.x. Since 4.0, brokers and Connect require Java 17. A safe plan includes a staging environment that replays representative HL7 and FHIR traffic, rollback steps, and a change window agreed with interface owners.
How do we choose between HL7 v2 and FHIR for each interface?
Choose by what the source and target systems already support and what the clinical workflow needs. HL7 v2 messages are common for admissions, discharges and transfers, orders and results between established hospital systems, and many devices and laboratory systems produce it. FHIR resources suit API-based exchange, such as retrieving patient, observation or medication data on demand. Many organizations run both, with a translation layer that maps HL7 v2 events to FHIR resources. HAPI FHIR, licensed under the Apache Software License 2.0, is one open-source option for a FHIR server, with the JPA server supporting R4, R4B and R5. Validate each choice against your vendors' supported versions and your interface inventory.
How should PHI in event topics be protected and retained?
Start by deciding whether a topic needs PHI at all. Where it does, the platform must encrypt traffic with TLS, authenticate clients with an approved SASL mechanism or certificates, and restrict topics with ACLs so only named services can produce or consume. In KRaft clusters, the StandardAuthorizer stores ACLs in the metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Retention should match clinical and legal requirements, and log access should support audit. Confirm these settings in your own environment and test them with a security review before go-live.
Questions to ask an implementation partner before signing a healthcare scope
Start with the question that decides whether the rest of the scope is safe to sign: will the partner accept business associate terms that match 45 CFR 164.314(a)(2)(i)? Ask whether they will sign a business associate agreement where their engineers can reach systems holding ePHI, whether those terms flow down to any subcontractor that touches the environment, and how they report security incidents, including suspected breaches of unsecured PHI, to your covered entity and within what internal process. Then ask where PHI may appear in topics at all. Payloads carrying HL7 or FHIR content should be scoped by message type, and the partner should show you which fields are minimized, tokenized or kept out of topics entirely, and how test and staging clusters are kept free of production data.
Next, press on defaults. Ask the partner to show, on a running cluster, the SSL or SASL listeners, the authentication mechanism for each client group, and the ACL configuration that shows resources without ACLs are restricted. Under the KRaft authorizer, the setting allow.everyone.if.no.acl.found should be false in production, and the partner should explain who holds super user rights. Ask how they will handle the upgrade path: clusters still on ZooKeeper must migrate to KRaft before any move to Kafka 4.x, and the Kafka upgrade notes recommend KRaft clusters older than 3.3.x move to 3.9.x first. Ask for the written upgrade plan, the Java 17 requirement for brokers, and the rollback point. For the FHIR layer, ask which authorization, consent and search narrowing interceptors they will configure, whether BALP audit logging is enabled, and where audit records are stored and for how long.
Finally, ask how evidence will be produced and who will run the tests. A credible partner will say they prepare configuration exports, access reviews, backup logs and test records for your assessors, and will state plainly that they do not issue attestations or certifications, since HHS does not certify HIPAA compliance. Request a backup and restoration test with a recorded recovery time, and a switchover exercise for the FHIR database, which the HAPI FHIR documentation says should be PostgreSQL or Microsoft SQL Server in production. Confirm the handover package for clinical integration staff: runbooks, alert ownership, topic and schema registries, and a named training plan. Ask for these items in the written scope before work starts, not after.
How DeployOpen scopes, builds and supports healthcare event streaming
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For healthcare event streaming, that means agreeing a written scope covering clinical message flows, PHI handling and access controls before any broker is configured.
How we scope
- Map which admissions, orders, results and device event flows enter topics and which systems consume them
- Record where protected health information appears in payloads, headers and logs, and who may read each topic
- Agree in writing the deliverables, timelines and retention rules, with engagements fixed-scope and quoted from that scope
How we build
- Deploy the chosen Kafka or other broker in the client's own data centers or cloud accounts with TLS and SASL configured
- Set ACLs in the cluster metadata, integrate HL7 and FHIR adapters, and test authorization and encryption against the agreed design
- Document configuration, data flows and evidence so the security and compliance team can review each control
How we hand over
- Deliver runbooks for topic creation, access requests, certificate rotation and upgrades to the platform team
- Train operators on monitoring, incident response and restoration of topics according to the agreed scope
- Provide architecture records and a control mapping that the organization can share with its own assessors
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover
- Plan broker and Java upgrades against the vendor's published upgrade notes and test them before production
- Confirm with your team the support hours, escalation paths and change approval process before the retainer starts
