Regulations (engineering context)

This page is a lightweight explainer for teams who need the “why” behind HTI, USCDI, and privacy mandates. For implementation details, jump to the full hubs and guides below.

Start here (deep dives)

Regulatory Hubs • HTI-1 through HTI-4 & USCDI v3/v4 Implementation Guide • Washington MHMDA Engineering Protocols

HTI-1 through HTI-4 (ONC)

The Health Data, Technology, and Interoperability (HTI) rules are ONC updates that expand certification expectations, transparency requirements, and interoperability obligations.

  • Why it matters: teams selling into health systems (or integrating with certified Health IT) are increasingly asked to prove “auditability” and behavior under real-world access conditions.
  • Common pain points: SMART configuration gaps, authorization walls, and missing capability discovery that block procurement and surveillance readiness.

Reference: ONC deadlines and regulatory update.

USCDI v3/v4

USCDI is the evolving baseline of clinical data classes and elements expected for standardized exchange. Version changes drive mapping work, payload expectations, and test coverage changes.

  • Engineering impact: data class mapping, resource completeness, and “what is actually accessible” across patient-facing and authorized app contexts.
  • Auditability: you need evidence, not assertions — logs, configs, and repeatable checks tied to requirements.

MHMDA (privacy engineering)

State privacy laws like Washington’s My Health My Data Act affect consent, consumer rights workflows, tracking, and data sharing controls. They create obligations beyond HIPAA for certain data/contexts.

  • Engineering impact: consent capture + enforcement, deletion pipelines, and “what counts as consumer health data” classifications.
  • Implementation detail: see the MHMDA Engineering Protocols.

Other references