IoT in hospitals: building data beyond medical devices

General information, not legal advice (status: October 2026). EU rules (AI Act, GDPR, MDR) apply across the EU; the sections on IT security refer to German rules as an example, and other countries implement their own.

Search for IoT in hospitals and most of what you find is about medical devices: connected infusion pumps, patient monitors, asset tracking. This article is about something else – the building. Hospitals have hundreds of rooms used in very different ways, plant that runs around the clock and areas with special requirements. For many questions, standard building management systems and off-the-shelf sensor kits are enough. For some they are not: in research and pilot projects, in university hospitals, in specialist areas, or where an organisation’s own systems need to be connected. This article covers what building IoT can add, which wireless options fit, what the EU AI Act, data protection and IT security require, and how to scope a project for custom AI and IoT solutions properly.

Key points

• Building IoT measures rooms and plant, not people. A device is not a medical device as long as it has no medical purpose, and building IoT should be planned separately from clinical systems [5].
• Research on digital technologies in healthcare facility management names interoperability, scaling beyond pilots, cybersecurity and data privacy, and organisational adoption as barriers [1].
• Wi-Fi and LoRaWAN have different strengths: Wi-Fi offers high data rates and uses existing infrastructure; LoRaWAN is designed for small amounts of data, long range and long battery life, with transmit-time limits in the 868 MHz band [2][4].
• The EU AI Act has applied in general since 2 August 2026; after the amending Regulation (EU) 2026/1744, duties for high-risk systems under Annex III apply from 2 December 2027, and the AI literacy duty has applied since February 2025, in amended form since July 2026 [10][11][12]. Data protection and IT security belong in the project from day one [6][13][14].

IoT in hospitals: building data is not medical technology

The distinction sounds obvious, but it shapes the whole project. Under the EU Medical Device Regulation (MDR), a medical device is a product intended by its manufacturer for use in humans for specific medical purposes, such as the diagnosis, monitoring or treatment of disease [5]. A sensor that measures temperature, CO₂ or humidity in a room to support building operations has no such purpose.

That leads to clear ground rules for a building IoT project:

• Fix the purpose. The system supports building operations: indoor conditions, energy, plant. It does not diagnose, monitor or treat patients.
• No measurement of people. Room sensors measure the environment. Vital signs, people tracking or fall detection are different products under different rules.
• Separate from clinical systems. Building data does not run through medical devices or into clinical systems. The network connection is agreed with IT beforehand.

This boundary protects both sides: medical technology stays within its regulated framework, and the building project can stay as lean as a building project should be.

Smart hospital buildings: where data is still missing

“Smart hospital” usually refers to clinical workflows and administration. The building itself features less often. Yet hospitals generate building data every day – in the building management system (BMS), at meters, in individual sensors – that is rarely analysed room by room. In England, for example, HTM 03-01 expects the operation of ventilation systems to be monitored through a BMS [15]; plant data exists, but it describes the plant rather than the rooms it serves.

A systematic review of digital technologies in healthcare facility management analysed 74 peer-reviewed articles covering building information modelling, the Internet of Things, artificial intelligence and digital twins [1]. Publications on the topic have grown markedly since 2018. As barriers, the authors name interoperability between systems, difficulty scaling beyond pilot projects, cybersecurity and data privacy risks, and organisational adoption [1].

Those barriers match what slows building projects in hospitals in practice: data sits in different systems and formats, a pilot on one ward cannot simply be rolled out across a site, and every new network connection is a question for IT security.

Root causes: why standard solutions reach their limits

Specialist areas. Research labs, animal facilities, high-level isolation units, pharmacies or archives have their own requirements for conditions, access and cleaning. A standard sensor kit often does not cover them.

Legacy systems. Many sites run BMS from different generations and manufacturers side by side. Data has to be brought together from different protocols and exports.

Radio in existing buildings. Thick walls, basements, plant rooms and shielded areas make wireless planning in hospitals demanding. What works in an office building does not always work here.

Questions without products. Research and pilot projects often ask questions no ready-made product answers: a specific link between room bookings and indoor conditions, a model for one part of a building, control of a particular piece of plant.

IT security and data protection. Every networked device is a potential point of attack. In Germany, hospitals must take appropriate organisational and technical precautions, in line with the state of the art, to avoid disruption to the availability, integrity and confidentiality of their IT systems [13].

