Best Kafka management tools for health technology and medical device companies

Tools compared

Rank	Tool	Total (out of 100)	Out of the data path	Many teams, shared clusters	Audit trail per person	Production access on request	IAM, SCRAM and mTLS	MSK Connect and Glue	Cost a year (modelled)
1	Kpow	91	One container, state in your Kafka, not a proxy	Tenants and per-action RBAC	Every action with the IdP user, data queries included	Time-boxed temporary policies via API, staged approvals, masking per resource	IAM, SCRAM and mTLS documented for MSK	Both, with cross-account roles	$20,880
2	Kafbat UI	68	One stateless container	Per-resource roles per cluster	Optional, reads at level ALL, no view	Per-resource RBAC, no approvals, masking for all viewers	IAM setup guide	Glue through a plugin, no MSK Connect	$11,520
3	AKHQ	60	One stateless container	Groups by resource and cluster pattern	Opt-in, no reads, no view	Regex groups, UI-only if JWT secret unset	IAM library bundled	Glue deserialise only, no MSK Connect	$16,320
4	Lenses	56	HQ on PostgreSQL, agent and database per cluster	Roles on groups only	In-product audit log from Team tier	Strict global masking, no approvals	IAM for its agent	Glue, no MSK Connect	$2,880 plus quoted licence
5	Redpanda Console	46	One stateless container	RBAC licence-gated; one cluster per deployment	None on Apache Kafka brokers	No access control without an Enterprise licence	IAM, timeouts on large clusters	Neither documented	$8,640 plus quoted licence
6	Conduktor	59	Console on PostgreSQL; Gateway proxy in the data path	Per user or group, most permissive grant wins	70+ event types with user, in the UI	Per-viewer masking, cross-team access requests	IAM	Glue, no MSK Connect	$50,880; $140,880 with Gateway Core and Protect

No tool meets every column, and companies on managed Kafka commonly pair a management tool for people with IAM policies or Kafka ACLs for devices and services.

The tools, ranked for health technology and medical device companies

What health technology and medical device companies need from a Kafka management tool

This page is about companies that build health technology: makers of connected medical devices, and digital health and health software companies, including the software that carries referrals and clinical messages between care providers. Their platform teams run Kafka for their own products, often on a managed service. Hospitals, health systems, payers, state health agencies and the networks that move referrals between care providers are covered in best Kafka management tools for healthcare organisations. Health insurers are covered in best Kafka management tools for insurers, and the regulation-by-regulation view for financial services is in best Kafka governance tools for financial services.

Kai Waehner’s overview of Apache Kafka in the healthcare industry lists IoT sensor analytics, cybersecurity and patient communication among the places data streaming is used, and notes that the systems Kafka connects in healthcare differ in format: some “use open standards like Health Level Seven (HL7) with FHIR, others use open data formats like JSON, and some use proprietary data formats.” In a health technology company that usually means readings and events from devices in the field, records from the company’s own apps and clinical software, and messages exchanged with hospitals and other care providers, all landing in the same few clusters.

Firmware, cloud, data and clinical software teams usually share those clusters, each owning some of the topics and needing to see and change its own without seeing every other team’s. The record format also changes as devices and apps are updated: a new firmware release can add a field to the readings it sends, and consumers keep working only if the schema registry enforces compatibility. A management tool has to show each team its own topics and the schemas behind them, and on AWS that often means the AWS Glue Schema Registry and MSK Connect as well as the topics, compared in best Kafka UI tools for AWS Glue Schema Registry.

Device readings, therapy records and referral messages in those topics can identify a patient. Where that data is electronic protected health information, the HIPAA Security Rule’s audit controls standard asks for “hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information”. In Europe, GDPR Article 9 treats data concerning health as a special category of personal data that may be processed only under one of its listed exceptions. A tool that engineers use to read production topics therefore has to mask the fields they do not need, grant access for a task rather than permanently, and record who looked. It also goes through the company’s security and vendor review, and a tool that runs inside the company’s own environment as an ordinary Kafka client, with no proxy in front of the brokers, leaves the least to explain in that review.

