HDS and compliance
Health Data Safe runs a personal health data vault. Individuals hold their own accounts, data enters only with their explicit consent, and they decide who may see it. This site records how that stands up against 4 regulatory frameworks: 229 requirements, read across three layers.
How this works
Every requirement is answered at each layer, and the document behind an answer is named by code on the requirement row. Two questions follow from that, and they are different questions that this site keeps apart: how HDS itself stands against each framework, and what you have to do if you build on it.
What if my application writes data into a person's vault?
A lab pushing results, a clinic pushing records, a device sending measurements: the API grants write access to specific parts of an account, and only after the individual consents. Writing that way is a disclosure the individual asked for. It does not make you a controller of the copy that lands in their vault, any more than reading does: they hold the account and decide who may touch it, and HDS is the controller of what it holds.
Your obligations come from the record you keep, not from the direction the data travels. A lab answers for the accuracy of its results because it is a lab. If you hold the data on your own systems, say so on the implementer page and the duties follow from that. If you capture at the point of care and retain nothing, you are supplying a tool, and little attaches to you.
The frameworks
GDPR
HIPAA
SOC 2
Swiss nLPD
implementedconfigurablefacilitateddocumentedout-of-scope
Each bar shows what the HDS layer does across that framework's requirements: implemented and configurable are delivered by the platform or its configuration, facilitated means HDS supplies part of the answer, documented means HDS records the position without implementing it, and out-of-scope means the requirement has no software role for anyone.