Best Kafka management tools for healthcare organisations

Tools compared

Rank	Tool	Total (out of 110)	Out of the data path	Audit trail per person	Production access on request	Inspecting topic data	Directory and Kafka sign-in	Many teams, shared clusters	Cost a year (modelled)
1	Kpow	99	One container, state in your Kafka, not a proxy	Every action with the IdP user, data queries included	Time-boxed temporary policies via API, staged approvals, masking per resource	kJQ search across topics, on the server	SAML, OIDC, LDAP; Kerberos, SCRAM or mTLS to brokers	Tenants and per-action RBAC	$29,880
2	Kafbat UI	74	One stateless container	Optional, reads at level ALL, no view	Per-resource RBAC, no approvals, masking for all viewers	Message browsing	OAuth2, OIDC, LDAP; no SAML	Per-resource roles per cluster	$11,520
3	AKHQ	64	One stateless container	Opt-in, no reads, no view	Regex groups, UI-only if JWT secret unset	Topic data browsing	LDAP, OIDC; no SAML	Groups by resource and cluster pattern	$16,320
4	Lenses	64	HQ on PostgreSQL, agent and database per cluster	In-product audit log from Team tier	Strict global masking, no approvals	SQL over topics	SSO incl. Entra ID and Okta	Roles on groups only	$2,880 plus quoted licence
5	Confluent Control Center	43	Dedicated host, broker reporter JAR	Broker principal, not always the person	Confluent RBAC, no DENY, no approvals	Topics > Messages view	OIDC on self-managed	Admin access only, per TD Bank	$2,880 plus quoted subscription
6	Conduktor	67	Console on PostgreSQL; Gateway proxy in the data path	70+ event types with user, in the UI	Per-viewer masking, cross-team access requests	Browse and filter	LDAP, OIDC	Per user or group, most permissive grant wins	$50,880; $140,880 with Gateway Core and Protect

No tool meets every column, and healthcare organisations commonly pair a management tool for people with broker ACLs or an authorizer for services.

The tools, ranked for healthcare organisations

What healthcare organisations need from a Kafka management tool

This page is about organisations that deliver, pay for or coordinate care: hospitals and health systems, claims processing and healthcare cost management companies, state health agencies that run Medicaid programs, and the networks that move referrals and patient information between care providers. Companies that build connected medical devices and health software for their own products are covered in best Kafka management tools for health technology and medical device companies. Health insurers’ own policy and claim systems are covered in best Kafka management tools for insurers, and the regulation-by-regulation view for banks, payments and insurance is in best Kafka governance tools for financial services.

Kai Waehner’s overview of Apache Kafka in the healthcare industry describes data flowing between modern cloud-native microservices and monolithic on-premise applications, some using open standards such as HL7 with FHIR and some using proprietary formats, and gives a public health example that connects claims and clinical data from legacy systems with cloud services. Claritev’s middleware team runs Kafka for claims processing at millions of messages a day, across development, SQA, a client-facing CIT environment and production, and soaks each upgrade for a month in each environment before it reaches production. The mix of formats is moving toward FHIR on a timetable: the CMS Interoperability and Prior Authorization final rule requires Medicare Advantage organisations, state Medicaid programs and the other payers it covers to run FHIR APIs, generally from January 2027, and to send prior authorization decisions within 72 hours for urgent requests and seven calendar days for standard ones, so where those flows run over Kafka a stalled consumer is counted against a regulatory deadline as well as an operational one.

Every one of those messages can carry protected health information, and the people who keep the flows running still need to read production topics when something breaks. The HIPAA Security Rule’s audit controls standard, 45 CFR 164.312(b), asks covered entities and business associates to “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” HIPAA does not name Kafka or any tool, but when engineers work through a shared management tool, the brokers only see that tool’s service account, so the tool’s own log is the only place that can name the person who opened a topic. In Europe, Article 9 of the GDPR treats health data as a special category of personal data.

