Chapter 3

Data Collection Standards

HL7 FHIR integration, data formats, interoperability requirements, privacy-preserving collection methods, and quality assurance protocols for remote patient monitoring systems.

The Foundation of Interoperability

Remote patient monitoring generates vast quantities of health data that must flow seamlessly between devices, platforms, healthcare systems, and care teams. Without standardized data formats and exchange protocols, RPM deployments become isolated silos that cannot integrate with electronic health records or participate in broader health information networks. The WIA-RPM standard mandates specific interoperability requirements that ensure data portability and system integration.

Healthcare interoperability has evolved significantly over the past decade, moving from point-to-point interfaces using proprietary formats toward modern API-based exchanges using standardized resources. HL7 FHIR (Fast Healthcare Interoperability Resources) has emerged as the dominant standard for health data exchange, supported by regulatory mandates and broad industry adoption. RPM systems must embrace FHIR to achieve meaningful integration with the healthcare ecosystem.

Data Flow Architecture

HL7 FHIR for RPM

HL7 FHIR provides a comprehensive framework for representing and exchanging healthcare data through RESTful APIs and standardized resource definitions. For RPM applications, key FHIR resources include Observation for vital signs, Device for monitoring equipment, Patient for demographics, and various workflow resources for care coordination.

Core FHIR Resources for RPM

Resource	Purpose	RPM Usage
Observation	Clinical measurements and findings	Vital signs, glucose readings, weights
Device	Medical device information	Monitoring devices, serial numbers
Patient	Patient demographics	Identity, contact information
DeviceMetric	Device capabilities/settings	Measurement capabilities, calibration
Communication	Patient/provider messaging	Alert notifications, care messages
CarePlan	Care coordination	Monitoring protocols, care goals
Goal	Patient health objectives	Target ranges, health targets

FHIR Observation for Vital Signs

The Observation resource is the workhorse of RPM data exchange, representing each measurement captured by monitoring devices. The WIA standard specifies required elements and coding requirements for RPM observations to ensure consistent interpretation across systems.

{
  "resourceType": "Observation",
  "id": "bp-reading-20250115-143022",
  "status": "final",
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/observation-category",
      "code": "vital-signs",
      "display": "Vital Signs"
    }]
  }],
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "85354-9",
      "display": "Blood pressure panel with all children optional"
    }]
  },
  "subject": {
    "reference": "Patient/patient-12345"
  },
  "effectiveDateTime": "2025-01-15T14:30:22-05:00",
  "device": {
    "reference": "Device/bp-cuff-omron-7250"
  },
  "component": [{
    "code": {
      "coding": [{
        "system": "http://loinc.org",
        "code": "8480-6",
        "display": "Systolic blood pressure"
      }]
    },
    "valueQuantity": {
      "value": 128,
      "unit": "mmHg",
      "system": "http://unitsofmeasure.org",
      "code": "mm[Hg]"
    }
  }, {
    "code": {
      "coding": [{
        "system": "http://loinc.org",
        "code": "8462-4",
        "display": "Diastolic blood pressure"
      }]
    },
    "valueQuantity": {
      "value": 82,
      "unit": "mmHg",
      "system": "http://unitsofmeasure.org",
      "code": "mm[Hg]"
    }
  }]
}

Vital Signs Profile Requirements

The WIA standard adopts the US Core Vital Signs profiles with extensions for RPM-specific requirements. All vital sign observations must include standardized LOINC codes, UCUM units, and device references.

Device Data Standards

Standardized device identification and capability description enables platform-agnostic device management and ensures observations can be properly attributed. The WIA standard specifies requirements for device registration, identification, and capability documentation.

Device Identification

Every RPM device must be uniquely identifiable and properly registered within the monitoring platform. Standard identifiers enable device tracking, firmware management, and observation attribution.