Which rules apply depends on who the company sells to, and that changes what a security review asks of the tool. A device maker or software vendor that handles patient data for hospitals, clinics or health plans is usually a business associate under HIPAA, and 45 CFR 164.302 applies the Security Rule to business associates directly. The definition in 45 CFR 160.103 also counts as a business associate “a subcontractor that creates, receives, maintains, or transmits protected health information on behalf of the business associate”, and 45 CFR 164.308(b)(2) lets a business associate use such a subcontractor only after it obtains satisfactory assurances, documented in a written contract. A hosted console that pulls message data into a vendor’s cloud, or a vendor-operated service that device and patient messages pass through, therefore adds a subcontractor and a contract to the chain the company answers for to its hospital customers, while software the company runs itself, with the vendor given no access to the data, adds neither. A company on AWS has already been through this once for the platform itself: the AWS HIPAA Eligible Services Reference lists Amazon MSK, AWS Glue and AWS IoT Core among the services that may handle electronic protected health information once the customer has a business associate agreement with AWS. That agreement covers the AWS services and not the software a company runs on them, so the comparison between tools is about parties: a self-hosted container adds no new party to the data flow and needs no new agreement, and a console hosted by a third party sends message data to a vendor with which the company has none yet.

Companies that sell health apps and connected devices directly to consumers are often outside HIPAA altogether, and the FTC’s Health Breach Notification Rule covers them instead. The FTC’s guidance on complying with the rule says its July 2024 amendments “make clear that makers of health apps, connected devices, and similar products must comply with the Rule.” Two definitions in 16 CFR 318.2 bear on a Kafka tool. A third party service provider is an entity that provides services to a covered company and “accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses” the health information as a result, and it carries a notification duty of its own; a hosted console fits that description and a self-hosted tool does not. The same section presumes that unauthorized access to the information is unauthorized acquisition, and so a breach, unless the company “has reliable evidence showing that there has not been, or could not reasonably have been, unauthorized acquisition of such information.” A log of which person queried which topic, and when, is evidence of that kind, and a log that records only topic and configuration changes cannot supply it.

For device makers the back end is also part of what the FDA asks about. Section 524B of the Federal Food, Drug, and Cosmetic Act, in 21 USC 360n-2, requires the sponsor of a cyber device to maintain processes that give reasonable assurance that “the device and related systems are cybersecure” and to supply a software bill of materials, and the FDA’s premarket cybersecurity guidance sets out the documentation it recommends. Neither text mentions Kafka or its tooling, but they are the reason a device company’s security review follows the data past the device into the systems that receive it, and in that review a component that every device message passes through is harder to set aside than a tool that connects beside the applications as one more client.

The audit trail answers to more than one rule in this industry, and the rules ask for different things. FDA’s 21 CFR 11.10, which governs systems that hold electronic records kept under FDA regulations, asks for “secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records”, together with authority checks and access limited to authorized individuals. It is a rule about changes, and it is the reference point a device company’s quality team brings to any tool that can alter production data. The privacy rules are about reads: 45 CFR 164.410 requires a business associate that discovers a breach to notify the covered entity within 60 calendar days and to identify “each individual whose unsecured protected health information has been, or is reasonably believed by the business associate to have been, accessed, acquired, used, or disclosed”, a list the company can keep short only if it can show which topics a person queried. In the Netherlands, an overview of Dutch law on electronic health records prepared for the European Commission records that the regulation on electronic data exchange between care providers requires system logging to comply with the NEN 7513 standard. A tool whose log covers data queries as well as changes, each against a named person, serves all three, and on Amazon MSK the cloud’s own trail does not fill the gap: under IAM access control, AWS CloudTrail logs seven Apache Kafka actions, all of them topic and configuration operations, so reading a topic’s records is not among them, and the identity on each event is the IAM role the tool runs under, not the engineer using it.