Where the tool runs decides how much of that there is to review. HIPAA’s definition of a business associate, in 45 CFR 160.103, covers anyone who “creates, receives, maintains, or transmits protected health information” on a covered entity’s behalf, and it names providers of “data transmission services” that need routine access to that information. A hosted console that pulls message data into a vendor’s cloud, or any vendor-operated service that claims and clinical messages pass through, puts that vendor inside the question the definition asks, and the privacy office has to settle it before the tool is switched on. Software that the organisation runs in its own environment, with the vendor given no access to the data, leaves the question with the organisation’s own safeguards.

On the audit trail the Security Rule is specific about two things beyond the audit controls standard. The same section makes unique user identification a required specification, “assign a unique name and/or number for identifying and tracking user identity”, and 45 CFR 164.308(a)(1)(ii)(D) requires procedures to “regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.” A shared Kafka principal cannot satisfy the first for the people behind it. A log that exists only as records on a topic or lines on a console satisfies the first without making the second practical, because somebody has to build the consumer and the report before any review can take place. The cost of leaving access unreviewed is on the public record: Memorial Healthcare System paid $5.5 million in 2017 after the login credentials of a former employee of an affiliated practice were used to access patient records daily for a year, in a case where the health system had not implemented procedures to review and modify users’ access rights.

The breach notification rule shows why that record has to include reads. In it, 45 CFR 164.402 presumes that an impermissible access to protected health information is a breach unless the organisation demonstrates a low probability that the information was compromised, and one of the four factors in that assessment is “whether the protected health information was actually acquired or viewed.” An audit log that records each data query with the person, the topic and the time lets an organisation answer that question for a specific account and a specific window, while a log that records only topic and configuration changes leaves the assessment with no evidence on that factor. European regulators apply the same test. The Dutch Data Protection Authority fined Haga Hospital €460,000 after dozens of staff viewed one patient’s file, finding that the hospital “failed to regularly monitor who was consulting which records” and did not use two-factor authentication.

Production access falls under the Privacy Rule’s minimum necessary standard, which asks for “reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose.” An engineer tracing a stuck claim needs the message’s structure, status and routing identifiers and seldom needs the patient’s name or diagnosis, which is the argument for masking on the server and for access that ends when the task does. The identifier list in the de-identification standard, 45 CFR 164.514(b)(2), is a practical starting point for a masking policy, because names, dates, telephone numbers, medical record numbers, health plan beneficiary numbers and account numbers are all on it. Masking in a tool limits what people see through that tool, and it does not de-identify the data held on the brokers.

Healthcare payloads make message search harder than in most industries, because two generations of format share the same clusters. HL7 version 2 messages are delimited text, with the delimiters declared in the message header, and each message carries a control ID in MSH-10 that the HL7 standard defines as “a number or other identifier that uniquely identifies the message.” FHIR resources are exchanged as nested JSON, and a Patient resource holds its identifiers as a repeating element, so a medical record number sits inside an array beside the patient’s other identifiers. A search tool therefore has to filter inside nested and repeating structures, and it has to cope with text that is not JSON at all. The second case has a consequence for masking that is easy to miss. Field-level redaction needs structured data, and Kpow’s data policies documentation states that String SerDes are removed from data inspect once data policies are configured. A topic that carries raw HL7 version 2 text can then be read as text only if it is listed as an exclusion, which leaves it unmasked, or through a custom SerDes that presents the message as JSON so that a policy can reach the patient identification fields. Organisations that convert version 2 messages to FHIR or JSON before they reach Kafka do not face that choice.

Sign-in is where the largest healthcare incident of recent years began. UnitedHealth’s chief executive told Congress that the attackers behind the 2024 ransomware attack on Change Healthcare used compromised credentials on a remote access portal that did not have multi-factor authentication. A Kafka tool that signs people in through the organisation’s identity provider with SAML or OpenID Connect inherits that provider’s multi-factor and conditional access rules, while a tool with local accounts is one more login outside them. The update to the Security Rule that HHS proposed in January 2025 would make multi-factor authentication an express requirement, so the question is likely to appear in more security reviews whether or not the rule is finalised as proposed.

