ISO/TS 28038:2018 — Health informatics — Requirements for the communication of patient data to and from personal health devices

ISO/TS 28038:2018 | Personal Health Device Communication Standard

Introduction to ISO/TS 28038:2018

ISO/TS 28038:2018, “Health informatics — Requirements for the communication of patient data to and from personal health devices,” defines communication requirements for exchanging patient-generated health data between personal health devices (wearables, home monitoring equipment, smartphone sensors) and formal healthcare information systems (EHRs, EMRs, personal health records). Published in 2018, this Technical Specification addresses the rapidly growing ecosystem of consumer health technology and the corresponding need to ensure that data flowing from these devices is both clinically meaningful and interoperable with clinical systems. Developed by ISO/TC 215, the standard responds to the explosive growth in wearable health devices — the global installed base exceeded 1 billion connected health monitoring devices by 2020, generating petabytes of physiological data that remains largely siloed from clinical workflows.

If you are developing a wearable health device or a mobile health application that needs to integrate with clinical EHR systems, ISO/TS 28038:2018 is your essential reference for data format, semantic content, and quality requirements. Conformance with this standard is increasingly being requested in healthcare procurement tenders.

The standard recognizes that patient-generated health data (PGHD) differs from clinician-acquired data in important ways: it may be collected under less controlled conditions, by users with varying levels of health literacy, using devices of variable quality, and transmitted over potentially insecure consumer networks. The specification establishes a layered data quality framework that assigns confidence levels to data based on device type, measurement protocol, user compliance, and transmission integrity. This confidence framework is designed to be transparent to both clinicians and patients — when a physician views a patient-reported blood pressure reading in the EHR, the confidence level is displayed alongside the value, enabling informed clinical interpretation.

The standard also addresses the important area of user consent and data governance. Personal health device data often involves sensitive health information that may be subject to different regulatory frameworks depending on jurisdiction (GDPR in Europe, HIPAA in the US, PIPEDA in Canada). ISO/TS 28038:2018 defines consent management requirements and data minimization principles, ensuring that only the minimum necessary data is transmitted and that patient preferences are respected throughout the data flow.

Data Quality Framework and Communication Protocol

The data quality framework in ISO/TS 28038:2018 defines four confidence levels for patient-generated data. Level 1 data comes from medically certified devices used according to manufacturer instructions with documented user training — this is treated as equivalent to clinician-acquired data and can be used for diagnostic and treatment decisions. At Level 4, data comes from consumer-grade devices with no clinical validation and unknown usage conditions — such data carries the lowest confidence and should be flagged as informational only when displayed in clinical systems. The framework enables EHR systems to present PGHD with appropriate context, allowing clinicians to weigh the data appropriately in their decision-making while avoiding both over-reliance on low-quality data and inappropriate dismissal of clinically valuable patient-reported measurements.

Confidence LevelDevice TypeUsage ProtocolClinical AcceptabilityExample Scenario
Level 1CE-marked / FDA-cleared medical devicePer manufacturer instructions, user formally trainedEquivalent to clinician-acquired measurementPrescribed home blood pressure monitor (validated per AAMI/ESH/ISO) with telemedicine training session
Level 2Medical-grade device, consumer-directed usePer written instructions, self-taught userClinically useful with appropriate cautionOver-the-counter glucose meter used by patient at home with smartphone coaching app
Level 3Consumer health device with clinical validation studiesStandard consumer use pattern, no formal protocolTrend data only, not sufficient for diagnosisFDA-cleared smartwatch ECG single-lead recording for atrial fibrillation screening
Level 4Unvalidated consumer device, wellness app, or social dataUnknown or variable usage conditionsInformational reference only, not for clinical actionGeneral-purpose fitness band step count or wrist-based heart rate estimate during daily activities
Mixing data from different confidence levels without clear labeling is a patient safety risk. ISO/TS 28038:2018 requires that the confidence level be carried as metadata alongside the measurement value throughout the data transmission chain, from device through gateway to EHR display. The confidence level should be visible to clinicians at the point of clinical decision-making, not buried in technical metadata.

Data Elements, Semantic Interoperability, and Security

