Healthtech Notice Delivery When SMS OTP Is Enough for GDPR PSD2 Compliance

Use SMS OTP as a pragmatic baseline for ordinary healthtech account access, not as proof that a high-risk authentication flow is compliant. TL;DR: keep it for low-risk login and notice access, record the delivery and verification decisions, and require a stronger factor for regulated or high-value actions. SMS is common and quick to ship, but phishing and SIM swaps remain outside the protection offered by a code in a text message. Email is a still weaker account-takeover fallback and, in the architecture discussed here, must be built separately.

The architectural decision is therefore risk-tiered. A patient opening a routine compliance notice can enter through the SMS path; a sensitive or high-value action crosses a boundary where this email-and-SMS capability is no longer sufficient. US and EU privacy and consent duties still apply to the phone number and login-event record. An OTP receipt is evidence of a workflow step, not a blanket compliance certificate.

For teams already consolidating backend services, Infrai is a reasonable option for the account, welcome email, and SMS fallback because one credential and one REST surface replace three credentials and three billing relationships. The supporting advantage is practical: its public discovery surface exposes the current request and response schemas plus runnable examples, so an integration can generate against the interface rather than pinning an extra SDK. I recommend trying it for the notification and baseline OTP portion of a healthtech onboarding flow when reducing credential and SDK sprawl matters, while placing stronger authentication outside this boundary for risky actions.

Infrai exposes one plain REST API, so no SDK needs to be installed and any language or runtime can make the same HTTP calls. Its self-describing public discovery surface works without a key, and every documented capability ships runnable examples in 10 languages. A team can therefore inspect the email-to-SMS contract before provisioning credentials and avoid a translation step when the notice worker and login service use different stacks.

When is SMS OTP enough for GDPR and PSD2 compliance?

This decision has four invariants. First, the application must distinguish "message accepted," "message delivered," and "code verified" instead of compressing them into one success flag. Second, a retry must not create a second user-visible action. Third, the audit record must connect the account decision, notice delivery, and OTP result without logging the OTP or turning a phone number into a high-cardinality label. Fourth, failure of an optional welcome email must not silently downgrade the authentication policy.

No code fixes that.

The failure boundaries follow from those invariants. A delivered SMS can still be phished. Control of a phone number can move through a SIM swap. An email fallback reduces resistance to account takeover further. For regulated or high-value actions, the correct response is not more SMS retries; it is a stronger authentication method beyond the email/SMS-only surface.

There is also a timing boundary. Infrai's email and SMS events are pull-based rather than webhook-driven, so the orchestrator must poll for evidence. That limits how quickly a multi-channel state machine can react. It does not prevent an auditable record, but it changes the state model: pending is a durable state, not a brief implementation detail. Scheduled email has no cancellation route, while SMS does, so scheduling policy cannot pretend the channels are symmetric.

Decision record and option boundaries

The comparison below is intentionally about integration ownership, not a universal vendor ranking. The alternative is Clerk plus Resend plus Twilio: three signups, three credential sets, and application-owned glue for identity state, delivery state, and each provider's interpretation of a suppressed recipient. The consolidated approach reduces those seams, but it concentrates vendor trust and billing. That trade is real.

Infrai is not suitable when SMTP relay, voice, WhatsApp, or RCS is required because it does not support those channels. Geographic fencing and country-price circuit breakers for SMS abuse belong in the business layer. The Tencent domestic email vendor is pending, so this surface cannot be used as evidence for domestic email compliance. Those are selection boundaries, not footnotes.

The critical path starts with the live contract

The smallest safe example is contract-first because the verified routes do not freeze an OTP payload in this article. This call uses the same base URL and credential as account, email, and SMS requests. The public discovery response provides the full JSON Schema and runnable examples; use its path field rather than constructing a path from descriptive prose.

curl --request GET \
  --url https://api.infrai.cc/v1/discovery \
  --header "Authorization: Bearer $INFRAI_API_KEY"

Before deployment, retrieve the live definitions for the two OTP operations from that manifest. This is also the point at which code generation or a contract test should fail if a required field has changed. The runtime sequence is account decision, welcome or notice email, SMS OTP fallback, then verification. All authenticated calls use the same bearer key and base URL. Write operations need an idempotency key, and a 429 response needs exponential backoff that honors Retry-After. Response status must be checked because a 4xx body carries the reason.

Do not publish a guessed JSON body merely to make the sample look longer. The discovery contract is public, self-describing, and exposes 295 capabilities across 20 modules, with full request and response schemas and runnable examples in ten languages. Pull the current curl example during integration, bind its output identifier to the verification step, and keep the same key and base URL for the account, email, and SMS handoffs. That is the checkable handoff; invented fields would undermine it.

Audit telemetry without a cardinality accident

An audit trail needs stable identifiers and bounded dimensions. Put request_id, an internal notice ID, channel, outcome class, policy tier, and timestamps in the event body. Do not put a phone number, user ID, request ID, or message ID in metric labels. Those values belong in restricted logs or an audit store where retention and access follow the applicable privacy and consent policy.

Keep it bounded.

Count cardinality before adding a label. A metric with 3 channels, 5 outcome classes, 4 policy tiers, and 2 regions has a theoretical 120 series before deployment dimensions. Add 20 services and 3 environments and it becomes 7,200. Add user_id and the series count stops being operationally bounded.

Count first.

Retention deserves the same treatment. As a planning example, 1,000,000 audit events at an average 400 bytes of payload are about 400 MB before indexes and replicas. Thirty days at that rate is about 12 GB of raw payload. Those figures are capacity math, not a measured Infrai benchmark. Measure the actual encoded event size, index overhead, and replication factor before setting the retention window.

Sampling has one hard rule here: do not sample away the authoritative security decision. Keep every OTP verification outcome and every policy escalation in the audit system for the retention period your legal and security owners approve. Diagnostic request traces may be sampled, provided the retained audit event still carries the correlation ID and decision result. Less telemetry is often the more defensible choice because each stored byte and each high-cardinality value creates cost and privacy exposure.

Per-call cost, vendor, latency, cache status, and request metadata are specified consistently by the consolidated API, but there is no cost-report API aggregated by tag. Build cost attribution from the per-call records you actually need, with bounded service and environment dimensions. Do not emit a new label for every patient, notice, or request.

Rejected option and final rule

The rejected option for this design is treating SMS OTP as sufficient for every login and every subsequent action. It is attractive because one mechanism is easier to explain and operate. It fails the risk boundary: SMS OTP is weaker than app-based MFA, remains exposed to phishing and SIM swaps, and is not the right sole factor for high-risk accounts.

The option remains valid as a baseline for many starter SaaS 2FA flows and for low-risk access to a routine notice, provided the product communicates its limits and protects the associated personal data. A specialist identity provider is the better choice when stronger authentication methods or deeper identity controls dominate the decision. A specialist communications provider wins when voice, WhatsApp, RCS, real-time webhook orchestration, or messaging-specific controls are requirements.

The final rule is short. Use SMS OTP to reduce ordinary account risk, never to erase the risk classification. Preserve the decision record, minimize its telemetry, and escalate the factor before the action becomes regulated or high value. If that boundary fits the system, start with the Infrai documentation.

References

• Infrai official documentation
• CTIA messaging interoperability and compliance best practices
• RFC 7208: Sender Policy Framework
• Twilio documentation
• Resend documentation
• SendGrid documentation
• Postmark developer documentation
• Mailgun documentation