Healthcare device interoperability is a solved problem in theory and a mess in practice. Every manufacturer builds its own ecosystem, its own app, its own cloud service. A blood pressure monitor from one vendor cannot talk to a medication dispenser from another, and neither can talk to the nurse call system in the same facility. Healthcore is an open-source project that takes a different approach: a protocol-agnostic architecture that standardizes data from any device and makes it available through a single API, running on whatever hardware you already have.
The project describes itself as "Home Assistant or OpenHAB, but specialized for healthcare." The comparison is apt. Home Assistant solved the smart home interoperability problem by building bridges to every protocol and device, then exposing a unified API. Healthcore applies the same pattern to medical and wellness devices, with the additional requirement that the data flows through a person-centric model rather than a room-centric one.
The architecture matters because healthcare data is heterogeneous by nature. A pulse oximeter speaks Bluetooth Low Energy. A motion sensor uses ZigBee. A weather station might use LoRa. A fitness tracker talks to Google Health or Garmin Health through REST APIs. Healthcore bridges all of these into a single MQTT message bus, normalizing the data into a common format before it reaches the application layer.
The bridge pattern and protocol adapters
Healthcore runs as a collection of Node.js services. An MQTT broker handles inter-service communication. A server provides the REST API and server-sent events for interfaces. Each supported protocol gets its own bridge service: bridge-bluetooth, bridge-zigbee, bridge-lora, bridge-http, and bridge-integrations for external APIs like Google Health and Garmin Health. Thread support is planned.
Each bridge contains a converters directory with JavaScript classes that transform raw device data into structured JSON. A converter for a ZigBee motion sensor takes the binary payload from the radio and produces an object with properties like occupancy, battery level, and tamper status. The converter extends a ConverterStandard base class, which handles the common plumbing of device registration and property management.
The converter model is deliberately simple. Each converter is a single JavaScript file with a static productName that must match the device's reported model name exactly. The class defines which properties the device exposes, whether each property is read-only or writable, and how raw values map to human-readable formats. This is not a complex SDK. It is a convention for writing data transformation classes that a Node.js runtime can load and execute.
The project actively solicits converter contributions. The README suggests using GitHub Copilot, Claude Code, or Codex to generate converters for new devices by prompting with the device model and pointing to existing examples. This is one of the more practical uses of LLMs in open-source development: generating boilerplate code that follows a well-defined pattern, where the output can be validated against real device behavior.
Three separate identity concepts
Healthcore distinguishes between three concepts that other systems conflate. The physical room where a device is installed (devices.roomID) is separate from the person who owns or uses a personal device (devices.individualID), which is separate from the person's primary residence or room (individuals.roomID). This three-way split matters for healthcare because a motion sensor in a bedroom tells you about the room, but a wearable on a person tells you about the person regardless of where they are.
The separation enables scenarios that do not map to a single room. A person wearing a fitness tracker might be at home, at the doctor's office, or walking outside. The device's data follows the person, not the location. Meanwhile, a blood pressure monitor in the bathroom reports data tied to that room. Healthcore can correlate the two: "the person who lives here used the blood pressure monitor this morning and their resting heart rate from the wearable was elevated."
Device groups extend this further. Motion detectors, blood pressure monitors, and fitness trackers can be grouped by function, by person, or by location. Scenarios can trigger actions based on group conditions: "if all motion detectors in the living room are inactive for two hours and the person's wearable shows they are home, send an alert."
Automation and reporting
Scenarios in Healthcore are trigger-action pairs. A trigger can be a device value change, a time-based condition, or a combination of factors. An action can send an alert, update a device value, or call an external API. The scenario engine runs on the server and evaluates triggers against incoming device data in real time.
Alerts are a first-class concept. The API exposes alert lists, statistics, single-alert lookup, and status updates. A caregiver or family member can subscribe to alerts for a specific person or device group and receive notifications when conditions change. The alert system is independent of the scenario engine, so alerts can be generated by scenarios or by direct API calls.
For longitudinal analysis, Healthcore includes a reporting engine that can use a local LLM to generate natural language summaries of collected data. A GGUF instruct model runs on the host machine and processes a time range of device data into a report. The quick start guide demonstrates this with a week of motion sensor data: collect occupancy readings for seven days, call the report generation endpoint, and receive a summary of room usage patterns. The LLM runs entirely locally, so no patient data leaves the device.
Security and deployment
Healthcore ships unsecured by default to lower the barrier for development and testing. Production deployment requires configuring several layers. API key authentication is enforced through a header. CORS restricts which origins can access the API. TLS encrypts API traffic using locally generated certificates. MQTT authentication requires username and password credentials for broker connections. TLS on the broker side is automatic when a certificate is configured.
The project includes production start and stop scripts that use a process manager to restart crashed services. Logs are written to a dedicated directory. The Healthcheck dashboard, running on port 9990 by default, displays system status and data from the APIs. A Bonjour service advertises the server on the local network, so interfaces can discover it without manual configuration.
For Raspberry Pi deployment, the README includes a step-by-step setup script that installs Node.js, enables Bluetooth, clones the repository, and configures autostart. The ZigBee adapter path is auto-detected from /dev/serial/by-id. The same instructions work on any Linux system with minor adjustments to the package manager commands.
Why this matters
The healthcare device market is fragmented because manufacturers have economic incentives to keep it that way. Proprietary ecosystems lock in customers and prevent data from flowing to competing products. Healthcore's approach is to sit between all of these ecosystems and translate. A device from any manufacturer can join the network through a converter, and its data becomes available to any interface through the API.
For developers building health monitoring applications, this eliminates the need to implement a separate integration for every device. For caregivers and families, it means a single dashboard that shows data from all of a person's devices. For patients, it means their health data stays on their hardware, under their control, rather than being siloed in a manufacturer's cloud.
The project is open source and accepts contributions. The converter model makes it straightforward to add support for new devices: write a JavaScript class that maps raw data to properties, drop it in the converters directory, and submit a pull request. The LLM-assisted converter generation workflow lowers the barrier further, making it realistic for non-developers to add support for devices they own.
Healthcore is used by bulp.io, which builds healthcare hardware designed to work with the platform. The combination of open software and purpose-built hardware creates a complete stack for health monitoring that does not depend on any single manufacturer's cloud service or proprietary protocol. For teams evaluating open-source health infrastructure, Healthcore is worth watching as the project matures.