Health data is the category where a design shortcut becomes a notifiable incident. It is also the category where the obligation does not stay in the table you thought it was in, because an order line naming a specific medicine carries the same inference as a diagnosis.
Patient records and health data handling under HIPAA and UK GDPR. Optical and veterinary prescription workflows, including prescriber verification and clinical cross-checks. Practice management system integration. Prescription recall and expiry handling. Licence-scoped catalogues where what a seller may list depends on their authorisation. Eligibility gating before payment. Separate US and EU production regions with data kept in the right place.
The sensitive data is not where you filed it. An
order for a named medicine reveals a condition. That inference travels
into your analytics, your search logs, your email content, your
support tickets, your error reports and your warehouse. Anywhere a
product identifier sits beside a customer identifier, so does the
health inference. Treating a health_records table as the
boundary is the most common mistake we see.
Retention fights deletion. Clinical and regulatory retention periods are usually longer than any other data you hold, and they collide directly with a deletion request. That conflict needs resolving deliberately, in advance, with a written position. Working it out at the point a patient asks is too late.
Licences are stateful, not boolean. They have issuers, scopes, expiry dates and renewal states. Expiry must actively disable selling rather than appearing in a report nobody opens.
Fulfilment has to be able to refuse. A prescription can be rejected after the order is placed. That is a normal path with a state, a refund route and a customer communication, not an exception handled by someone in support.
Development data is the quiet risk. A production restore in a staging environment is where most health data actually leaks, and staging is where contractors and third-party tools get credentials on day one. Anonymisation has to treat order lines as sensitive rather than as commercial data.
Operating in the US and the EU is not one application with a locale switch. Different regimes, different retention, different breach obligations and different views on where data may physically sit. Getting that wrong is not a performance problem, it is a compliance one, and it is far cheaper to design in than to retrofit.
If you handle health data, sell regulated products, or are moving into a regulated category, the compliance and payments conversations should both happen before the build rather than during it.