Production access runs against a deadline in a device company. Under 21 CFR 803.50 a manufacturer reports to the FDA within 30 calendar days of becoming aware of information that reasonably suggests a device may have caused or contributed to a death or serious injury, or has malfunctioned in a way that would be likely to if it recurred, and 21 CFR 803.53 shortens that to 5 work days where remedial action is needed to prevent an unreasonable risk of substantial harm to the public health. The engineer who has to read one device’s events to establish what happened cannot wait a week for a standing role to be approved, and should not be left holding that role once the report is filed. Both problems have the same answer, a grant that is requested, approved and created in minutes and that expires when the investigation ends.

Masking has a detail that is specific to devices. HIPAA’s de-identification standard, 45 CFR 164.514(b)(2), lists “device identifiers and serial numbers” among the identifiers that have to be removed before data counts as de-identified, and on a device topic the serial number is commonly the record key. A policy that redacts the patient’s name in the value and leaves the serial number in the key has hidden less than it appears to, so a device company should check what a tool’s masking does to the record key before relying on it.

Team scoping has a privacy reading as well as an operational one. GDPR Article 25 requires that “by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons”, and a shared cluster browsed through a tool that shows every topic to every engineer is close to the situation that sentence describes. Scoping also lets a company keep its product lines apart where the rules differ, for example a prescribed device handled under HIPAA beside a consumer app that falls under the FTC rule, without giving each its own cluster.

The sign-in criterion matters more to device companies than its weight suggests, because their clusters often run more than one mechanism at once, and the reason is that devices in the field rarely speak the Kafka protocol. Kai Waehner’s comparison of Apache Kafka and MQTT notes that MQTT “was built for IoT use cases, including constrained devices and unreliable networks” and that “Apache Kafka is not an IoT platform”, so device messages usually arrive through an MQTT broker or a cloud IoT service and a bridge writes them to Kafka. On AWS one such bridge is the AWS IoT Core rule action for Apache Kafka, whose documentation gives SSL, or SASL_SSL with PLAIN, SCRAM-SHA-512 or GSSAPI, as its options and states that MSK Serverless is not supported because the rule action does not support IAM authentication. A cluster fed that way keeps a SCRAM or TLS listener open for the bridge even where the company’s own services use IAM, and Amazon MSK serves each mechanism on its own port. For a management tool this means it has to connect with whichever mechanism the platform team chooses for it, and because the Kafka principal on every device record is the bridge’s, the device’s identity exists only in the record key or the payload, which is where a search has to find it.

Schemas behave differently when the producers are devices. A cloud service is upgraded in one deployment, while a fleet of devices in patients’ homes takes a firmware update over weeks or months and some units never take it, so several schema versions are written to the same topic for as long as the product is supported. The AWS Glue Schema Registry offers eight compatibility modes, and the ones that suit a fleet are those ending in _ALL: its documentation describes BACKWARD_ALL as allowing consumers “to read both the current and all previous schema versions”, where plain BACKWARD checks only against the last one. A tool that reads Glue shows which schema version a given device’s record was written with, and a tool that does not leaves Glue-encoded device records unreadable. Connectors have a similar divide, because MSK Connect is managed through its own AWS API, which reports a connector’s state as one of RUNNING, CREATING, UPDATING, DELETING, FAILED or RESTARTING, so a tool has to call that API before it can show an MSK Connect connector beside the topics it reads and writes.

What health technology and medical device companies use Kpow for

Three health technology companies that run Kpow are named here: Claritev, which runs claims-processing Kafka for the US healthcare system, Philips Respironics, which makes sleep and respiratory care devices, and ZorgDomein, which runs a patient referral platform in the Netherlands. Claritev has described its use 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. Philips Respironics and ZorgDomein have not published an account of their Kafka, so their cards carry public information about each company.

How a health technology company runs its Kafka with Kpow

