NFN LABS · Hospital IoT Monitoring
Discovery

What we'll ask, and why

Before anything is built, a short discovery phase confirms what your equipment can actually tell us. This is the exact set of questions and evidence we'd work through together.

NFN Labs · September 2026

This is what we'll ask, and why, during the paid discovery phase — across your clinical, technical, facilities and commercial stakeholders, not one long form for a single person. Sharing it upfront is intentional: we want you to know exactly what to expect before you commit.

First meeting: twelve questions

Hold a 60–75 minute session with the sponsor, the lead embryologist, the administrator and the biomedical or facilities owner.

  1. What happened, or nearly happened, that made this urgent? A specific event, date, equipment and how it was discovered.
  2. If we could start with only one area, which storage assets come first? Exact rooms and quantities.
  3. What are the actual storage technologies? See the model labels and current monitoring screens.
  4. What does the current software fail to do: missing data, unreliable alerts, poor reports, hard to use, subscription problems, or no support?
  5. At 2 a.m., who receives an alarm, who can enter the site, and who can act? Who are the backups?
  6. How do you know today that the alarm system itself works? Recorded tests, missed alarms.
  7. What evidence would make you trust a first deployment?
  8. Who approves storage limits, escalation times and incident closure?
  9. After the split from the hospital chain, who controls equipment contracts, API credentials and vendor relationships?
  10. Who signs the purchase, who holds the budget, and who can block deployment?
  11. Is there a deadline tied to an opening, inspection, contract renewal or recent incident?
  12. Would you fund a short assessment that produces a tested integration and a fixed pilot scope?

End with a named clinic coordinator, vendor introductions, agreed evidence requests and a review date.

Question bank by stakeholder

Clinical: lead embryologist and medical director

  • What is stored, in which vessel types, under whose responsibility? Which units are in use, standby or decommissioned?
  • Where do limits come from: manufacturer, clinic procedure, or adopted standard? Are there separate warning, action and recovery limits?
  • What is the maximum acceptable detection delay per failure scenario, and the time to acknowledge, reach site and act?
  • Are controller readings enough, or is an independent probe required? How are probes placed, calibrated and checked for drift?
  • What happens during refilling, routine access, calibration or maintenance? Which events must alert even during planned maintenance?
  • What backup storage, supplies and people are available? Which manual checks continue after go-live?

Equipment and interfaces: equipment maker, service provider, biomedical owner

  • Make, model, serial number, firmware, age and warranty status of each unit.
  • Does each feed come from the equipment, a logger, a gateway or a vendor cloud? Which protocols: HTTPS, MQTT, OPC UA, BACnet, Modbus?
  • Are native alarm events available, or only measurements? Sampling, publication and worst observed delivery intervals?
  • Are values raw, averaged or cached? Are source timestamps, units and validity flags included? Can a successful response contain old values?
  • What happens to readings and alarms during network loss, reboot and power loss? How much history is buffered, and can the API retrieve it?
  • Rate limits and retry rules? Does API access cost extra, and does it survive cancelling the platform subscription?
  • Is NFN Labs integration contractually permitted? Is a sandbox, spare unit or supported test mode available?
  • Can the clinic get a dedicated read-only service account instead of a staff login?

Power and connectivity: facilities, electrical and network owners

  • Which assets, loggers, gateways, routers and alarms have backup power? Do they share a circuit, UPS or switch?
  • Is internet redundancy physically independent? Does cellular coverage work in the storage room? Is wired connectivity available?
  • Can the system see mains failure, generator start, generator stable, transfer switch changeover and load restored separately, at the critical circuit?
  • Who approves firewall rules, network segmentation and remote access? What can be safely simulated, and when?

Alarms and response: clinical lead, administrator, on-call staff

  • Primary and secondary responder per asset and shift; cover for leave and holidays.
  • Which channels actually work overnight: local alarm, voice, SMS, app? What counts as acknowledgement?
  • Who may pause an alarm, for how long, and with whose approval? What if the primary responder is unreachable?
  • Which alerts are ignored today because of noise? Language and accessibility needs? How often will contact details be tested?

Evidence, privacy and governance: quality, legal, IT

  • Which inspection, accreditation, insurer or audit requirements must reports meet? Which accreditation scheme and edition?
  • How are uptime, downtime, excursions and missing-data periods defined today? What retention period applies to each record type?
  • Who owns cloud accounts, data, encryption keys and recovery access? What records remain with the former hospital chain?

Commercial: sponsor, finance, procurement

  • Legal contracting entity, approval chain and budget for assessment, build and annual operation separately.
  • What does the current or competing system cost, and what is included? Which contracts can end, when, and at what cost?
  • Are you looking for a product licence, a bespoke build or a managed service? Expected IP, hosting, data export and exit terms?
  • What acceptance evidence releases each payment? What would make you reject the pilot even if the software works?

Evidence to request

Use a secure exchange and request device data without patient identifiers.

Evidence Owner Why it matters
Asset list and model-label photos Biomedical or clinic coordinator Establishes exact equipment
Manuals, sensor specs, calibration records Equipment maker or quality lead Meaning and reliability of readings
API documentation and access process Equipment maker or platform owner Proves integration feasibility and rights
Redacted raw payloads and 7–14 days of history Vendor or IT Shows cadence, gaps and data quality
Current screens and report examples Operations Shows adoption and reporting failures
Alarm, emergency and maintenance procedures Embryologist or quality lead Defines workflow and rule ownership
On-call roster and escalation tree Administrator Shows real response coverage
Network and power diagrams, including UPS and transfer switch Facilities Finds shared failure points
Past incident and service records Operations or equipment maker Relevant failure cases and baseline
Current software and equipment licence agreements Procurement API costs and cancellation dependencies
Applicable inspection or accreditation requirements Quality or legal Requirements-to-evidence matrix

Prepared by NFN Labs, September 2026.