The specification defines a core set of data elements that personal health devices should be capable of reporting, including vital signs (blood pressure, heart rate, temperature, respiratory rate, oxygen saturation), laboratory-type measurements (blood glucose, INR, peak flow), physical activity (steps, calories, sleep stages), and patient-reported outcomes (pain scales, symptom questionnaires, medication adherence). For each data element, the specification provides the preferred coding system (LOINC for observation identifiers, UCUM for units of measurement, SNOMED CT for clinical concepts) and the minimum metadata set that must accompany the measurement — including timestamp, device identifier, measurement context (fasting, post-exercise, resting), and confidence level.

Semantic interoperability is achieved through the use of ISO/IEEE 11073 personal health device standards and HL7 FHIR Observation resources. The specification provides detailed mapping tables between ISO/IEEE 11073 domain information model attributes and FHIR Observation elements, enabling seamless data flow from a Bluetooth-connected blood pressure cuff through a smartphone gateway into an EHR system. For security, the standard requires TLS 1.2 or higher for data in transit and mandates compliance with regional data protection regulations such as GDPR, HIPAA, and PIPEDA. Device authentication and data integrity protection using cryptographic signatures are also addressed, with the standard recommending that each data payload include a device-specific digital signature that can be verified by the receiving health system.

The communication architecture recommended by ISO/TS 28038:2018 follows a three-tier pattern: the Device Tier (sensors and wearables communicating via Bluetooth LE, ANT+, or NFC), the Gateway Tier (a smartphone app or home hub that aggregates device data, applies initial quality scoring, manages user consent, and provides protocol translation), and the Health System Tier (EHR, PHR, or population health platform that receives, validates, and stores the data for clinical use). The gateway tier is particularly important as it performs protocol translation between device-specific formats and standards-based health information exchange formats, data buffering during network interruptions, and user-facing data quality feedback that encourages patients to improve measurement technique over time.

Early adopters of the ISO/TS 28038:2018 framework in telehealth programs report 40-60% reduction in data quality-related help desk calls and significantly higher clinician trust in patient-reported measurements. The confidence level metadata is cited as the single most useful feature for clinical acceptance of patient-generated data.
The most significant challenge in personal health device data communication is the fragmentation of device protocols and data formats. Without a standardized approach like ISO/TS 28038:2018, healthcare organizations face an unsustainable integration burden, often requiring custom interfaces for each device model. This fragmentation is a major barrier to scaling remote patient monitoring programs.

Frequently Asked Questions

Q1: Does ISO/TS 28038:2018 cover continuous monitoring devices vs. spot measurements?
A: Yes. The standard covers both types of measurements. For continuous monitors (e.g., CGM, Holter monitors, wearable ECG patches), it specifies how to transmit time-series data with appropriate sampling rate metadata, averaging intervals, and data reduction guidance to avoid overwhelming clinical systems with high-frequency raw data.
Q2: How does this standard relate to the ISO/IEEE 11073 personal health device family?
A: ISO/TS 28038:2018 complements ISO/IEEE 11073 by defining the clinical information model and quality framework at the application layer. ISO/IEEE 11073 handles the device-level communication protocols (transport, encoding, device specialization); this TS handles what the data means, how trustworthy it is, and how it integrates with clinical information systems.
Q3: Can patient-reported outcomes (PROs) be transmitted using this framework?
A: Yes. The standard includes data elements for patient-reported outcome measures (PROMs) and specifies LOINC codes for validated PRO instruments and SNOMED CT for response values. This enables integration of standardized questionnaires (e.g., PHQ-9 for depression, EQ-5D for quality of life) into the same data flow as device measurements.
Q4: What are the requirements for data retention and deletion?
A: The standard requires alignment with applicable jurisdictional regulations (e.g., GDPR right to erasure, HIPAA data retention requirements). It recommends that personal health devices and gateways support configurable data retention periods and secure deletion mechanisms, and that patients be provided with clear information about what data is stored, for how long, and with whom it is shared.

📥 Standard Documents Download

🔒
Please wait 10 seconds, the download links will appear after the ad loads

Leave a Reply

Your email address will not be published. Required fields are marked *