Each workflow below uses documented Kpow features, linked to the Factor House docs, the way the platform team at a health technology or medical device company would run them.

Install it in your own cloud account. Kpow runs as one Docker container or Java JAR, or on Kubernetes with the Helm charts, inside the company’s own VPC. It needs no external database, because its state lives in topics on the company’s own clusters, so device and patient data is not copied to a store outside them. A team on AWS can buy it through the AWS Marketplace and pay for it on the AWS invoice, and Amazon lists Kpow in the Amazon EKS User Guide as an AWS Marketplace add-on, factorhouse_kpow, published by Factor House.

Connect to MSK the way your services already do. Kpow’s MSK configuration covers IAM access control with AWS_MSK_IAM, SCRAM-SHA-512 with credentials from Secrets Manager, and mutual TLS, on provisioned and serverless clusters, and MSK Connect connectors sit beside the topics they read and write. Set up Kpow with Amazon MSK walks through the configuration. Teams on another distribution use the standard cluster settings instead. On a cluster where an IoT bridge writes over SCRAM while the company’s services use IAM, Kpow is configured with one of the two like any other client. Under IAM access control the policy attached to Kpow’s role decides what Kpow can do on the cluster, and the MSK page gives three example policies that run from every cluster in the account down to the topics and consumer groups of one cluster. That policy is the ceiling on what anyone can do through Kpow, and Kpow’s RBAC divides the ceiling among people. Companies that keep production in its own AWS account can leave Kpow in a tooling account and, once the brokers themselves are reachable from it over the network, have it reach MSK Connect and the Glue Schema Registry by assuming a role in the production account, the standard AWS STS AssumeRole pattern for cross-account access.

See the schema behind every device topic. Kpow reads the AWS Glue Schema Registry, including by assuming a role in another account, and Confluent-compatible registries, Apicurio and Karapace, with several registries per cluster if the company runs them. Engineers can look up a subject’s versions beside the topic that uses it and decode the topic’s records in Data Inspect, which helps when a firmware or app release changes the format. When part of a fleet is still on old firmware, the useful question is which records no longer decode. Data Inspect shows the schema ID and deserializer for each message, and its deserialization options can drop records that fail to decode, keep them flagged, or show only the failures, so the engineer can isolate the records a consumer cannot read.

Give each team its own view of shared clusters. Multi-tenancy restricts each team to the topics, consumer groups, schema registries and connectors it owns, by name or prefix, so a firmware team sees its device topics and a data team sees its analytics topics on the same cluster. RBAC then sets Allow, Deny or Stage per action and resource, and people sign in through Okta, Microsoft Entra ID or any OpenID Connect provider, with directory groups mapped to roles. Tenants are declared in the same YAML file as the RBAC policies and assigned to roles from the identity provider, so who can see a product line’s topics and who can change them are reviewed in one place. A policy names the cluster it applies to, which lets one role produce test messages in development and only inspect in production. The design that holds up is a few generic roles combined with team scope. A separate role for every team and product rebuilds a per-user access list under another name, the administration problem that the NIST model of role-based access control was introduced to remove.

Find one device’s events, with patient fields masked. When a device reports a fault, an engineer can use Data Inspect with a kJQ filter to search for one device serial number across several topics at once. Data policies redact names, dates of birth and other identifying fields on the server, so the engineer sees the readings and the event history without the patient’s identity. The SHAHash redaction replaces a value with its hash, so where a serial number has to be hidden one device’s records stay recognisable as the same device without the number being shown. The search can only reach what the topic still holds, and Kafka’s retention.ms defaults to seven days, while a complaint about a device often arrives later than that, so a company that expects to investigate from Kafka sets retention on its device topics to match the period it investigates over, or keeps the longer history in a store fed from them. The clearest public account of masking on Amazon MSK comes from Belong, a consumer telco owned by Telstra, whose Kafka talk lists among its reasons for buying Kpow “the PII masking feature in Kpow, which lets us mask fields like mobile number, first name, last name, or address.”

