TI-Messenger for German healthcare on Matrix

No. HIPAA has no certification, and HHS states that no Security Rule standard requires an entity to certify compliance, so a private certificate does not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Teams working in a HIPAA context should prepare documented evidence for the technical safeguards in 45 CFR 164.312, including unique user identification, audit controls and transmission security. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue attestations or certifications. Independent assessors and certification bodies do that work.

HITRUST is an optional external assessment, not a legal requirement under German healthcare rules, and whether it is worth pursuing depends on your contracts and customers. HITRUST CSF v11.9.0 is organized in 14 control categories with 49 control objectives and 156 control specifications. An e1 or i1 certification lasts one year and an r2 certification lasts two years. Ask your assessor which assessment type applies and what scope they will test, including the Kubernetes cluster, the identity provider and the backup chain. DeployOpen can prepare the systems and evidence for that assessment, but the certification itself comes from an independent HITRUST assessor.

Access evidence comes from several components, and an auditor will expect all of them to line up. The Synapse logs record client and federation activity for each user session, the identity provider logs record sign-in events and failures, and Kubernetes audit logs record administrative changes to deployments, secrets and configuration. Map each log source to a specific control, such as unique user identification or audit controls under 45 CFR 164.312(b), and confirm retention periods with your data protection officer. Log storage and access to those logs should also be controlled, since audit records that anyone can edit carry little weight.

Document encryption as a configuration record that names each connection and each store. Cover TLS on client, federation and TI connections, the database encryption setting for PostgreSQL, encryption for backups and object storage, and how keys are generated, stored and rotated. The HIPAA Security Rule treats transmission security under 45 CFR 164.312(e)(1) as a required safeguard, and encryption specifications are addressable, so your record should state the decision and the reason. Federation runs on port 8448 by default, so the record should show the listener configuration and any firewall rule that restricts it. Confirm current settings against your own environment, since defaults change between releases.

Any party that creates, receives, maintains or transmits ePHI for you needs a written agreement that meets the requirements in 45 CFR 164.314(a)(2)(i). That includes the cloud or data center provider, the managed service partner and any subcontractor that touches the platform. The contract must require compliance with the Security Rule, flow the same terms down to subcontractors and require reporting of security incidents, including breaches of unsecured PHI. For German deployments, your data protection officer will also review processor agreements under GDPR. Keep a register of each party, its role and its contract date, and review it whenever the service scope changes.

An incident reporting path should name who detects the event, who decides it is reportable, and which regulator or contract clause applies. Define the trigger points in the runbook, such as unexpected federation traffic, a compromised administrator account or a failed backup restore. Time limits differ by rule, so confirm each obligation with counsel rather than assuming one clock applies everywhere. The HIPAA business associate contract must require incident reporting to the covered entity, and NIS2 Annex I lists health as a sector of high criticality, which may bring additional reporting duties for some organizations. Test the path with a tabletop exercise and keep the record.

Auditors look for a dated record of each upgrade, the version before and after, the test evidence and the approver. For Synapse, keep the release version and the upgrade notes that applied, because the upgrade notes warn that rolling back can be difficult due to database schema changes. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer, so record which runtime versions were in use at each date. Keep the Helm chart values, image digests and cluster version history in version control. Confirm your patch cadence and approval steps with your security team before you rely on them as evidence.

The evidence can be prepared by your team, a partner or both, but the sign-off must come from accountable people inside your organization. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and it prepares controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Agree in writing which evidence artifacts the engagement produces, who owns each one and how they are refreshed after changes. Ask any partner to show a sample evidence pack before you sign.

The cost is driven by the licensing edition, the Kubernetes platform you run, the work to connect to the telematics infrastructure, identity integration, security testing and the number of sites. Element offers ESS Community for non-professional deployments and evaluations, ESS Pro for professional and government use, and ESS TI-Messenger for German healthcare, deployed on Kubernetes with Helm charts. Confirm with Element which edition covers your use, because a practice or hospital cannot assume a free tier fits a production service. Each cost component should appear as its own line in a quote so you can see who is paid for what and what changes when you add sites or users.

One-time costs usually include planning, Kubernetes and Helm setup, the telematics connection work, identity integration, initial hardening and security testing, and migration of any existing messaging data. Recurring costs usually include the Element subscription for the edition you choose, hosting and storage on your infrastructure, backups, monitoring, upgrades and an optional support retainer. Ask the quote to split these into one-time and monthly or annual lines, and ask how upgrades are priced when Synapse or the Element charts move to a new release. Note that upgrades to Synapse can be hard to roll back because of database schema changes, so budget for a tested upgrade process rather than treating it as a single event.

A small practice can run the software itself only if it has someone who can operate a Kubernetes cluster, manage a PostgreSQL database, apply Helm chart upgrades, and handle the identity and telematics connection. Synapse recommends PostgreSQL for production and requires PostgreSQL 14 or newer from version 1.143.0, so the database side is not optional. Many practices instead buy the platform from their existing IT provider or from a partner, and keep the clinical and administrative decisions in-house. Decide early which tasks you will perform, which you will delegate and who holds accountability for a patient-facing messaging service.

Staff time depends on how much of the platform your own team builds and runs, and on how many sites and identity sources are involved. Expect IT to supply the Kubernetes environment, network and DNS changes, certificates, the identity provider connection and access to the telematics infrastructure. Clinical and administrative leads need time to define user groups, roles, who may message whom, and how staff are onboarded and offboarded. Ask a partner for a written list of tasks by role and an estimate of hours per role. Such an estimate should come from the written scope, not a generic figure from a brochure.

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. Ongoing support, upgrades and continuous testing are available as retainers, so operations can be handed over under a written agreement. DeployOpen does not issue certifications or attestations, and it does not publish a price list, so the operating model and retainer scope are set in a quote. Confirm the division of responsibilities for telematics connection, clinical sign-off and incident response before signing, because some of these depend on your provider and the national infrastructure.

A written scope should name the sites, user counts, identity sources, Element edition, Kubernetes platform, and the telematics connection work with the responsible party. It should list deliverables such as installed and hardened environments, backup and restore tests, documentation, and training, plus the acceptance criteria for each. Include exclusions explicitly, for example mobile device management or any work on the telematics infrastructure itself. Ask the partner to state the timeline in phases, the change process for scope additions, and the support model after go-live. Add the compliance evidence you need, such as audit controls and access records under 45 CFR 164.312, so the evidence is designed in from the start.

Ask the partner to list the telematics connection work as a separate line with its own assumptions. Confirm which connection standards, certificates, gateways and test environments are needed, who obtains access to the telematics infrastructure, and who pays for any third-party onboarding. Ask how the work is tested before go-live and whether a failure of the connection is covered by the support model. Confirm these points with Element and with the operator responsible for the telematics infrastructure, because DeployOpen cannot speak for those parties.