Common mistakes in hospital IoT projects

• Starting with technology instead of a question. Buying sensors first and deciding later what to learn leaves you with lots of data and few answers.
• Bringing IT in too late. Network, security and operations decide whether a project succeeds. They belong in the first meeting.
• Mixing building and clinical data. A project that also wants to use patient data becomes a different project in regulatory terms.
• Not designing the pilot to scale. A pilot that only works with one-off workarounds cannot be rolled out to further wards [1].
• Leaving operation and ownership open. Who changes batteries, who responds to flags, who maintains the room mapping? Without answers, systems go stale quickly.
• Promising AI before there is data. Models need data over time. Promising specific results in a funding bid puts the project under the wrong kind of pressure.

Building blocks of a hospital environmental monitoring IoT project

A building IoT project in a hospital consists of a few clearly separated components: sensors in rooms, a wireless or network route, a platform that maps data to rooms and analyses it, connections to existing systems, and people who work with the results.

Figure 1: Components of a building IoT project, kept separate from clinical systems and medical devices. Own illustration. Sources: [5][13][14].

IoT sensors for healthcare facilities: what is measured

Typical room readings are CO₂, temperature, relative humidity, particulate matter, volatile organic compounds, light and sound. Depending on the project, data that already exists is added: meter readings, plant status and set points from the BMS. What matters most is not the number of readings but their mapping: every value has to belong to a room with known use, position and size, or it is hard to interpret.

LoRaWAN or Wi-Fi in a hospital: healthcare wireless sensors compared

For wireless connections, buildings mainly use Wi-Fi and low-power wide-area networks (LPWAN) such as LoRaWAN; wired routes via the BMS are a third option. The choice depends on data volume, power supply, building structure and IT requirements.

Table: Wi-Fi, LoRaWAN and wired routes compared. Own compilation based on [2][3][4].

A comparative study of LPWAN technologies concludes that LoRa and Sigfox have advantages over NB-IoT in battery life, capacity and cost, while NB-IoT performs better on latency and quality of service [2]. A series of measurements in buildings by Dortmund University of Applied Sciences and Arts (published as a preprint so far) found that LoRaWAN reached the basements in all buildings tested, but also recorded packet error rates between 11 and 38% at several hard-to-reach measurement points [3]. For a hospital, the lesson is to test radio coverage in your own building rather than planning from a datasheet.

Fact & Feeling’s standard devices connect via Wi-Fi. Which wireless or network solution makes sense in a custom project is agreed with your IT team.

The platform: bringing data together

The real value comes when data from different sources is combined: new sensors, BMS, meters, room schedules. A platform has to map that data to rooms, store it over long periods and present it so that estates, nursing and management each get the view they need.

Digital twins: one term, many meanings

“Digital twin” is used in very different ways – from a full BIM model with every system to a floor plan showing live data. The review cited above counts digital twins among the technologies increasingly studied in healthcare facility management [1]. For a project, it helps to define exactly what is meant: which rooms, which data, which questions. A floor plan with room data is a sensible first step; a full building model is a separate, larger undertaking.

AI in healthcare real estate: models for rooms and plant

AI models can find patterns in building data that single readings do not reveal: rooms that regularly overheat at a certain time of day, plant that behaves differently than usual, links between use and indoor conditions. Where AI is also meant to support energy optimisation, the same rules apply: models need data over time, control needs clear limits, and conditions for patients and residents come first. Specific savings cannot be promised in advance.

Smart care home technology

Care homes are smaller, but the questions are similar: how warm do residents’ rooms get in summer, how well are they aired at night, how does a building behave across the year? For care homes, a lean setup with room sensors and clear responsibilities can be more useful than a large platform. Here too, building data stays separate from care documentation and residents’ personal data.

Legal framework: EU AI Act, GDPR and IT security

Figure 2: Four questions every hospital building IoT project should answer early. Own illustration, not legal advice. Sources: [5][6][8][9][13].

EU AI Act

The AI Act (Regulation (EU) 2024/1689) has applied in general since 2 August 2026; some parts have applied since February or August 2025 [11]. The amending Regulation (EU) 2026/1744 of 8 July 2026 (“Digital Omnibus on AI”, in force since 27 July 2026) postponed the duties for high-risk systems: to 2 December 2027 for systems under Annex III and to 2 August 2028 for systems under Annex I, i.e. AI in products such as medical devices [11][12].

