12.2 Design Compliance and Incorporating Industry Trends

12.2 Design Compliance and Incorporating Industry Trends

Quick Answer: Design has two clocks. Compliance is the floor—law, certification, accessibility, safety. Trends are the horizon—new standards, infrastructure patterns, care models. Build one intake process so neither clock is “whoever attended a conference.”

Tasks B.2 and B.3 are paired on purpose. Compliance without a trend process produces a frozen, eventually non-certifiable EHR. Trend-chasing without a compliance gate produces a shiny pilot that violates Section 508, breaks an ONC-certified API, or ships an unsafe workflow. CPHIMS scores the operating system that keeps both clocks honest after the RFP is signed.

CPHIMS practice questionsPractice questions with detailed explanations

Why this is a process, not a memo

Healthcare design constraints change on different calendars:

• Statute and rule (HIPAA, Cures, information blocking, state privacy)
• Certification editions and CMS Promoting Interoperability measures (not “Meaningful Use” as the current program name)
• Safety and quality (Joint Commission, CMS Conditions of Participation, FDA when software is a device)
• Accessibility (Section 508, WCAG, ADA litigation risk)
• Infrastructure and industry patterns (zero trust, cloud regions, FHIR bulk and SMART apps, immutable backup, ambient documentation)

If the only “process” is a yearly strategy offsite, you will miss a mid-year ONC or CMS change and you will overfit to a vendor keynote. Task B.3 is not “list five buzzwords.” It is “show the path from signal to design standard.”

The intake process CPHIMS wants named

Architecture, informatics, and compliance share a lightweight, dated pipeline:

Rules that show up on items:

• Legal-must is not optional because the project is late or the vendor cannot meet it this quarter. Document the gap and the residual risk; do not pretend the criterion vanished.
• Trend does not skip privacy, safety, or accessibility review. A FHIR bulk export still needs a BAA, minimum necessary, and an owner.
• Park is a decision with a named owner and a revisit date. Silence is not a park.
• Record the source. “I heard FHIR is required” is not an impact note.

Certification as a design constraint

ONC Health IT Certification is a product-capability program. It is not a license to practice medicine and not proof that local order sets are safe (Chapter 9). Design implications:

• If you need Promoting Interoperability credit or information-blocking “certified API” behavior, the product must maintain the relevant certification criteria after you configure it.
• Customization that breaks patient-access APIs, e-prescribing, or quality reporting is a design defect, not a clever local enhancement.
• Certification does not certify your MPI, your device VLAN, or your downtime plan.
• USCDI data classes constrain what certified exchange is expected to support. Local “we do not store that” may be a compliance problem, not a preference.

Ask in every design review: which criteria must remain true after we configure this, and where is the evidence?

SOC 2, HITRUST, and NIST CSF can support a security story. None of them replace HIPAA, and none of them are ONC certification.

Accessibility is in the design, not the theme deck

Accessible design is a requirement:

• Section 508 for federal and many state or covered systems
• WCAG (perceivable, operable, understandable, robust) as the practical success criteria; many programs target 2.1 AA
• Keyboard access, contrast, screen-reader names, captions on training and telehealth
• Clinical reality: a nurse in gloves, a physician with low vision, a patient using a portal with a screen reader, a kiosk in a noisy lobby

Your custom portal skin, PDFs, wayfinding kiosks, and e-learning are in scope even when the EHR vendor’s core is certified. “Clinicians are too busy for accessibility” is not a design decision. Neither is “the vendor is certified, so our overlay is fine.”

Safety standards belong in the design file

HIT safety is designed, not inspected at go-live:

• Human factors: wrong-patient, look-alike orders, interruptive versus passive alerts (Chapter 7)
• Alarm and alert philosophy written before the first BPA
• When software is a medical device or SaMD, think in intended use, risk file, and change control (IEC 62304 / ISO 14971 style)—FDA oversight does not replace HIPAA
• IEC 80001-style thinking for medical devices on IT networks: who owns risk when the pump rides your WLAN
• Joint Commission medication-management and environment-of-care expectations that depend on BCMA, pump libraries, and downtime
• Security-as-safety: ransomware is a clinical downtime event (Section 12.3)

A feature that cannot be used safely in a crash-cart moment is not “done,” even if it compiles and the sprint burned down.

Infrastructure and technical trends

Run trends through the same gate:

• Cloud regions and shared responsibility still sit under HIPAA (Chapter 5)
• Zero-trust and identity-first access often migrate from trend to standard
• FHIR R4/R5, SMART, bulk data, and subscriptions—match to a use case, do not rip working v2
• Immutable backups and identity recovery are now baseline design after years of ransomware, not a conference extra
• Ambient scribes and other AI tools are evaluated in Section 12.4; they still need a BAA, retention, and an accuracy owner

Do not redesign the enterprise around a single demo. Do not ignore a NIST or ONC shift because this quarter’s vendor cannot meet it—write the gap into the standard and the risk register.

Design-review questions

1. Which law, certification criterion, accessibility standard, or safety control does this design claim to meet?
2. What evidence will we keep, and who retrieves it at survey?
3. What trend did we consider and park—and who owns the revisit date?
4. If this configuration breaks a certified API or a 508 path, who is authorized to accept that risk? (Usually: no one.)

Scenarios and exam traps

Scenario. A service line wants a custom portal skin that hides the certified patient-access API “until we are ready.” That is a certification and information-blocking design defect, not a marketing choice. Keep the certified path; park the skin until it passes accessibility and API tests.

Scenario. An architect hears at a conference that “everyone is on FHIR subscriptions now” and opens a project to retire v2 results. Run it through triage. It is an optional trend until an impact note shows a use case, a semantic map, and a cutover that does not break Promoting Interoperability reporting.

Scenario. A pump wireless redesign is treated as a network ticket. Safety and IEC 80001-style ownership never enter the file. Send it back: device-on-network risk is a design-compliance item, not only a VLAN change.

Scenario. Surveyors ask for WCAG evidence on the patient kiosk the marketing team launched. The EHR vendor’s certification letter does not cover the kiosk. Accessibility evidence is local.

Watch these traps:

1. Treating ONC certification as local clinical safety.
2. Skipping 508/WCAG because “only clinicians use it” or “the vendor is certified.”
3. Absorbing trends by hallway conversation instead of a dated impact note.
4. Parking a legal-must as if it were a trend.
5. Using SOC 2 or HITRUST as a substitute for HIPAA or ONC criteria.
6. Calling a yearly offsite a B.3 process.

B.2 and B.3 are how the architecture stays legal and current. Section 12.3 then asks whether that same architecture can survive weather and ransomware.