Shared clusters raise a question that is specific to patient data, which is that running a cluster and reading its contents are different jobs. A middleware team needs to create topics, change configuration and restart connectors, and none of that requires opening a claim. In Kpow’s RBAC any action without a matching policy is implicitly denied, so an administrator’s role can inspect topic data only where a policy grants it, and the minimum necessary standard can be applied to the platform team as well as to developers. The audit record needs the same care, because each entry holds the contents of the request, and a search filtered on a member number can therefore write that number into the audit topic. Kpow’s multi-tenancy includes a Kpow Hidden tenant that excludes Kpow’s internal groups and topics, so a tenant defined for a development team should exclude them as well.

A management tool for this work should add nothing between the organisation’s applications and their brokers, keep no copy of the data outside the organisation’s clusters, record reads as well as changes against a named person, and let a platform team grant a developer access to a production topic for one task with patient fields masked. Much of the remaining work is ordinary operations, and Claritev’s case study gives two examples: finding which broker is out of sync when Kubernetes and Prometheus report healthy, and seeing that an application is missing from the consumer group it should have joined.

What healthcare organisations use Kpow for

Three healthcare organisations that run Kpow are named here: a claims and cost management company, a state health agency and a patient referral network. Claritev has described its use in public, in a case study with Factor House, so its card describes how Kpow is used and is tagged with the rubric criteria its evidence speaks to. The other two cards carry public information about the organisation itself, not a description of its Kpow setup.

How a healthcare organisation runs its Kafka with Kpow

Each workflow below uses documented Kpow features, linked to the Factor House docs, and the Claritev case study describes several of them in daily use.

Install it beside the clusters. Kpow runs as one Docker container or Java JAR, or on Kubernetes with the Helm charts, inside the organisation’s own network. It connects to the brokers as an ordinary Kafka client with the same cluster security settings as any other client, and it needs no external database, because its state lives in topics on the organisation’s own clusters. Claims, referral and clinical services keep talking to the brokers directly. Claritev runs self-managed Kafka on Kubernetes and is moving it from Rancher to Oracle Kubernetes Engine, with Factor House providing the setup instructions for running Kpow there.

Put every environment in one view. One instance connects to self-managed Apache Kafka, Confluent Platform, Confluent Cloud and Amazon MSK together, up to 12 clusters, so development, test, pre-production and production clusters sit side by side and an engineer picks the environment before looking at anything. Kpow also documents support for Oracle’s managed OCI Streaming services.

Find the broker that is out of sync. When an application slows down but the platform’s own health checks are green, the team opens the cluster in Kpow and checks the brokers directly. That is how Claritev found the one broker that was not running in a degraded cluster that Kubernetes and Prometheus reported as healthy, and restarted that broker instead of cycling all of them. Kpow also publishes broker, topic, consumer group and lag metrics on Prometheus endpoints, so the organisation’s existing monitoring can alert on what Kpow sees. Platform health checks and Kafka health can disagree for a structural reason. A Kubernetes probe reports whether a container is alive and ready, not whether a broker is in sync with its replicas, and the broker metric most dashboards alert on, UnderReplicatedPartitions, is reported by each broker, so a broker that is down reports nothing. Kpow counts under-replicated partitions per topic partition against the configured replication factor instead of asking each broker, so a cluster with a broker down still shows them.

Check that an application has joined its consumer group. When a new integration does not receive messages, the consumer group view shows the group’s topology, its members and their offsets, live and over time. Claritev’s team used it to see straight away that an application connecting Kafka to Informatica was not part of the expected consumer group, which the CLI could only show as a point-in-time snapshot.

