How we'd build your monitoring platform

Purpose and scope

This document lays out four ways we could build a monitoring platform for your critical equipment, across your 4 hospitals — with the honest trade-offs of each. Nothing is decided yet; the right approach follows a short, paid discovery phase. Fertility cryostorage at one pilot site comes first; the other hospital systems are later phases and not yet committed scope.

• Where you're starting from: a fertility centre group recently separated from a larger hospital chain, with 4 hospitals on your side and limited IT infrastructure in place today. The monitoring tool you have isn't giving you the visibility or confidence you need.
• Priority equipment: cryogenic storage of eggs, sperm and embryos (zero tolerance for breaches).
• Wider scope: blood bank, lab equipment, air conditioning, power (mains, UPS, generator).
• Core outcomes: one dashboard across sites, real-time breach alerts to staff, and a timestamped audit trail of readings, uptime, downtime, power outages and generator start times.
• Later phase: predictive and preventive maintenance.
• Stated assumption to test: devices already expose APIs or data feeds, so no hardware build is needed. "Can the equipment stream data?" below shows this holds only partly.

Out of scope for phase 1

• Controlling equipment: the system is read-only. No commands to refrigeration, LN2 filling, generators or HVAC.
• Patient management, EMR, sample identity or witnessing, and specimen inventory.
• Sensor installation, calibration, repairs and electrical work: separate work packages by qualified partners.
• Predictive models that claim to forecast failures.

What the system commits to: measurable detection, escalation and evidence. It cannot guarantee that equipment will never fail or that stored material will never be lost; physical emergency response stays with the clinic and equipment suppliers.

Regulatory anchors (India)

This build follows Indian law and Indian accreditation only. Indian rules require alarms on the equipment itself; they do not require a data feed. Remote alerting and continuous records are required or strongly implied, which is what this system adds.

Medical device software risk. Positioned as equipment-performance monitoring, the system likely sits outside CDSCO's definition. Marketed as protecting reproductive material, it may not. The intended-use statement and product claims need a written assessment before scope and price are fixed.

Global guidance, deferred to a later phase. Some practices in this design, such as LN2 level sensing and quarterly alarm tests, also appear in overseas guidance; they are adopted here as NFN design choices, not as compliance claims. Formal alignment with global standards such as ASRM and ESHRE can be scoped later if you'd like.

Open question for discovery: whether you hold, or are pursuing, NABH or other accreditation that adds requirements.

Design principles and zero-tolerance requirements

The alarm path must never depend on a single component, network or person. These principles apply to every option below.

1. No single point of failure in the alarm path. Three independent layers: device alarm, on-site edge, central cloud (see Reference architecture).
2. Silence is an alarm. A sensor or gateway that stops reporting alerts as loudly as a threshold breach.
3. Alerts need acknowledgement. Unacknowledged alerts escalate up an on-call ladder: SMS, then voice call, then the next person. Escalation resumes if an acknowledged incident is not resolved in time.
4. Muting is time-boxed and logged. Every suppression has an expiry, a named person, a reason and an audit entry. This targets the failure mode in the RBMO review.
5. Alarm thresholds sit inside the regulatory band. Staff get warned before the legal limit, not at it. Limits come from the clinic's clinical owner, never from NFN.
6. Monitoring is independent of the equipment. Where possible, a separate sensor and power path, not only the device's own controller. Specialist vendors design this way (HospiMedica).
7. Power-failure survival. Alarm hardware runs on UPS or generator, consistent with Schedule F's continuous-power requirement for blood bank storage.
8. Tested, not assumed. End-to-end alarm drill per sensor at commissioning, then at least quarterly. No Indian rule sets a test frequency; this is an NFN design choice.
9. Tamper-evident audit trail. Append-only, with device and server timestamps. Gateways and servers sync to NIC or NPL time servers, as CERT-In directs (JSA).
10. Freshness is shown, not assumed. The system detects stale, cached, frozen or out-of-order data. A gateway heartbeat does not prove each sensor is reporting. "Last received" and "last measured" are shown separately when they differ.
11. Replayed data is labelled. Data backfilled after an outage is tagged as replayed and never reopens an old incident as if it were live.
12. Unknown is never green. A sensor with no valid recent data shows as unknown or failed, not in range.
13. Timing is an end-to-end budget. Sensor sampling + transmission + processing + notification + human acknowledgement + travel and action must fit inside the intervention window the clinical lead sets, with an agreed margin. A faster dashboard does not help if the source reports every few minutes.

Can the equipment stream data?

Mostly yes, but in three tiers. Discovery must place every unit in one tier, because the tier decides whether we read the device or add sensors.

