BeeLink CN
BeeLink CN is a February 2026 MVP for home-care emergencies: simulated vitals over MQTT, threshold triage, ambulance dispatch and a hospital capacity service.
Last updated: October 1, 2026
Connecting home vitals to emergency response
BeeLink CN set out to connect a patient's vital signs at home to emergency response: an alert when a reading crosses a threshold, an ambulance dispatch, and a hospital with free beds. The code is public in the BeeLink-CN GitHub organization, whose contracts repository describes a "home healthcare and emergency response platform".
The repositories are named for 5G, and no code depends on it. Readings arrive over MQTT, the services exchange events over NATS JetStream, and browsers receive them over WebSocket.
Two decisions recorded in the contracts repository
The contracts repository holds the platform's JSON Schema, OpenAPI and AsyncAPI definitions and calls itself the single source of truth for them. Two architecture decision records sit beside them, both dated 8 February 2026. ADR-001 fixes naming: events take the form <domain>.<entity>.<action> with a past-tense verb, as in vitals.recorded. ADR-002 puts every API and event contract on semantic versioning, so a breaking change shows in the major version.
What the February 2026 MVP implements
Simulated home vitals
Readings arrive as JSON on the MQTT topic home/<patient_id>/vitals. The data contract carries heart rate, SpO2, systolic and diastolic blood pressure and body temperature. No sensor or wearable was integrated: a simulator publishes random readings every two seconds. The ingestion service validates each reading, stores it in TimescaleDB and republishes it on NATS JetStream as vitals.recorded.
Threshold-based triage
A rules engine checks heart rate and SpO2 against configurable thresholds. By default it flags heart rate above 120 or below 50 bpm on two consecutive readings, and SpO2 below 90% on the first. Each alert carries a severity (low, medium or high) and a fixed suggested action. Blood pressure and temperature are not evaluated, and nothing learns from past data; the service's README calls the engine an MVP that is "ML-ready".
Ambulance dispatch with placeholder assignment
The dispatch service ignores low-severity alerts. For the rest it records a dispatch and assigns the first ambulance and hospital ID from a configured list, a placeholder the code labels "MVP: Dummy". It does not consult the capacity service.
Hospital capacity recommendations
The capacity service stores bed and ICU counts per hospital, posted to /capacity/update or sent as a NATS message. Its recommendation endpoint lists hospitals within a 50 km straight-line radius by default that have free beds and data under ten minutes old, sorted by availability and then distance. No hospital information system feeds it.
A WebSocket gateway and an event dashboard
A WebSocket gateway streams the NATS events to browsers. A React and Vite dashboard lists them with their raw JSON and has a mock mode that generates its own data. There is no mobile app.
Tech Stack
- TypeScript on Node.js for every service
- MQTT through Eclipse Mosquitto for incoming readings
- NATS JetStream for events between services
- PostgreSQL for storage, with TimescaleDB for vitals
- JSON Schema, OpenAPI and AsyncAPI for the contracts
- React and Vite for the dashboard
- Docker Compose for the local development stack
- GitHub Actions for CI in six of the eight repositories
Where BeeLink CN stands in October 2026
BeeLink CN was built as an MVP between 8 and 15 February 2026, across eight public repositories: the contracts, the local infrastructure, five services and the dashboard. There have been no commits since 15 February 2026. The triage service publishes alerts in a different shape from the one the dispatch service validates, and the shared Docker Compose stack, marked for local development only, does not include the dispatch and capacity services.