Trace one claim or referral through the topics. When a message goes missing between two systems, an engineer opens data inspect, selects the topics the message passes through, sets a time window, and filters by key, value or header with kJQ, for example on a claim or referral identifier. The search runs on the server, so nobody writes a throwaway consumer against production, and the query itself lands in the audit log. kJQ is a JQ-like filter language, modelled on jq, which many engineers already use on JSON, so the syntax is familiar during an incident. A report that Kafka has lost a message can end the way the incident in Things that go bump in the night did, where inspecting the topic showed the messages were still there and had never been read, and for a referral or a claim that finding is what moves the investigation to the consuming system. The schema view shows the structure each payload should have, and in a test environment data produce sends a test message so the team can see how the next system handles it.

Separate admins from developers. RBAC sets Allow, Deny or Stage per action and resource, with Deny winning where policies overlap, and directory groups map to roles through LDAP or SAML with Microsoft Entra ID. Claritev uses this to keep elevated, auditable admin access with its middleware team and give developers read-only access in production and in the client-facing CIT environment. Where several teams share a cluster, a tenant scopes each one to its own topics, consumer groups and connectors.

Grant production access for one task. An engineer who needs to inspect a production topic during an incident raises a request in the organisation’s change system. Once it is approved, that system calls the Kpow API to create a temporary policy that grants inspect access on the named topics for an hour or two. The policy expires on its own, is capped at seven days by default, and is recorded in the audit log. An administrator cannot grant more than their own role allows, and a grant can be set to end at a chosen date and time as well as after a duration. The same mechanism serves as the break-glass path. The usual failure of emergency access is that it is never taken away afterwards, and the AWS Security Blog’s guidance on temporary elevated access treats break-glass access as a case for the same time-bound, logged grant as any other request.

Mask patient fields. Data policies redact names, member and patient identifiers, dates of birth and clinical fields in Data Inspect and ksqlDB results on the server, so an engineer tracing a claim or referral sees its structure and status without the patient’s details. An organisation that encrypts payloads itself can load its own custom SerDes so authorised users read the decrypted data while it stays encrypted on the brokers. Encrypting fields in the application before they reach the broker is the pattern Confluent documents as client-side field level encryption, and it leaves the broker, and any generic tool, unable to read those fields unless the tool can run the organisation’s own deserializer inside the organisation’s deployment.

Hold risky changes for a second person. With staged mutations, a role can be set to Stage on actions such as resetting a consumer group’s offsets or deleting a topic, so the request waits in Kpow until an administrator approves or denies it, and the full history lands in the audit log.

Keep the record of who did what. The audit log records each action, data inspect queries included, with the user from the organisation’s directory and the policy that allowed it. Kpow shows the last seven days in the product and writes the record to the __oprtr_audit_log topic on the organisation’s own cluster, where Kpow’s topics default to one week of retention, so for the longer record a security team reviews, webhooks send mutations, data inspect queries or both to Slack, Microsoft Teams or any endpoint the organisation chooses, such as its SIEM. Two settings matter for a healthcare organisation. The webhook sends mutations only by default, so an organisation that wants reads in its SIEM sets WEBHOOK_VERBOSITY to QUERIES or ALL, and because query events describe searches that may have been filtered on a patient identifier, the SIEM is a better destination for them than a chat channel. Each record also carries the authorization result and the policies that were evaluated against the request. The Security Rule names no retention period for the logs themselves, but its documentation standard, 45 CFR 164.316(b)(2)(i), keeps required records for six years, a horizon that no seven-day view or one-week topic meets.

Govern Flink jobs the same way. Organisations that run Apache Flink beside Kafka, for example to enrich claims or join clinical events, can put the same directory sign-in and Allow, Deny or Stage policies over their Flink jobs with Flex.