{
  "resourceType": "Device",
  "id": "bp-cuff-omron-7250",
  "identifier": [{
    "system": "urn:ietf:rfc:3986",
    "value": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  }, {
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
        "code": "SNO"
      }]
    },
    "value": "OMR-7250-2024-001234"
  }],
  "udiCarrier": [{
    "deviceIdentifier": "00843210101234",
    "issuer": "https://www.gs1.org/gtin"
  }],
  "status": "active",
  "manufacturer": "Omron Healthcare",
  "modelNumber": "BP7250",
  "serialNumber": "2024-001234",
  "type": {
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "258057004",
      "display": "Non-invasive blood pressure monitor"
    }]
  },
  "patient": {
    "reference": "Patient/patient-12345"
  },
  "owner": {
    "reference": "Organization/rpm-program-abc"
  }
}

IEEE 11073 Personal Health Device Standards

The IEEE 11073 family of standards provides device communication protocols and data models for personal health devices. While FHIR serves as the exchange format, IEEE 11073 defines device-level communication and terminology that underpins interoperable device ecosystems.

Data Quality Requirements

RPM data quality directly impacts clinical utility—inaccurate or incomplete data can lead to missed alerts, inappropriate interventions, or eroded clinician confidence. The WIA standard establishes data quality requirements addressing completeness, accuracy, timeliness, and validity.

Data Completeness

Completeness measures whether expected measurements are actually captured and transmitted. RPM programs must define expected measurement frequency for each parameter and track compliance against these expectations. Missing data should trigger patient outreach to resolve device or connectivity issues.

// WIA Standard: Completeness Monitoring Configuration
{
  "completenessRules": [
    {
      "parameter": "blood_pressure",
      "expectedFrequency": "daily",
      "minimumReadings": 1,
      "alertThreshold": "2_consecutive_days_missing",
      "action": "patient_outreach"
    },
    {
      "parameter": "weight",
      "expectedFrequency": "daily",
      "minimumReadings": 1,
      "alertThreshold": "3_consecutive_days_missing",
      "action": "patient_outreach"
    },
    {
      "parameter": "glucose",
      "expectedFrequency": "per_meal",
      "minimumReadings": 3,
      "alertThreshold": "less_than_2_in_24h",
      "action": "patient_outreach"
    }
  ],
  "reportingPeriod": "weekly",
  "minimumCompliance": 0.80
}

Data Accuracy

Accuracy requirements address measurement precision and validity. Devices must meet specified accuracy standards, and platforms must implement validation rules to identify implausible values that may indicate measurement error.

Data Timeliness

RPM value depends on timely data availability for alert generation and clinical review. The standard specifies maximum latency requirements from measurement to platform availability and from alert condition to notification delivery.

Data Flow Stage	Maximum Latency	Measurement Method
Device to Gateway	30 seconds	Bluetooth connection time
Gateway to Cloud	60 seconds	Upload confirmation timestamp
Processing and Storage	30 seconds	Database commit timestamp
Alert Generation	60 seconds	Alert timestamp minus observation time
Alert Delivery	60 seconds	Delivery confirmation timestamp
Total End-to-End	5 minutes	Notification time minus measurement time

Privacy-Preserving Data Collection

Health data collection must balance clinical utility with patient privacy protection. The WIA standard incorporates privacy-by-design principles ensuring data collection minimizes privacy risks while enabling clinical applications.

Data Minimization

Organizations should collect only data necessary for defined clinical purposes. RPM programs must document data collection rationale and avoid accumulating data without clear use cases. Granular consent mechanisms enable patients to control which data types are collected and shared.

De-identification Techniques

When RPM data is used for analytics, quality improvement, or research beyond direct patient care, de-identification techniques protect patient identity while preserving data utility.

Technique	Description	Use Case
Safe Harbor	Remove 18 HIPAA identifiers	Research datasets
Expert Determination	Statistical risk assessment	Complex analytics
Pseudonymization	Replace identifiers with tokens	Longitudinal analysis
Aggregation	Group-level statistics only	Population health
Differential Privacy	Mathematical privacy guarantees	ML model training

Consent Management

RPM programs require comprehensive consent covering data collection, storage, analysis, and sharing. Modern consent frameworks provide granular control enabling patients to authorize specific uses while restricting others.

