Building Hekara: An Open-Source, Self-Hosted Healthcare Management Platform

I've been working on an open-source project called Hekara, a self-hosted healthcare management platform designed for home healthcare agencies.

The motivation was straightforward: managing a home healthcare agency involves a lot of moving parts. Caregiver schedules, patient records, visit assignments, compliance requirements, billing and operational reporting often end up scattered across different tools.

I wanted to explore whether these workflows could be brought together in one platform, while giving organisations control over their software and infrastructure.

So I started building Hekara.

Here's what I've built, some of the engineering decisions behind it, and what I'm still trying to figure out.

What is Hekara?

Hekara is an open-source home healthcare agency management platform.

The goal is to provide a central place for agencies to manage their daily operations without depending entirely on closed-source, per-seat software.

Some of the implemented features include:

• Scheduling: Live day and week timelines for caregivers and visits.
• Shift management: One-click shift allocation with skill, availability and weekly-hour checks.
• Scheduling assistance: Explainable, rule-based suggestions for filling shifts and avoiding overtime.
• Patient management: Patient records, care plans and notes.
• Credential tracking: Monitor CPR, TB tests, background checks and expiry dates.
• Billing: Claims workflow covering draft, submitted, paid and denied states.
• Reporting: Operational reports, hours, fill rates and billing summaries.
• Access control: Separate admin, scheduler, caregiver and billing roles.

Some engineering decisions

I didn't want this to become a tightly coupled application that would be difficult to maintain or extend.

The current stack is:

1. Ports and adapters architecture

One of the architectural decisions I'm particularly interested in getting feedback on is the use of ports and adapters.

The core domain logic doesn't directly depend on the infrastructure.

Instead, the application communicates through interfaces for repositories, cryptography, realtime events, audit logging, queues, blob storage and secrets.

Currently, PostgreSQL is the implemented backend adapter.

The idea is to make it possible to introduce other infrastructure adapters without rewriting the core application.

Cloudflare and AWS adapters are part of the roadmap, not completed implementations.

2. Patient data protection

Healthcare software requires a different level of care around sensitive information.

I've implemented several security mechanisms:

• AES-256-GCM field-level encryption.
• Per-agency encryption keys and key rotation.
• HMAC-based blind indexes for searching encrypted fields.
• Server-side role enforcement.
• Tenant-scoped database queries.
• Append-only, hash-chained audit logging.
• Hardened session and authentication controls.

I have also written tests for tenant isolation and access-control boundaries.

An important clarification: Hekara has not undergone an independent security audit or penetration test. It is not HIPAA-certified, SOC 2-certified or independently certified under any healthcare security framework.

The project is currently in alpha and should only be evaluated with synthetic data.

3. Keeping the application lightweight

Another goal was to avoid unnecessary infrastructure complexity.

The current setup uses PostgreSQL and a relatively small application stack. It doesn't require Redis or a separate message broker.

The frontend client is approximately 50 KB gzipped, according to the current project documentation.

The intention is to make self-hosting practical for smaller organisations.

What still needs work?

Hekara is far from finished.

Some of the things on my roadmap include:

• Portable export/import tooling.
• Cloudflare infrastructure adapter.
• Improved multi-instance rate limiting.
• Better mobile experience.
• Additional billing workflows.
• Automated security checks for accidental exposure of sensitive data.
• More integrations with external healthcare systems.

I'd also like to improve the documentation and make contributing easier.

Where I need feedback

This is the part I'm most interested in discussing with other developers.

Architecture: Is ports and adapters a sensible approach for a platform of this size? Am I introducing unnecessary abstraction?

Security: What additional security tests or threat scenarios should I prioritise before considering a production deployment?

Database design: Are there particular challenges I should anticipate with encrypted fields, blind indexes and multi-tenant data isolation?

Product direction: Are there important home healthcare workflows I'm overlooking?

Open source: What would make a project like this easier for other developers to adopt and contribute to?

I'd appreciate criticism, particularly from people who have worked on healthcare software, enterprise applications, security engineering or open-source infrastructure.

The project

Hekara is released under the AGPL-3.0 licence.

GitHub: https://github.com/Srinivas26k/Hekara/

Contributions, bug reports, architectural suggestions and documentation improvements are welcome.

I'm building this independently and would like to make Hekara a genuinely useful project rather than simply another repository on GitHub.

If you've worked on something similar, I'd be particularly interested in hearing what you learned.