Know what the deployment does and does not cover. Kpow is one Docker container or JAR, and everything it needs to operate, snapshots, metrics and the audit log, is held in topics on the organisation’s own cluster, so beyond Kafka it has no dependencies. Two consequences belong in a security review. It snapshots each cluster every minute, which suits investigation and trend views and does not replace a metrics pipeline that has to page within seconds, and its web UI records product usage with Google Analytics, which its data collection documentation describes as page views and action names without query strings, unless ALLOW_UI_ANALYTICS is set to false, which paid licences can do and Community and trial licences cannot. Kafka data itself stays in the organisation’s environment unless the organisation connects one of Kpow’s optional AI features to a hosted model provider. Those features generate a kJQ filter that the query engine validates before it runs, the model is the organisation’s own choice, and a hosted provider that receives message content raises the business associate question described above, which is a reason to run a local model for topics that carry patient data.

Keep a separate control for applications. Kpow governs people working through Kpow, not services connecting to brokers, so broker ACLs or an authorizer remain the control for claims, referral and clinical applications. Conduktor Console also connects to clusters directly, keeps a detailed audit log and masks data in its own UI, but it needs an external PostgreSQL database, and Conduktor’s encryption, masking of the data itself, policy enforcement on client traffic and Virtual Cluster multi-tenancy run through Conduktor Gateway, which Conduktor’s own documentation describes as a Kafka proxy between client applications and brokers. The trade runs in both directions, because Gateway can enforce policy on applications, which Kpow does not attempt, at the cost of a component that every message passes through. Lenses’ SQL is likewise a stronger query model than kJQ for analysts who think in SQL.

To see these screens before installing anything, the live Kpow demo needs no signup and shows data inspect with kJQ, consumer groups, topic management and the audit log topic on two MSK clusters. To run the workflows against the organisation’s own clusters, install Kpow from its container image or JAR; tenants, RBAC, temporary policies, staged mutations, masking and the audit log are Kpow Enterprise features, and Community Edition is free for 3 clusters and 10 users.

To check the rubric against the product, open the demo, run a kJQ search across topics, follow a consumer group’s lag, then open the __oprtr_audit_log topic on MSK Secondary to see what the audit trail records. The demo has no SSO and no data policies configured, so sign-in and masking are the two things to test in your own environment.

Kpow Data Inspect searching three topics at once with one kJQ filter. The topics in this demo carry airline baggage events; a healthcare organisation filters its claims and referral topics the same way.

Kpow live demo

Read the audit trail the way a health system's security team would

The live Kpow demo needs no signup. Search topic data with kJQ across several topics, follow consumer groups and lag on two clusters, then read the audit trail on the __oprtr_audit_log topic of the MSK Secondary cluster.

For platform, middleware and security teams running Kafka under claims, referral and clinical systems.

Try the Kpow demo→

FAQ

What is the best Kafka tool for a healthcare organisation?

On this page’s rubric, Kpow: it runs as one container with no external database and nothing in the data path, records every action and data query with the person from the organisation’s directory, grants time-boxed production access through its API, masks patient fields in inspection, searches message content across topics with kJQ, and separates admin and read-only roles per team. Kafbat UI is the strongest free option, but its audit trail has no view in the product and it has no expiring access grants. For a small team that only needs to browse, search and manage topics, Kpow Community Edition is free for 3 clusters and 10 users, without the governance features scored here.

Does HIPAA require an audit trail for Kafka?

HIPAA does not name Kafka or any technology. The Security Rule’s audit controls standard, 45 CFR 164.312(b), asks covered entities and business associates to “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” Where claims, referral or clinical messages carry that information through Kafka, the cluster and the tools people use on it are among those systems. Broker audit logs name the client principal, which for a shared management tool is the tool’s own service account, so the record of which person read or changed a topic has to come from the tool, and a tool that logs each data inspect query with the person who ran it supplies it.

Is there a HIPAA-compliant Kafka management tool?

