WEARABLES & IOT CONNECTORS

Device Types & Capabilities

2 of 7

Explore wearable, medical-device and IoT categories, the data they provide, and how Mediloop maps device capabilities to interoperable healthcare models while keeping clinical and consumer contexts distinct.

Device CatalogCapability ModelClinical vs ConsumerFHIR MappingManufacturer ExamplesData Quality & Validation

14+

Device categories

From wellness to medical-grade workflows

200+

Normalized measurements

Mapped to standard concepts and units where appropriate

50+

Manufacturer patterns

Expandable through standards and provider adapters

Data contexts

Clinical/medical-device data and consumer wellness data

Device Category Overview

Smartwatches

Heart rate, activity, sleep, ECG

Fitness Bands

Activity, calories and sleep

Smart Rings

Sleep, HRV and temperature

Continuous Glucose Monitors

Glucose, trends and alerts

Blood Pressure Monitors

Systolic/diastolic and pulse

Pulse Oximeters

SpO₂ and heart rate

ECG Devices

Single/12-lead ECG and rhythm

Smart Scales

Weight, BMI and body composition

Thermometers

Body temperature

Spirometers

FEV1, FVC and respiratory measures

Sleep Devices

Sleep stages and respiration

Rehabilitation Sensors

Movement and range of motion

Connected Medication Devices

Inhalers, smart pillboxes and adherence events

Environmental Sensors

Air quality, temperature and humidity

Other IoT Devices

Home monitoring, fall detection and custom sensors

Device Catalog (Examples)

Device / provider	Category	Measurements	Connection	Context	Standards mapping
Apple Watch	Smartwatch	HR, ECG, SpO₂, activity, sleep	BLE / HealthKit	Wellness + selected regulated features	FHIR, LOINC, SNOMED CT as applicable
Garmin devices	Fitness / multisport	HR, activity, VO₂ max, sleep	BLE / provider cloud	Primarily wellness	FHIR, LOINC
Oura Ring	Smart ring	Sleep, HRV, temperature, readiness	BLE / provider cloud	Wellness	FHIR, LOINC
Dexcom CGM	CGM	Glucose, trends, alerts	BLE / provider cloud	Clinical / medical device	FHIR, LOINC, UCUM
Withings BPM	Blood pressure	Systolic, diastolic, pulse	BLE / cloud / platform API	Clinical-device context may apply	FHIR, LOINC, UCUM
AliveCor Kardia	ECG	ECG waveform / rhythm	Device/app/provider integration	Clinical / medical device	FHIR Observation + attachment/waveform model

The catalog is an integration-pattern guide, not a promise that every named commercial device is production-certified. Provider access, regional availability and regulated-use status must be verified during onboarding.

Capability Model

Identity & ownership

Stable device identity, provider identifiers, model, serial and patient/device association.

Measurements

Supported metrics, sampling frequency, precision, units and source timestamps.

Connectivity

BLE/GATT, platform framework, cloud API, webhook, MQTT or gateway capability.

Operational state

Battery/connectivity status, firmware/version metadata and last sync when available.

Trust & context

Clinical vs wellness context, regulatory metadata, consent and confidence/quality flags.

Lifecycle

Onboard, activate, update, disconnect, replace and decommission.

Clinical vs Consumer Data

Aspect	Consumer wellness data	Clinical / medical-device data
Intended use	Wellness, prevention, lifestyle	Diagnosis, treatment, monitoring or regulated clinical use
Validation	Informational / provider-defined quality	Requires clinically appropriate validation and regulatory context
Consent	Explicit user authorization to applicable data/provider	Explicit consent/legal basis plus clinical governance
Provenance	Preserve device/provider/source	Preserve device/provider/source plus clinically relevant traceability
Decision support	Do not treat as clinically equivalent by default	May support clinical decisions only within validated intended use

Data Mapping (FHIR)

Device capability	FHIR resource	Terminology / unit guidance
Device identity	Device	Type/model/manufacturer identifiers; preserve source identifiers
Metric definition	DeviceMetric	Use when device metric metadata is represented explicitly
Measurement	Observation	LOINC where available; UCUM units; source coding preserved
Waveform / rich payload	Observation + Attachment / derived representation	Keep raw/original payload or reference where required
Provenance	Provenance	Record provider, device, connector and transformation lineage

Developer Integration Surface

Surface	Operation / resource	Use	Status
FHIR	Device / DeviceMetric / Observation / Provenance	Canonical interoperable representation	FHIR surface
BLE / GATT	Service/characteristic discovery, read/write/notify	Direct device capability integration	Protocol surface
Provider APIs	Provider-specific device & measurement APIs	Cloud-connected commercial devices	External provider API
Connector SDK	Device adapter, capability mapping, ingestion handlers	Custom/new device families	SDK contract evolving
Mediloop Device API	Device registry / measurements façade	Simplified app-level device management	Planned contract

Regulatory Considerations

Do not infer medical-device status from the connector alone; use the manufacturer device and intended-use classification.

Keep wellness and clinically validated measurements distinguishable in the data model and UI.

Preserve source device, provider, firmware/version and quality metadata when clinically relevant.

Validate regional provider availability and regulatory constraints before production.

Treat algorithm-derived measurements according to the provider's intended use and evidence, not simply as raw sensor values.

Best Practices

Identify capability and data-quality requirements before choosing the device.

Map measurements to standards without deleting original codes/units.

Handle sampling frequency, timestamps, time zones and gaps explicitly.

Test battery/connectivity interruptions and replacement-device scenarios.

Separate device connectivity success from clinical data validation.

Monitor provider API changes, firmware changes and deprecations.

Next Steps

Choose integration path

BLE, mobile platform, provider cloud, gateway or local clinical network.

Verify provider requirements

Access program, scopes, rate limits, test devices and regional availability.

Map data

Define FHIR resources, terminology, units and provenance.

Validate production use

Security, privacy, data quality, monitoring and regulatory context.