Grant production access for one task. Where reading production data at all needs approval, an admin, or a ticketing system calling the Kpow API, creates a temporary policy that grants inspect access on a named topic for a fixed time. It expires on its own, is capped at seven days by default, and is recorded in the audit log. An admin cannot grant more than their own role allows. Because the grant is an API call, the complaint or incident system that opens a device investigation can create it with the case, and the access ends when the policy expires, with nothing left for a later access review to find. Staged mutations hold risky changes, such as deleting a topic or resetting offsets in production, for an admin to approve before they run.

Keep a record of who did what. The audit log records each action, data inspect queries included, with the user from the 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 company’s own cluster, where Kpow’s topics default to one week of retention, so for a longer record webhooks send mutations, queries or both to Slack, Microsoft Teams or the company’s SIEM. How long that longer record has to be is set outside Kafka. Where the trail supports a record kept under FDA rules, 21 CFR 11.10(e) requires that it “be retained for a period at least as long as that required for the subject electronic records”, which no seven-day view or one-week topic meets, and on MSK Serverless the audit topic keeps one day.

Watch consumer lag on device pipelines. Kpow publishes consumer group lag, with broker, topic and connector metrics, on Prometheus endpoints for Grafana, AlertManager or the company’s own monitoring, so a consumer falling behind on device readings shows up before the data it feeds goes stale. Device traffic is uneven, since MQTT clients, as Kai Waehner’s comparison of Kafka and MQTT puts it, “can be offline for a long time”, and whatever a device held while offline arrives together when it reconnects, so a lag threshold tuned for steady traffic fires on every reconnection. The metrics glossary includes a gauge for consumer group state and a count of failed tasks per connector, and rules on those report a consumer that has stopped or a connector task that has failed without depending on a lag figure. The division of work is the one Google’s Site Reliability Engineering book draws between what is broken and why. The alerting system reports the symptom, and Kpow is where an engineer opens the group and the topic to find the cause.

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 company’s own cluster, so beyond Kafka it has no dependencies. It connects to brokers as an ordinary Kafka client, with the same cluster security settings as any other client. Devices and applications keep talking to the brokers directly, and the Kpow product page says Kpow runs “with no data leaving your environment”. Kafka data stays in the company’s environment unless the company connects one of Kpow’s optional AI features to a hosted model provider. Those features turn a plain-English question into a kJQ filter, and the model is the company’s own choice of Amazon Bedrock, OpenAI, Anthropic or a local Ollama server. For topics that carry patient data the choice of provider matters, because AWS describes Amazon Bedrock as HIPAA eligible, so a Bedrock model in the company’s own account stays inside its agreement with AWS, while a model provider outside that agreement is a new recipient of whatever is sent to it. No tool makes a Kafka deployment HIPAA or GDPR compliant on its own, and Kpow is no exception: it supplies the audit trail, access control and masking for people working through it. Every governance feature on this page is Enterprise, and Community Edition, free for 3 clusters and 10 users, holds none of them.

Keep a separate control for devices and services. Kpow governs people working through Kpow, not devices or services connecting to brokers, so IAM policies or Kafka ACLs remain the control for those. Its masking is per resource, not per viewer. Conduktor Console also connects to clusters directly 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 all run through Conduktor Gateway, which Conduktor’s own documentation describes as a Kafka proxy between client applications and brokers. Kai Waehner’s overview of Kafka proxies notes that a proxy “adds an extra network hop between clients and brokers, which can slightly increase end-to-end latency”. Kpow gives people RBAC, tenants, masking in inspection, temporary access and an audit log without putting anything in front of the brokers. The trade runs in both directions, because Gateway can enforce policy on applications and Kpow does not attempt that.

To see these screens before installing anything, the live Kpow demo needs no signup and runs on two MSK clusters. To check the rubric against the product, open the demo and do what a device company’s engineers do when a device reports a fault: search a topic for one key, check the schema behind it, 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, along with tenants for team scoping, are the things to test in your own environment. To run the workflows against the company’s own clusters, install Kpow from its container image or JAR; RBAC, multi-tenancy, temporary policies, staged mutations, masking and the audit log are Kpow Enterprise features.