No tool is HIPAA compliant on its own. The technical safeguards in 45 CFR 164.312 are written for covered entities and business associates: the audit controls standard asks for mechanisms that record and examine activity, the access control standard asks that access go only to people who have been granted access rights, and the person or entity authentication standard asks the organisation to verify that whoever seeks access is the one claimed. A Kafka management tool is one of the mechanisms an organisation uses to meet them, through its audit log, its access policies, its sign-in through the organisation’s directory, and where it runs. Kpow runs inside the organisation’s own environment, so patient data in Kafka stays there unless the organisation connects one of Kpow’s optional AI features to a hosted model provider.

How do healthcare organisations use Kafka?

In healthcare, Kafka typically connects claims platforms, electronic health records, referral and scheduling systems, labs and cloud analytics. Kai Waehner’s overview describes flows that mix HL7 with FHIR, JSON and proprietary formats, and Claritev runs Kafka for claims processing at millions of messages a day. That is why a management tool for healthcare has to find one message by its identifier across topics, and control who reads the patient data in them.

Can engineers troubleshoot Kafka without seeing patient data?

Yes, if the tool masks on the server and grants access per task. In Kpow, data policies redact patient fields in data inspect results before they reach the browser, a temporary policy grants inspect access on named topics for a fixed time and then expires, and every query is recorded with the person who ran it. The engineer still sees the message’s structure, offsets and headers, which is usually enough to find where a flow broke.

How does a healthcare organisation give an engineer break-glass access to a production Kafka topic?

The access control standard in the same HIPAA section, 45 CFR 164.312(a), includes an emergency access procedure: “procedures for obtaining necessary electronic protected health information during an emergency.” In Kpow, an administrator, or a change system calling the Kpow API, creates a temporary policy that grants inspect access on the named topics for a fixed time and expires on its own, capped at seven days by default. Data policies keep patient fields masked while the engineer works, and every query run under the grant lands in the audit log with the engineer’s name.

Is a Kafka proxy a problem for patient data?

A proxy is a deliberate choice with real uses, such as enforcing policy on applications, but every message carrying patient data that is routed through it passes through one more component that has to be sized, run for high availability and cleared through the organisation’s security review, and Kai Waehner notes that the extra network hop can slightly increase end-to-end latency. A management tool that connects as an ordinary Kafka client avoids that, because producers and consumers never pass through it.

Can a hospital run Kpow in its own data centre?

Yes. Kpow runs as one Docker container, Java JAR or Helm deployment wherever the organisation’s Kafka runs, with no external database, and one instance connects to self-managed and managed clusters together, up to 12 clusters. Its system requirements ask for it to be installed in reasonably close proximity to the Kafka resources it manages, so an organisation with clusters in a hospital data centre and in a cloud region runs an instance in each. Kai Waehner’s healthcare overview describes that split, with cloud-native microservices on one side and “monolithic proprietary on-premise applications” on the other.

Do healthcare organisations need a different Kafka tool from insurers?

The tool can be the same, but the priorities differ. This page weights the per-person audit trail as heavily as staying out of the data path, because the HIPAA audit controls standard puts that record at the centre of a healthcare organisation’s security review, while the insurers page weights message tracing more heavily for quote, policy and claim systems.

How these tools were scored

Six criteria, each taken from a situation healthcare organisations have described in public or face under the HIPAA Security Rule, score every option from 0 to 10. They are listed here in order of weight; the weights add up to 11, so the total is out of 110.

1. Out of the data path. A management tool that runs in the organisation’s own environment, connects as an ordinary Kafka client and keeps no data outside the organisation’s clusters adds nothing between the organisation’s applications and the brokers, and gives the shortest answer when the security team asks which systems can see patient data. Scored lower: tools that need an external database, and tools whose controls work only when application traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or a component on the brokers 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.

2. Audit trail per person. When people work through a shared tool, the broker only sees the tool’s service account, so only the tool’s own log can name the person. A healthcare organisation needs that log to include data reads as well as changes, so it can show who looked at a topic carrying patient data as well as who changed one, and to be readable without building a consumer first. Kafka audit logging tools compares the layers in detail.