Three consequences for design:

• Tier B does not meet the audit-trail need alone. An alarm contact says that a unit breached, not the readings before and after.
• Cryo gets two paths where possible: the controller's data plus an independent sensor (principle 6).
• Sensor placement is a clinical choice. A probe in vapour reads warmer as LN2 falls. In one test on a well-insulated 20 L dewar, temperature went from −150 °C to 0 °C in eight hours after the liquid ran out; less efficient dewars warm faster (Networked Robotics). Level or weight sensing warns earlier (ASRM).

Power and HVAC follow the same model: UPS units usually offer SNMP cards, and building systems often speak BACnet. Split air conditioners typically expose nothing and need a room sensor. These three are to be confirmed per unit in discovery.

The cryo room also needs a low-oxygen alarm: rooms holding dewars should have one, especially with poor ventilation, and it can indicate an LN2 leak (Vitrolife). It protects staff, so it needs its own response procedure.

Vendor platforms and APIs: a feed is not the same as usable data

Where equipment reports through a vendor's monitoring platform, access to that platform's API is usually a commercial feature, and it can change or disappear with the subscription. Two established vendors show the pattern:

What to prove in discovery for every vendor feed, not just confirm on a checklist:

• Freshness: sampling interval, publication interval, typical and worst delivery delay.
• Fidelity: are values raw or averaged, rounded or cached? Are source timestamps, units and validity flags included?
• Outage behaviour: what happens to readings and alarms during network loss, reboot and power loss; how much history is buffered and whether the API can retrieve it.
• Commercial terms: licence cost, which plan includes API access, and whether access and data export survive cancelling the vendor subscription.
• Rights and limits: permission for NFN to integrate, rate limits, a dedicated read-only service account rather than a staff login, and notice of breaking API changes.

If the only data path is polling a vendor cloud, the system is remote supervision with that dependency. It cannot claim independent protection during a vendor-cloud or internet outage.

Reference architecture: three alarm layers

Every option implements the same three layers. They differ only in what software fills layers 2 and 3. Each diagram below is interactive: search, focus a component, trace a path or open it full screen.

Each layer keeps working when the one after it fails.

The power audit trail comes from the edge: mains loss and generator start times from the generator controller or transfer switch (Modbus or dry contact), and UPS state via SNMP.

Power events are recorded separately where signals exist: mains lost, generator start, generator running and stable, transfer switch changeover, critical load restored, mains returned, retransfer. "Generator running" does not prove the freezer's circuit had power. A lost network connection is recorded as "communication lost", not a power outage, unless a power signal confirms it.

Level 1: system context

Who and what the system talks to. The specialist cryo vendor appears only in Option D, shown below.

Level 2: inside a site edge

The same logical parts exist in every option; only who supplies them differs (see the options below).

Alarm lifecycle

An alarm has two tracks that move independently: the equipment's condition, and the staff response. A reading can return to normal while the incident still needs review, and a person can acknowledge an alarm while the condition is still dangerous. Every transition on both tracks is written to the audit log with who and when.

Condition track

Response track

Alarm classes

Admin staff can coordinate a response but should not be the only recipients where clinical or equipment expertise is needed.

A breach, end to end

The siren sounds locally at once. The edge sends its own SMS only when the central platform does not confirm the alert; the confirmation window is a design decision for discovery.

Option A: ThingsBoard (open-source platform, self-hosted)

Configure and extend an existing open-source IoT platform. Fastest route to a working system; least NFN-owned IP.

How it maps to the layers

• Layer 2 (edge): ThingsBoard Edge at each hospital. Local alarms fire without server connectivity; data is stored locally and synced when the link returns. Up to 1,000 devices per Edge instance.
• Protocol collection: ThingsBoard IoT Gateway connectors for Modbus TCP/RTU, SNMP, BACnet, OPC-UA, REST/HTTP, plus custom Python connectors.
• Layer 3 (central): ThingsBoard server. Its rule engine raises alarms on telemetry, attribute changes, device inactivity and user actions; alarms propagate up an entity hierarchy (thingsboard.io). Alarm rules support duration conditions, schedules and clear conditions (docs).

The siren/GSM integration at the edge and the escalation companion service would be built by NFN Labs on top of the platform.

Pros

• Apache 2.0 licence: free for commercial use, including hosting as SaaS (thingsboard.io).
• Offline edge alarms and store-and-forward already exist, which covers the hardest zero-tolerance requirement.
• "Silence is an alarm" is built in via inactivity alarms.
• Protocol coverage matches the equipment tiers without writing drivers.
• Portable: self-hosted on any cloud or on-premises, so no hyperscaler lock-in.

Cons