Kpow live demo

Open Kpow the way a device company's platform team would

The live Kpow demo needs no signup. It runs on two Amazon MSK clusters: browse topics and their schemas, search messages with kJQ, follow consumer lag, then read the audit trail on the __oprtr_audit_log topic of the MSK Secondary cluster.

For platform teams running Kafka under connected devices and health software.

Try the Kpow demo→

FAQ

What is the best Kafka tool for a medical device or health technology company?

On this page’s rubric, Kpow: it runs as one container in the company’s own cloud account with no external database and nothing in the data path, scopes each team to its own topics, schemas and connectors, records every action against the person, grants time-boxed production access with patient fields masked, signs in to MSK over IAM, SCRAM or mTLS, and reads the Glue Schema Registry and MSK Connect. Kafbat UI is the strongest free option if the team signs in with OIDC and does not need team scoping, approvals or expiring access.

Does a Kafka management tool make Kafka HIPAA compliant?

No. HIPAA compliance covers the whole organisation and every system that holds electronic protected health information. A management tool can supply part of what the Security Rule’s audit controls standard describes, a record of who did what in a system that holds that data, along with access control and masking for the people using it. In Kpow those are the audit log, RBAC, tenants and data policies, all Enterprise features. Applications and devices that connect to the brokers directly are governed by the cluster’s own IAM policies or ACLs and audit logs, not by the management tool.

Can a Kafka UI read device data encoded with the AWS Glue Schema Registry?

Some can. Kpow reads the Glue Schema Registry and decodes its records, with cross-account role assumption, and also reads Confluent-compatible registries, Apicurio and Karapace. Kafbat UI decodes Glue records through a separate plugin, AKHQ only deserialises them, and Redpanda Console does not document Glue support. Best Kafka UI tools for AWS Glue Schema Registry compares them in detail, and best Kafka schema registry tools covers registries beyond Glue.

Does the ranking change for a health technology company that does not run Kafka on AWS?

No. Without the two AWS criteria, IAM, SCRAM and mTLS and MSK Connect and Glue, the other four criteria total 80, and Kpow still ranks first with 72, ahead of Kafbat UI at 55 and AKHQ at 48. Claritev, in the cards above, runs self-managed Kafka on Kubernetes. The same tools are scored for other platforms in best Kafka UI tools for Confluent Cloud, best Kafka UI tools for Google Cloud Managed Service for Apache Kafka and best Kafka tools for self-managed Apache Kafka.

Is a free Kafka UI enough for a health technology startup?

For browsing topics and consumer groups, often yes. Kafbat UI and AKHQ are free and run as one container each, and Kpow Community Edition is free for up to 3 clusters and 10 users, with topic search and inspection, consumer group and offset management, schema registry and Kafka Connect. None of the free options scopes each team to its own topics, grants production access that expires, or keeps an audit trail that can be read without building a consumer for it; in Kpow those are Enterprise features. On this page’s model the open-source tools cost $11,520 to $16,320 a year in engineering time, and Kpow Enterprise for 4 clusters is $18,000 a year in licence with 100 users included, $20,880 with the modelled operator time, which buys those controls and SAML sign-in without a separate proxy.

How these tools were scored

Six criteria, each taken from how health technology and medical device companies run Kafka, score every option from 0 to 10. They are listed here in order of weight.

1. Out of the data path. A management tool that runs in the company’s own environment, connects as an ordinary Kafka client and keeps no data outside the company’s clusters adds nothing between devices, services and brokers, and leaves the least to explain when the security team asks which components can see or store 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. Many teams, shared clusters. Firmware, cloud, data and clinical software teams share a handful of clusters across several environments, so each team needs to be scoped to its own topics, consumer groups, schemas and connectors, and the platform team should onboard a team with a policy rather than a cluster. Reaching several clusters from one deployment is not scored here; best tools to manage multiple Kafka clusters from one place compares it, and Kafka RBAC tools compares permission models.