3. Production access on request. Can an engineer be given read access to a production topic for a task, approved and time-boxed, without a standing grant? Can production changes such as offset resets be held for a second person’s approval? And is patient data masked for the people who do get in? The wider set of controls over deletes and offset resets is compared in Kafka destructive operations tools, and masking in best Kafka data masking tools.

4. Inspecting topic data. Finding one claim or referral means filtering messages by key, value or header across several topics, on the server, without writing a consumer against production. SQL over topics scores highest, filtered search across topics next, and browsing or filtering one topic at a time a point lower. Best Kafka message search tools covers search in detail.

5. Directory and Kafka sign-in. People should sign in through the organisation’s directory, whether that is LDAP directly or SAML and OIDC in front of Active Directory or Entra ID, with directory groups mapped to roles. On the cluster side the tool has to connect the way the organisation’s clusters already authenticate clients, whether that is SASL, Kerberos or mutual TLS. Kafka SSO tools covers the protocol detail.

6. Many teams, shared clusters. A middleware or platform team runs a handful of clusters for several development teams across several environments, so admin rights stay with the team that runs the clusters, each development team is scoped to its own topics, consumer groups and connectors, and a new team is onboarded with a policy rather than a cluster. Reaching cloud and on-prem clusters from one deployment is not scored here; best tools to manage multiple Kafka clusters from one place compares it.

The cost figures model a healthcare organisation running 6 clusters (four production and two pre-production) for 40 engineers at $120 an engineer-hour, and each card prints its own assumptions. The general listicle view, without the healthcare weighting, is in best Kafka management tools.

F1 What a healthcare organisation runs into, and what the Kafka tool has to do about it

What happens at a healthcare organisation What the Kafka tool has to do

Patient data in topics Claims, referral and clinical messages carry protected health information through every topic they pass Run inside the organisation's own environment as an ordinary Kafka client, with no external database and no vendor proxy on the path those messages take

Who looked at what The HIPAA Security Rule asks covered entities and business associates to record and examine activity in systems that contain electronic protected health information Log each action and each data query with the person from the directory, and send the record to the organisation's SIEM

Production access An engineer needs to read a production topic during an incident, and the patient fields in it are not theirs to see Grant read access for the task and let it expire, mask patient fields on the server, and hold risky changes for a second person

A broker out of sync Kubernetes reports every pod healthy and Prometheus raises no alert while a cluster is degraded Show brokers, consumer groups and their members live and over time, so the team restarts the right broker

Admins and developers A middleware team runs the clusters for several development teams across development, test and production Give the middleware team admin rights and developers read-only access in production, mapped from directory groups

Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts three times, Audit trail per person counts three times, Production access on request counts twice, Inspecting topic data counts once, Directory and Kafka sign-in counts once and Many teams, shared clusters counts once, for a total out of 110. Out of the data path counts three times because claims, referral and clinical messages carry protected health information through every topic, so a tool that sits between applications and brokers handles every one of those messages, and a tool that keeps its state in a database of its own is one more system to run and to clear through a security review. The per-person audit trail also counts three times, because the HIPAA Security Rule's audit controls standard asks covered entities and business associates to record and examine activity in systems that contain electronic protected health information, and when people work through a shared tool only the tool's own log can name the person. Production access on request counts twice, because engineers still need to read production topics during an incident without a standing grant to patient data. Inspecting topic data, directory sign-in and shared clusters count once each. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 99 out of 110. The other options follow by total. Conduktor is listed last whatever its total; on its total of 67 it would place third.

Related reading

• Kafka: the complete guide
• Best Kafka audit logging tools
• Best Kafka data masking tools
• Best Kafka management tools for insurers
• Best Kafka management tools for health technology and medical device companies
• Best Kafka governance tools for financial services
• Best Kafka tools for self-managed Apache Kafka