• Least differentiation: NFN's value is integration and configuration, not a product it owns.
• The escalation ladder with acknowledgement, time-boxed mutes and Indian SMS/voice providers will likely need custom rule chains or a small companion service.
• Some features are in the paid Professional Edition only; which ones this project needs is to be confirmed.
• NFN Labs takes on operating the platform, its database, upgrades and backups.
• Dashboards are configurable widgets, not a bespoke UI; heavy UX customisation fights the platform.

Option B: AWS-native, built ground up

NFN builds the application on AWS's core IoT building blocks. Highest ownership and data stays in India; more build effort than A.

What Greengrass is, and what "we build on Greengrass" means

AWS IoT Greengrass is an open-source edge runtime plus a cloud service for deploying and managing software on devices. It is a host for software, not an alarm product. At each hospital it would run on an industrial PC and give us:

• Packaging and remote deployment of our code as versioned "components", pushed from the cloud to all 4 sites.
• Local messaging between components, and MQTT to AWS IoT Core (feature matrix).
• Ready-made protocol adapters: Modbus-RTU, Modbus-TCP and EtherNet/IP (Greengrass FAQs). The Modbus-RTU adapter needs a serial connection to the device network and runs on Linux only (docs).
• Stream manager to buffer data locally and export it to AWS services (docs).

What Greengrass does not give us, so NFN writes it as components: the local alarm engine (thresholds, durations, missed-heartbeat detection), siren and strobe control, the GSM modem SMS/voice fallback, SNMP and BACnet collectors, and the local audit buffer. That is the meaning of "we build it on Greengrass": Greengrass runs and updates our edge software; the edge logic itself is ours.

Cloud layer (layer 3)

• Ingest: AWS IoT Core over MQTT/TLS. Each gateway authenticates with a registered X.509 certificate (aws-samples).
• Alarm and escalation service: NFN code on ECS or Lambda; current device state in DynamoDB; a scheduled missed-heartbeat check.
• Readings store: Timestream for InfluxDB or PostgreSQL.
• Audit log: S3 with Object Lock in compliance mode, where no user, including the account root, can overwrite or delete a record during its retention period (AWS docs).
• Region: an Indian AWS region, so all data stays in India.

Everything inside the site box and the alarm service is NFN-written; AWS supplies the runtime, broker and storage.

Pros

• NFN owns the product and IP; reusable for other hospitals.
• Bespoke dashboard and workflows; no platform constraints on UX.
• Mature per-device certificate security and immutable audit storage.
• Remote deployment and updates to every site are handled by Greengrass.

Cons

• AWS has retired the higher-level IoT services that would have shortened this build: IoT Events ended support on 20 May 2026 (AWS); IoT Analytics ended on 15 Dec 2025 (AWS); Timestream for LiveAnalytics closed to new customers on 20 Jun 2025 (AWS). The alarm logic is therefore ours to build and maintain.
• AWS's free-tier IoT page still lists IoT Events (AWS), so marketing pages are not a reliable guide to service status.
• Greengrass does not encrypt stream data stored on the device, or data passed between components on it; it relies on file permissions and full-disk encryption, if enabled (AWS). Disk encryption and local access control must be designed in.
• S3 Object Lock stops archived records being altered or deleted, but it does not prove a sensor was accurate or that every event was captured. Retention periods must be agreed before enabling compliance mode, which cannot be reversed.
• Higher build effort and more moving parts to operate than A.
• Medium lock-in: IoT Core, Greengrass and DynamoDB are AWS-specific.

Option C: Cloudflare-native, built ground up

NFN builds the cloud layer on Cloudflare Workers and Durable Objects, matching the stack NFN already uses for Punchcard. Elegant alarm model; weakest on India data residency and edge tooling.

How it maps to the layers

• Layer 2 (edge): entirely NFN-built. Cloudflare has no edge runtime equivalent to Greengrass or ThingsBoard Edge, so we write the gateway agent: protocol collectors, local alarm engine, siren and GSM control, store-and-forward buffer, and an update mechanism.
• Ingest: gateways push readings over HTTPS or WebSocket to Workers. Cloudflare's former MQTT broker, Pub/Sub, is no longer in the product list, and its docs URL now redirects to the docs homepage (Cloudflare docs); treat it as unavailable.
• Alarm state: one Durable Object per sensor holds its state and sets a timer for when the next reading is due. Alarms have guaranteed at-least-once execution, with automatic retries on failure (Cloudflare docs). If the reading does not arrive, the timer fires the alarm: "silence is an alarm" by design.
• Storage: D1 for configuration and alarm records; readings in R2 or an external Postgres via Hyperdrive.
• Admin access: Cloudflare Tunnel gives outbound-only connections with no open ports (Cloudflare docs).

