# Hypothetical purchasing data-use and portability rules

**Educational draft only.** These ideals are not an implemented DenQAI service, privacy policy for a future entity, security certification, data-processing agreement, or legal conclusion.

## Minimum necessary intake

- Accept only the fields required for the defined purchasing comparison.
- Prefer coded categories and aggregate quantities.
- Do not request patient data, credentials, payer fees, unredacted contracts, identifiable competitor strategy, or unrelated financial records.
- State whether a field is required, optional, derived, retained, shared, or excluded.

## Purpose and access

- Publish each permitted use before collection.
- Use role-based access and least privilege.
- Identify every vendor, subprocessor, affiliate, adviser, or sponsor that can receive data.
- Prohibit use for undisclosed sales leads, paid ranking, unrelated profiling, or competitive coordination.

## Security and operations

- Use authenticated access, encryption, logging, tested backups, incident response, recovery, and periodic independent review appropriate to the actual risk.
- Set retention and deletion periods by record type.
- Test correction, deletion, account closure, and recovery—not only describe them.

## Member control and portability

- Members can inspect, correct, export, and delete eligible records under the governing rules.
- Export uses documented, usable formats with definitions and units.
- Termination revokes access, returns portable records, resolves open orders, and identifies legally required retention.
- No essential purchasing history or clinical continuity should be held hostage to membership.

## Launch boundary

No intake should open until the actual entity, contracts, data map, roles, vendors, security controls, legal duties, incident process, retention, deletion, audit, correction, portability, and exit have been implemented and independently tested.