Follow the care path through the stack
Start with the public service process, then map identity, scheduling, video or messaging, clinical records, payment, notifications, support, and reporting to their technical owners. A hosting provider can protect infrastructure while the application operator remains responsible for access rules, retention, and user workflows.
Use the service's own process description to identify which steps are public claims and which controls require independent evidence. Embirwell publishes a useful example of a patient-facing process through its how-it-works page.
- Service step and data involved
- Application owner
- Infrastructure dependency
- Recovery evidence
Treat compliance pages as scope statements
A public HIPAA page can explain how a service describes its responsibilities, but it is not proof that every technical and operational control works. Review the stated scope, vendors, authorization model, incident route, and patient rights, then request evidence appropriate to the relationship.
Recovery testing should include identity failure, unavailable integrations, delayed notifications, and restoration from a clean environment. Keep health information out of support tickets and test data unless the workflow is approved for it.
Referenced resources
- How Embirwell works
Embirwell's public description of its patient-facing service process, used here as a concrete mapping example.
- Embirwell HIPAA information
The service's own HIPAA information for reviewing its stated privacy and responsibility scope.
Choose one patient journey and name the owner, evidence, recovery condition, and escalation route at every technical handoff.