The Durable Object timer is reset on every reading; if it fires, no reading arrived in time and the sensor goes into alarm.

Pros

• Strong fit with NFN's existing Cloudflare skills and tooling.
• The per-sensor timer model is a clean, low-code way to implement missed-heartbeat alarms.
• Low operations burden: no servers to patch in the cloud layer.
• NFN owns the product and IP.

Cons

• No India data residency. Durable Objects can be pinned only to the EU or FedRAMP data centres (Cloudflare docs); D1 has the same two options (Cloudflare changelog). Equipment telemetry is not patient data, so this may be acceptable; your own policy decides.
• Highest build effort: the whole edge layer, including remote updates, is NFN's to write and maintain.
• No managed MQTT broker, so standard MQTT devices need an NFN-run broker or protocol translation at the edge.
• Storing years of time-series readings needs a store outside D1; to be designed.

Two Indian rules sharpen the residency question for this option: CERT-In requires covered entities to keep ICT logs for 180 days within India (JSA), and CDSCO asks whether hosted medical device software runs on a MeitY-empanelled cloud (CDSCO). Whether either applies depends on your organisation's status and the product's intended use; both are discovery questions.

Option D: Specialist vendor for the cryo room, NFN platform for the rest

A hybrid: a reproductive-medicine monitoring vendor covers the highest-risk area, and NFN's platform (A, B or C) covers blood bank, lab, HVAC and power, pulling in the vendor's alarms. Lowest clinical risk for cryo; adds a second vendor and licence.

The dotted link is the key unknown: without a vendor API or export, the unified dashboard cannot show cryo data.

Example vendor: XiltriX (named as an example, not an endorsement)

• Offers fully managed monitoring-as-a-service built for IVF and ART labs, with 24/7 support and configurable alarm escalation (XiltriX).
• Monitors power supplies, LN2 levels in bulk tanks, CO2 line pressure and lab air quality, not just fridge temperature (XiltriX).
• Lists a case study with an Indian fertility group, Ferty9 (XiltriX).

Pros

• Proven, specialist design for the zero-tolerance area; sensor placement and cryo know-how come built in.
• Vendor provides 24/7 support and local field installation.
• NFN still delivers the unified dashboard and hospital-wide scope.

Cons

• Recurring licence cost; pricing not researched yet.
• Integration depends on the vendor exposing an API or data export; not yet confirmed, and no public XiltriX API documentation was found. See "Vendor platforms and APIs" for what to prove.
• Two systems for staff to learn, unless NFN's dashboard becomes the single front end.

Side-by-side comparison

No option wins on every axis; the trade is speed and proven parts (A, D) against ownership and bespoke UX (B, C). Ratings are qualitative and relative to each other; effort estimates follow discovery.

Cross-cutting: security, notifications, audit trail

These apply whichever option is chosen.

Security

• Monitoring devices on their own network segment, separate from clinical and office networks.
• Edge gateways connect outbound only over TLS, with a unique credential per gateway; no inbound ports at hospitals.
• Staff sign-in with SSO and MFA; role-based access scoped per hospital.
• Changes to alarm thresholds are themselves audited, with who, when, old and new value.

Notifications in India

• Business SMS needs TRAI DLT registration: the sending entity, sender IDs and every message template must be registered on an operator DLT portal (WebEngage). Unregistered messages are blocked at network level without an error (Message Central). Start early; you'd be the registering entity.
• Parallel channels: voice call, app push or WhatsApp, and an on-site GSM modem that works without internet.

Audit trail

