What is the Learning Unit about?

Patients increasingly arrive at the clinic already carrying data about themselves – sleep trackers, smartwatches, e-diaries, continuous glucose monitors. That data can enrich clinical reasoning, but only if students learn to read it critically: what it adds, what it misses, and when it can be trusted. Learning Unit (LU) 109 introduces undergraduate students to wearables and mHealth tools as part of the diagnostic and monitoring process, moving them from passive awareness of these devices to active use of patient-generated data in reasoning about a case.

Students work through a virtual patient (VP) case built around Denis Langlois, a patient being screened for sleep apnea, where passively collected wearable and home-monitoring data are woven directly into the diagnostic workflow. A second VP – centred on migraine – extends the same skill into the synchronous, in-class phase, asking students to consider active data acquisition using e-diary and app-based data in a different clinical context. Around these cases, the unit adds short videos introducing wearables from both a clinical and a patient-user perspective, MCQs, reflective questions on the benefits and risks of these tools, and a mapping exercise that makes visible how wearable data is integrated in patient-centred care.

How We Developed It

The team built LU109 across roughly eight biweekly meetings from March through April 2026, with tasks split among a distributed group – video curation, question writing, case development, and assessment design each had their own owner, coordinated through a shared outline and folder.

One of the earliest and most consequential decisions was choosing the right device for the sleep-apnea case. The team’s first instinct was a specific home-screening device, but closer investigation showed this wearable did not provide connectivity through mobile apps and so didn’t really qualify as an mHealth device in the sense the unit wanted to teach. Rather than settle for whatever was already on hand, the team went out and asked: colleagues consulted a sleep-medicine clinic directly, and the search extended to partner institutions in Rotterdam and Kraków to see what devices were actually used in practice there. That cross-institutional check turned up a cloud-connected alternative and surfaced again the genuinely useful discussion of what distinguished medical devices from wellness consumer health apps, a nuance students should be aware of before trusting any device output.

The three-phase structure also went through real development iteration rather than being fixed from the start. Early drafts asked whether 120 minutes was too long for the asynchronous phase. Over successive meetings, the team narrowed this down: an asynchronous phase built around videos, MCQs, and the sleep-apnea case; a synchronous phase adding a second case and students’ discussion about the patient’s perspective. Along the way, superseded material was deliberately cut rather than kept “just in case” – an older seminal article was demoted to optional reading once a brand new one was identified.

What Did We Learn?

Building LU109 reinforced how much clinical value sits in the gap between what a device measures and what it actually means for a patient. Wearable and mHealth data isn’t self-interpreting – the question “what does the reading say?” is far less useful than “what does this reading tell me about this patient, and what might it be missing?” Anchoring that question in a virtual patient case that told a realistic story, rather than a generic discussion of wearables, made the stakes tangible in a way an abstract lecture could not.

We also learned that checking assumptions against real clinical practice pays off. Rather than building the case around the first plausible device, we asked clinicians across institutions what they actually use. This added a valuable cross-national comparison enabled by the Erasmus+ collaboration, covering the differences in regulatory environments the students will practice in the future.

Finally, developing LU109 as a genuinely iterative process – revisiting structure, timing, and content case-by-case rather than locking in early – produced a stronger unit than a fixed plan would have. Giving the team room to say “this doesn’t fit yet” and keep adjusting, right down to removing content in later meetings, meant the final design reflected what the didactic module actually needed rather than what the first draft assumed.

Stay connected with D-CREDO and follow our journey on LinkedIn for more updates, insights, and stories.