Two provisions matter most for building IoT:

• Annex III, point 2 (critical infrastructure): High-risk systems include AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity [9]. Whether a particular building system falls under this has to be assessed case by case. Annex III systems can also fall outside the high-risk category where they pose no significant risk, for example when performing a narrow procedural task [8].
• Article 4 (AI literacy): Providers and deployers of AI systems must take measures to support the AI literacy of their staff and others operating AI systems on their behalf; since the 2026 amendment, they are not required to guarantee any specific level of AI literacy [10][12]. This duty has applied since 2 February 2025 [11].

AI that itself serves a medical purpose falls into a different category (Annex I together with the MDR) and is not part of a building project [8].

Data protection under the GDPR

Room readings such as temperature or CO₂ are, on their own, usually not personal data. The GDPR – and the UK GDPR – defines personal data as any information relating to an identified or identifiable natural person [6][7]. Room data can become personal data when it is linked to information about who is in a room and when – for example, a single patient room combined with bed-management data. The GDPR then applies; data concerning health is subject to the stricter rules of Article 9, and where processing is likely to result in a high risk, a data protection impact assessment under Article 35 is required [6]. That is why the data protection officer belongs in the project early. Fact & Feeling’s sensors measure rooms, not people, and Fact & Feeling does not process patient data.

IT security

National rules differ. In Germany, § 391 of the Social Code Book V requires hospitals to take appropriate organisational and technical precautions, in line with the state of the art, to avoid disruptions to the availability, integrity and confidentiality of their IT systems [13]. For building technology, the German Federal Office for Information Security (BSI) provides dedicated modules in its IT-Grundschutz compendium: “INF.13 Technical building management” and “INF.14 Building automation” [14]. Depending on size and classification, further duties may apply; your IT security team and its advisers clarify which.

Planning a pilot with custom IoT solutions

A custom project starts with a question, not with technology. One way to proceed:

1. Clarify the requirement. What question should be answered, for which rooms, with which existing data? Who uses the results?
2. Concept. Measurement, data routes, models and, where relevant, control – agreed with estates, IT, data protection and, where patient areas are involved, nursing and IPC.
3. Development. The solution is developed jointly and tested in a limited area.
4. Roll-out. Installation, training and handover to the team – including who operates what.
5. Further development. The solution grows as requirements change; the pilot is designed for transferability from the start.

For research projects on smart hospital buildings, the research question, data access and publication of results should also be agreed in writing beforehand.

How Fact & Feeling helps

Fact & Feeling measures room conditions with sensors for CO₂, particulate matter, volatile organic compounds, temperature, humidity, light and sound, connected via Wi-Fi. The platform shows rooms on the floor plan with live values, trends, issues and hints; more on platform and devices.

For IoT in hospitals beyond the standard, we offer custom AI and IoT solutions: tailored monitoring, custom AI models, automations and IoT connections – for facilities with special areas, owners with their own IT or building systems, and research and pilot projects. Existing systems such as BMS and meters are connected through data integration. For ongoing hospital environmental monitoring, devices stay in place with monitoring around the clock.

How this looks in different settings is described on the pages for hospitals and clinics on the way to a smart hospital and for care homes looking at smart care home technology. To discuss a pilot, use the contact page.

What Fact & Feeling does not do: we do not develop or connect medical devices, measure people, replace safety-related alarm systems, or give legal advice on the AI Act, data protection or IT security.

Limits and risks

• Legal classification is case by case. Whether an AI system is high-risk, whether data is personal and which IT security duties apply are questions for legal advisers, the data protection officer and IT security.
• Rules change. The AI Act was already amended in 2026 [12]. Check the current position before any decision.
• Radio in hospitals is hard. Measurements show that even robust wireless technologies lose data at some locations [3]. Test in your own building first.
• Pilots are not proof of scale. A successful pilot says little about operation across a whole site. Transferability needs its own planning [1].
• No health claims. Building IoT measures room conditions. Questions about the health of patients or staff belong with doctors; IPC questions belong with IPC specialists.
• No substitute for engineering and maintenance. Building services design, manufacturer maintenance and statutory testing remain with the responsible specialists.