3. Audit trail per person. When people work through a shared tool, the broker only sees the tool’s own IAM role or service account, so only the tool’s log can name the person. A company holding patient data needs that log to include data reads as well as changes, and to be readable without building a consumer first. Kafka audit logging tools compares the layers in detail.

4. 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 be held for a second person’s approval? And are patient fields 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 on its own in Kafka data masking tools.

5. IAM, SCRAM and mTLS. Many health technology companies run Kafka on Amazon MSK, where clients authenticate with IAM, SASL/SCRAM or mutual TLS. A tool that cannot connect the way the cluster is configured cannot be used at all. Scores are the same as on best Kafka UI tools for Amazon MSK.

6. MSK Connect and Glue. On AWS, schemas often live in the AWS Glue Schema Registry and connectors in MSK Connect. A tool that cannot decode Glue-encoded records or manage MSK Connect leaves two services outside it. Scores are the same as on the MSK page.

The cost figures model a health technology company running 4 clusters (development, test, staging and production) for 40 engineers at $120 an engineer-hour, and each card prints its own assumptions. Claritev’s case study counts about forty users across its development and middleware teams, close to this model. The general listicle view, without this weighting, is in best Kafka management tools.

F1 What a health technology or medical device company runs into, and what the Kafka tool has to do about it

What happens at a health tech or device company What the Kafka tool has to do

Patient data in topics Device readings, therapy records and referral messages can identify a patient Run inside the company's own environment as a Kafka client, with no proxy in front of the brokers and no database of its own

Many teams, few clusters Device, cloud, data and clinical software teams share the same clusters Scope each team to its own topics, consumer groups, schemas and connectors

Who looked at what Security and quality teams ask who read a production topic and who changed it Record every action, data queries included, with the person's directory identity

Payloads change Device firmware and app releases change the shape of the records they send Read the schema registry, including the AWS Glue Schema Registry, beside the topics that use it

Managed Kafka on AWS Clusters run on Amazon MSK, with IAM, SCRAM or mutual TLS for clients and MSK Connect for connectors Connect the way the cluster already authenticates clients and manage MSK Connect in the same view

Production fixes An engineer needs to read one device's events in production to fix a fault Grant that access for the task, mask patient fields, and let it expire on its own

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, Many teams, shared clusters counts twice, Audit trail per person counts twice, Production access on request counts once, IAM, SCRAM and mTLS counts once and MSK Connect and Glue counts once, for a total out of 100. Out of the data path counts three times because device and patient data sits in a health technology company's topics: a tool that puts a proxy between devices, services and brokers handles every one of those messages, and a tool that keeps its own state in a database outside Kafka is one more system to run and one more vendor component to clear through the company's security and vendor review. Many teams on shared clusters and the per-person audit trail count twice: device, cloud, data and clinical software teams share a few clusters, so each team has to be scoped to its own topics, and where that data is electronic protected health information, HIPAA's audit controls standard asks for mechanisms that record and examine activity in the systems that hold it. Production access on request counts once because it applies to the few engineers who read production device data during a fault, while team scoping and the audit trail apply to everyone who opens the tool. The cluster's IAM, SCRAM or mTLS settings and the AWS Glue Schema Registry with MSK Connect count once each, since many health technology companies run managed Kafka on AWS but not all of them do. 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 91 out of 100. The other options follow by total. Conduktor is listed last whatever its total; on its total of 59 it would place fourth.

Related reading

• Kafka: the complete guide
• Best Kafka governance tools for financial services
• Best Kafka management tools for insurers
• Best Kafka UI tools for Amazon MSK
• Best Kafka UI tools for AWS Glue Schema Registry
• Set up Kpow with Amazon MSK
• Best Kafka management tools for healthcare organisations