• Every reading, alarm, acknowledgement, mute and threshold change is recorded with device time and server time.
• Gateways time-synced so events across sites line up.
• Power events: mains loss, generator start and stop, UPS on battery, each timestamped from the generator controller, transfer switch or UPS.
• Where the device keeps its own tamper-proof log (for example the TEC 3000's 30,000-event memory, Core Cryolab), it can backfill gaps after an outage.
• Record retention period: open question, tied to your own regulatory advice.

Reporting: define "uptime" before promising it

These are reported as separate figures, because combining them gives false reassurance.

Example: a day with 23 hours of valid in-range readings and 1 hour with no data is reported as about 95.8% coverage, 100% within limits over the observed time, and 1 unknown hour. It is never reported as a full day of safe conditions. Backfilled data can complete the history but cannot retroactively restore real-time supervision.

Minimum event record

• Every reading: site, asset, sensor, metric, value, unit, source timestamp, receipt timestamp, sequence or event ID, quality state, source system, schema version, live or replayed.
• Every incident: trigger evidence, rule version, severity, participants, delivery attempts, acknowledgements, actions, recovery evidence, closure reason, related configuration changes.
• Fields a source does not supply are recorded as absent, never invented.
• Application actions such as acknowledgements are audited by the application itself; cloud provider logs do not capture them.

Assumptions

Each assumption below is to be confirmed in discovery; any that fails changes scope or cost.

1. Every in-scope unit has at least an alarm contact (tier B). Tier C units get off-the-shelf retrofit sensors; no custom hardware is designed.
2. Scope is your 4 hospitals, starting with fertility cryostorage at one pilot site. Other hospital systems are later phases, and the other side of the split is out of scope.
3. Monitoring data is equipment telemetry only. Linking alarms to patient or sample IDs is out of scope for phase 1.
4. Each site has internet access, but it is not assumed reliable. A 4G backup link is part of the design.
5. Hosting is in an Indian cloud region (Options A, B), in either your own account with delegated NFN Labs access, or an NFN Labs-managed account under a service contract. Either works if ownership of the account, data, keys and recovery access is documented.
6. Equipment vendors will share Modbus register maps or API access, and confirm that wiring into alarm terminals does not void warranty.
7. You'll name clinical owners who approve thresholds and alarm-response procedures; NFN Labs does not set clinical limits.
8. Predictive maintenance is a later phase and needs a baseline of stored readings plus maintenance and failure records first. Data readiness is reviewed after several months; no fixed period is promised, because it depends on how many real failures occur.

Prerequisites

You'd need to provide these before build can start; the owner column shows who is responsible.

Responsibility boundaries

One named person is accountable for each boundary; "the vendor handles it" is not an operating model.

Phasing and open questions

Discovery comes first because it tests the riskiest assumption: what the equipment can output. The option choice follows it.

The pilot stores raw readings from day one, so predictive maintenance has a data baseline later.

Decision gate after discovery

Pilot acceptance tests

Tests use manufacturer test modes, non-clinical equipment or simulated signals; unsafe storage conditions are never created to prove an alarm.

Open questions for discovery

• What hasn't worked with the monitoring tool you have today — software, sensors, integration or process? Understanding this shapes everything else.
• How many units per site, and which tier (A, B, C) is each?
• Does hospital or group policy require data to stay in India? This decides whether Option C is viable.
• Are you pursuing NABH or other accreditation that would add requirements?
• Required retention period for monitoring records?
• Is there a building management system at any site?
• Would you like NFN Labs to operate the system after go-live, or keep it with your own team?
• Budget range and target go-live for the pilot site.

Full interview questions and evidence requests: Discovery kit

References

Regulatory (India)

• ART (Regulation) Rules, 2022
• CDSCO blood bank guideline (Schedule F Part XII-B)
• Drugs Control: blood bank requirements
• CDSCO Guidance on Medical Device Software (2026) · NatLawReview summary
• DPDP Rules 2025 phased commencement
• CERT-In Directions, April 2022 (JSA summary)
• NABH · NABH is voluntary (Bajaj Finserv)

Clinical and global references (not compliance claims)

• ASRM: Cryostorage of reproductive tissues in the IVF laboratory (2020)
• ESHRE Good Practice in the IVF Laboratory, 2026
• RBMO: Cryostorage management review (2023)

Equipment and vendors

• MVE TEC 3000 brochure (Chart) · MVE TEC 3000 (Core Cryolab)
• DSE7420 MKII generator controller
• Blood bank refrigerator datasheet with RS-485 Modbus
• Haier 4 °C blood bank refrigerator · Haier HXC-279T datasheet
• Vitrolife: monitoring LN2 tanks in IVF · Networked Robotics: monitoring dewars by weight · HospiMedica: independent IVF monitoring
• DicksonOne REST API · Dickson API keys · Dickson expired subscription
• Vaisala viewLinc · viewLinc licensed features · viewLinc REST token
• XiltriX monitoring-as-a-service · XiltriX IVF · XiltriX case studies

Platforms

• ThingsBoard · ThingsBoard Edge · ThingsBoard IoT Gateway · ThingsBoard alarm rules
• AWS IoT free tier page · Greengrass feature matrix · Greengrass FAQs · Greengrass Modbus-RTU adapter · Greengrass stream manager · Greengrass stream data security
• AWS IoT Events end of support · AWS IoT Analytics end of support · Timestream for LiveAnalytics availability change · S3 Object Lock · AWS IoT X.509 sample
• Cloudflare docs home · Durable Objects alarms · Durable Objects data location · D1 jurisdiction changelog

Notifications

• WebEngage: TRAI DLT regulations · Message Central: India SMS guideline