Data minimization
We look at the scenario and remove fields that do not affect the meaning of the report, the working route or the pilot's quality check.
Public security overview
Security and data in Wizey B2B projects
Clinics, labs and healthtech teams need to understand which data a pilot requires, who gets access to results and which questions are settled before launch. This page gives an open overview without publishing our closed technical and information-security documentation.
Before the pilot
What we discuss before the pilot
We start not with a technical diagram but with the partner's goals: who will use the result, which text-based medical data is required, where the report appears and which constraints matter for the team. The service complies with HIPAA and GDPR requirements. General processing principles are described in the privacy policy and the data processing agreement.
pilot goal user roles typical documents level of detail storage environment deletion timeline
Data
How we reduce unnecessary data transfer
For a B2B project we separate, in advance, the data that is genuinely needed for the result from information that can be left out or replaced with test values.
Text-based materials
The work is built around lab results, discharge summaries, prescriptions, visit notes and text-based study conclusions in an agreed form.
Test set
For the initial check, de-identified test samples, synthetic records or prepared partner cases are suitable.
Role separation
The patient, doctor, operator, administrator and product team can each see a different level of detail.
Timelines and storage
The storage and deletion environment is agreed within the project, accounting for the scenario, the arrangements and the partner's internal rules. Baseline principles are in the privacy policy.
Clear output
The final report adapts to the channel: a patient account, a specialist's workstation, an internal service or a white-label interface.
Organization
Documents and roles
Before the pilot it is important to agree not only on the product scenario but also on the responsible people on both sides. This reduces the risk of unnecessary data, blurred access rights and disputed expectations of the result.
Roles and access
We define who sends data, who receives the result, who validates the samples and who decides on further rollout. Different roles can get a different report format. Scenarios for clinics, labs and patient journeys are gathered in the B2B use-case overview.
Project documents
Teams agree in advance on the set of materials, the pilot procedure, data requirements, the support format and the rules for exchanging information between the responsible participants. Pilot launch terms are described in Pricing and Pilot.
Working with samples
For demos and tests we use de-identified test samples or specially prepared sets. Real cases are discussed separately and only within an agreed process. Our approach to quality checks is on the Quality Proof page.
Scope of the public description
The open page does not publish access parameters, internal schemes, working regulations or detailed information-security materials. This protects partners and the integration process itself. The general integration approach is on the Integration and API page.
Closed package
What stays in the closed documentation
The public page helps you understand the approach. Anything that could reveal the working environment is shared only directly and only after discussing the project.
Technical parameters
Specific connection settings, operating limits, exchange formats and instructions for the partner's team.
Information-security materials
Detailed descriptions of protective controls, internal procedures, lists of responsible people and additional answers for the security team.
Project agreements
The data scope, roles, retention timelines, deletion procedure, support and scaling terms are fixed for the specific pilot.
After the meeting
What we hand to your security team
After a short meeting and an agreed scenario we prepare a package of materials for the security team. Its contents adapt to the maturity of the process and the project task.
Data-flow architecture overview
The scheme of how data enters processing, who receives the result and where each side's responsibility ends. The public integration overview is on the Integration and API page.
Processing regulation
A description of roles, timelines, deletion rules and sample-handling scenarios within the specific pilot.
Contract template
A baseline edition of the documents for review by your legal and security teams, with room for adaptation.
Answers to common questions
Prepared answers to the recurring items in security questionnaires: processing purposes, data scope, environment and responsible parties.
Ready to discuss a secure B2B pilot?
Tell us about the scenario, the roles and the data types. We will propose a pilot format and the list of materials for your team.