Frequently asked questions

What does IoT in hospitals mean for the building?

Networked sensors and plant that capture room conditions and building services data – temperature, air quality, light, meter readings – and bring them together on one platform. Unlike connected medical technology, building IoT has no medical purpose [5].

Is a room sensor a medical device?

Not as long as it has no medical purpose such as the diagnosis, monitoring or treatment of disease [5]. A sensor for building operations measures the environment, not people.

Is LoRaWAN suitable for hospitals?

LoRaWAN is designed for small data volumes, long range and long battery life [2] and can reach basements; packet loss is possible at difficult locations [3]. Whether it fits depends on the project and should be tested in the building.

What is a smart hospital from a building perspective?

A hospital that systematically captures, combines and uses building data for operations and planning. Research names technologies such as BIM, IoT, AI and digital twins – and interoperability, scaling and cybersecurity as barriers [1].

Does the EU AI Act apply to AI in building services?

The AI literacy duty in Article 4 applies to providers and deployers of AI systems generally [10]. Whether a specific system is high-risk – for example as a safety component of critical infrastructure under Annex III, point 2 – must be assessed case by case [9].

Do room sensors need a data protection impact assessment?

Room data with no link to individuals is usually outside the GDPR. If it is combined with information about people, that can change; where a high risk is likely, an assessment under Article 35 is required [6]. Your data protection officer decides.

What are custom IoT solutions for healthcare facilities?

Projects tailored to a specific question, area or existing system – for example a special area, a research question or an in-house BMS – rather than a standard product.

How does a pilot with Fact & Feeling start?

With a conversation about your question and your building. That leads to a concept for measurement, data routes and, where useful, models, which we develop and test with you.

Sources

1. Zhang, X.; Zhang, Y.; Peng, Y.; Au-Yong, C. P.; Awang, N. A. (2026): Transforming healthcare facility management with digital technologies: A systematic review and future roadmap. Advanced Engineering Informatics 71:104404. https://knova.um.edu.my/research_publications_2026_2030/140
2. Mekki, K.; Bajic, E.; Chaxel, F.; Meyer, F. (2019): A comparative study of LPWAN technologies for large-scale IoT deployment. ICT Express 5(1):1–7. https://doaj.org/article/9d8d95d9b5094e29b3f42011f651582f
3. Röhrig, C.; Cramer, B. (2026): Experimental Evaluation of LPWAN Technologies: mioty, LoRaWAN, Sigfox, NB-IoT, and LTE-M in Deep Indoor Environments. Preprint, arXiv:2605.23483. https://arxiv.org/pdf/2605.23483
4. LoRa Alliance (2021): LoRaWAN Regional Parameters RP002-1.0.3. https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf
5. European Union (2017): Regulation (EU) 2017/745 on medical devices (MDR), Article 2(1). https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng
6. European Union (2016): Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 4, 9 and 35. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
7. Information Commissioner’s Office (n.d.): What is personal data? https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/what-is-personal-data/
8. European Commission (2026): AI Act Service Desk – Article 6 Classification rules for high-risk AI systems. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6
9. European Commission (2026): AI Act Service Desk – Annex III High-risk AI systems referred to in Article 6(2). https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
10. European Commission (2026): AI Act Service Desk – Article 4 AI literacy. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4
11. European Commission (2026): AI Act Service Desk – Article 113 Entry into force and application. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113
12. European Union (2026): Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI). https://eur-lex.europa.eu/eli/reg/2026/1744/oj
13. Federal Ministry of Justice (2026): Sozialgesetzbuch V, § 391 IT-Sicherheit in Krankenhäusern. https://www.gesetze-im-internet.de/sgb_5/__391.html
14. Bundesamt für Sicherheit in der Informationstechnik (2022): IT-Grundschutz-Kompendium, implementation notes INF.13 Technisches Gebäudemanagement and INF.14 Gebäudeautomation. https://bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/Umsetzungshinweise/Umsetzungshinweise.html
15. NHS England (2021): Health Technical Memorandum 03-01: Specialised ventilation for healthcare premises, Part A. https://www.england.nhs.uk/wp-content/uploads/2021/05/HTM0301-PartA-accessible-F6.pdf