// WIA Standard: Consent Resource Structure
{
  "resourceType": "Consent",
  "id": "rpm-consent-patient-12345",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://loinc.org",
      "code": "59284-0",
      "display": "Patient Consent"
    }]
  }],
  "patient": {
    "reference": "Patient/patient-12345"
  },
  "dateTime": "2025-01-15T10:00:00Z",
  "provision": {
    "type": "permit",
    "period": {
      "start": "2025-01-15",
      "end": "2026-01-15"
    },
    "data": [{
      "meaning": "related",
      "reference": {
        "reference": "Device/bp-cuff-omron-7250"
      }
    }],
    "provision": [{
      "type": "permit",
      "action": [{
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/consentaction",
          "code": "collect"
        }]
      }],
      "purpose": [{
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
        "code": "TREAT",
        "display": "Treatment"
      }]
    }, {
      "type": "deny",
      "action": [{
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/consentaction",
          "code": "disclose"
        }]
      }],
      "purpose": [{
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
        "code": "HMARKT",
        "display": "Healthcare Marketing"
      }]
    }]
  }
}

Data Validation and Quality Assurance

Systematic data validation ensures RPM data meets quality requirements before clinical use. Validation occurs at multiple stages from device measurement through platform storage to clinical presentation.

Validation Layers

Error Handling

When validation identifies data quality issues, appropriate handling depends on error severity and clinical implications. The standard defines error categories and required responses.

// WIA Standard: Error Classification and Handling
{
  "errorCategories": {
    "IMPLAUSIBLE_VALUE": {
      "severity": "warning",
      "action": "flag_for_review",
      "storage": "store_with_flag",
      "alert": "suppress_pending_review"
    },
    "DEVICE_ERROR": {
      "severity": "error",
      "action": "discard_measurement",
      "storage": "log_only",
      "alert": "device_maintenance_notification"
    },
    "TRANSMISSION_FAILURE": {
      "severity": "warning",
      "action": "retry_with_backoff",
      "storage": "queue_for_retry",
      "alert": "connectivity_alert_after_threshold"
    },
    "CALIBRATION_EXPIRED": {
      "severity": "warning",
      "action": "accept_with_warning",
      "storage": "store_with_calibration_warning",
      "alert": "device_recalibration_reminder"
    }
  }
}

Audit and Provenance

Complete audit trails enable data verification, support compliance demonstration, and enable investigation of data quality issues. The WIA standard requires comprehensive provenance tracking for all RPM data.

Provenance Requirements

• Source Attribution: Device identification for each observation
• Timestamp Chain: Measurement, transmission, and storage timestamps
• Processing History: Transformations applied to raw data
• Access Logging: Record of who accessed data and when
• Modification Tracking: Amendments with reason codes

{
  "resourceType": "Provenance",
  "id": "provenance-bp-reading-123",
  "target": [{
    "reference": "Observation/bp-reading-20250115-143022"
  }],
  "recorded": "2025-01-15T14:32:15Z",
  "activity": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
      "code": "CREATE"
    }]
  },
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "performer"
      }]
    },
    "who": {
      "reference": "Device/bp-cuff-omron-7250"
    }
  }, {
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "custodian"
      }]
    },
    "who": {
      "reference": "Organization/rpm-platform-xyz"
    }
  }],
  "entity": [{
    "role": "source",
    "what": {
      "identifier": {
        "system": "urn:ietf:rfc:3986",
        "value": "urn:uuid:device-transmission-98765"
      }
    }
  }]
}

Summary

Robust data collection standards form the foundation of effective RPM programs. By adopting HL7 FHIR for interoperability, implementing comprehensive data quality frameworks, and incorporating privacy-by-design principles, organizations can build RPM systems that generate trustworthy clinical data while protecting patient privacy.

The WIA-RPM standard provides detailed specifications for each aspect of data collection, from device-level protocols through EHR integration. Compliance with these standards ensures RPM data can flow seamlessly across the healthcare ecosystem while meeting regulatory requirements and clinical expectations for quality and security.