Privacy Policy
Dagnul, Inc.
1. Who we are and what this policy covers
Dagnul, Inc. (“Dagnul”, “we”, “us”) makes software for the Drug Safety teams of drug companies. It reads copies of the intake streams a company's other teams run (its medical-information inbox, its call-center contractor's notes, comments on its own social pages, market-research and patient-support forms) and puts every possible adverse-event report in Drug Safety's queue on the day it arrives, for a safety scientist to confirm or correct. This policy explains what personal data we handle when we do that, and why.
Registered at 451 D Street, Suite 702, Boston, MA 02210, United States.
We handle personal data in two different situations, and different rules apply to each:
| Whose data | Our role | What applies | |
|---|---|---|---|
| Part A | People who visit this website, ask about the service or write to us | Controller: we decide why and how the data is used | This policy |
| Part B | Patients, reporters and other people named in the items a customer's intake streams carry, whose data reaches us only as copies of those streams and which we process for the drug company that holds the application; and the staff of our customers who use the service or own a stream | Set out in B.1, because it depends on the data | This policy and the data processing agreement we sign with each customer |
If the data processing agreement (“DPA”) and this policy ever disagree about Part B, the DPA wins.
2. Part A: this website and our contact with you
This part covers the personal data we collect for our own purposes: running this website, answering requests, and staying in touch with people who are or might become customers.
A.1 What we collect
What you give us. When you send the form on this site, we collect what you type into it, such as your name, email address, phone number or company, and the fact that you agreed to be contacted. If you email or talk to us, we keep that correspondence and any contact details in it.
What is collected automatically. Our web server records the IP address a request came from, the browser used, the pages requested, the page you came from and the time. These logs exist to keep the site running and secure.
We don’t ask for sensitive data (the “special categories” in Article 9 GDPR) through this website, so please don’t send any through the form.
A.2 Why we use it, and what allows us to
| Why | What | Legal basis (GDPR Art. 6) |
|---|---|---|
| Answering your request and working out whether the service fits | What you sent in the form, our correspondence | Art. 6(1)(b): steps you asked for before a contract |
| Looking after customers, billing and support | Contact details, correspondence | Art. 6(1)(b): carrying out a contract |
| Keeping the site running, secure and free of abuse | Server logs | Art. 6(1)(f): our legitimate interest in running a secure service |
| Contacting you about the service | Email address, company | Art. 6(1)(f): our legitimate interest in business-to-business marketing. You can object at any time |
| Meeting tax, accounting and legal duties | Billing and contract records | Art. 6(1)(c): a legal obligation |
Where we rely on legitimate interest, we have weighed that interest against your rights, and you can ask to see the assessment.
A.3 How long we keep it
- Requests from people who don’t become customers: 12 months from our last contact, then deleted.
- Customer contact and contract records: for the length of the agreement plus 6 years, to cover legal claims and accounting rules.
- Server logs: 30 days.
- A record that you objected or opted out: kept indefinitely, so we can keep respecting it.
A.4 Your rights
If you are in the EEA or the UK, you can ask to see your data, correct it, have it deleted, limit or object to how we use it, get a copy you can take elsewhere, and withdraw consent where we rely on it. Write to [email protected] and we will answer within one month.
You can also complain to a data protection authority. If you are in the EEA, that can be the authority where you live or work.
3. Part B: data inside the service
This part covers the data that passes through the service: the items copied to us from the intake streams a customer switches on, the safety database's case list it sends us, and the proposals, confirmations and corrections made on those items.
B.1 What we handle, and in what role
For the items, the case list and everything made from them we act as a processor for the application holder, under the data processing agreement, because the holder decides why the data is processed (its pharmacovigilance duties) and which streams we read. For the account details of our customers' users we act as a controller. The service handles the following:
- Items from the streams the customer switches on. The text of medical-information emails and the replies in their thread, call-center contractors' call notes, comments on the customer's own social pages with the post each sits under, market-research and patient-support-program AE forms, and sales-rep call notes exported from the customer's CRM, with each item's sender address, time and stream. These items often hold health data: a patient's age or date of birth, initials or name, the medicines taken, reactions and hospital stays, and the reporter's name, email address or phone number.
- The product list and the case list. The customer's product names, established names and strengths from its own SPL listing files, which carry no personal data. And the safety database's case list for the period counted: case number, the date Drug Safety logged receipt, day zero, seriousness and the kind of source. Where the customer sends E2B(R3) messages instead of a list, we read those elements and discard the rest of each message on arrival.
- Users, owners and their decisions. The names and work email addresses of the customer's Drug Safety users, its head of pharmacovigilance and the people in the teams that own each stream, and which user confirmed, corrected, moved a line or signed a model version, and when.
The model reads each item in full, because a reaction can sit in any sentence. It reads text and text-based PDF forms only; images, scans and call recordings go to the customer's queue unread and are marked so.
We use items for the customer's intake and for nothing else: no marketing, no profiling of patients or reporters, no research of our own and no sale.
Our staff open an item only when one of the customer's users asks them to in a support request, and each opening is written into that item's trail.
B.2 What we do with it
Reading and routing. Our own model reads each item as it arrives and proposes whether it is a possible case, which of the four minimum criteria it holds, a seriousness and a day zero, each tied to the sentence it came from. The item goes into the customer's queue, and the team that owns the stream receives a notice with a one-line gist and a link, not the item's text, which that team already holds.
Confirmation by the customer's safety scientists. Every item is confirmed or corrected by one of the customer's safety scientists, including the items the model proposes are not cases. Confirmed items go to the customer's safety database as source documents, which the customer's case processors enter; we write nothing into the safety database and send nothing to FDA.
Retraining the customer's model. When a scientist confirms or corrects a proposal, we keep the sentences the model read and the confirmed marks as a pair, with names, contact details, record numbers and dates of birth replaced by placeholders. A customer's pairs train only that customer's model, at the retraining its head of pharmacovigilance approved, on cloud GPU capacity we control in N. Virginia.
The handoff count. For the free count, the model reads the exports of last quarter's streams, proposes a day zero for each item that became a case, and the customer's scientists confirm them; we then count the calendar days to the safety database's receipt. If the customer does not go on, the exports are deleted within 30 days of the count.
Subprocessors, and no onward sale. We do not sell, rent or share items, case lists or decisions. The subprocessors that host the service on cloud infrastructure in N. Virginia, send our email and take payment are named on our subprocessor list; no model provider is on it, because no item is sent to one.
B.3 AI models: where they run and what they learn from
Where models run. Every item is read by Dagnul's own model, an open-weight multilingual encoder we fine-tune and serve ourselves on cloud GPU capacity we control in N. Virginia, beside the app and the stored items on cloud infrastructure in N. Virginia. No part of any item, proposal or correction is sent to a third-party model provider, which is why none is on our subprocessor list. Nothing of ours runs inside the customer's systems; the copy rules there only send us copies.
Training. We do not train any model on one customer's items for anyone else. Our base layer is trained only on inquiries, call notes, comments and forms written and labeled by pharmacists under contract with us, and on public regulatory text, with no patient's words in it. The one exception is each customer's own layer: when its safety scientists confirm or correct a proposal, we keep the pair (the sentences the model read, with names, contact details, record numbers and dates of birth replaced by placeholders, and the confirmed marks). Pairs are never pooled across customers, train only that customer's layer at the retraining its head of pharmacovigilance approved, on the same GPU capacity in N. Virginia, and are deleted with that layer when the contract ends.
Where a person decides. The model proposes, and a safety scientist settles every item. Above the line the safety scientists set for each stream, an item is marked a possible case and put at the top of the queue; second-hand reports, outcomes without circumstances, conflicting dates, a criterion that needs medical judgment and text in a language it does not read are marked as items it cannot decide, with the reason; below the line, items go into a daily list that a scientist confirms item by item by the next working day. The model closes, nullifies and answers nothing, no item reaches the safety database without a scientist's confirmation, and no new model version or line reads anything until the head of pharmacovigilance signs it. The service makes no automated decision with legal or similarly significant effect on any person.
B.4 Where the data is kept
Items, case lists, proposals, decisions, trails, training pairs, each customer's model and their backups are stored and processed on cloud infrastructure in N. Virginia, in the United States, and do not leave the United States. Our staff in Boston reach them remotely, only as the notes above allow.
Nothing of ours runs inside the customer's systems: the copy rules a stream's owner sets there only send us copies. Payment details are held by our payment provider and never reach our systems.
The suppliers that handle data in the service are named on our subprocessor list, which comes with the data processing agreement and which we send to anyone who asks: write to [email protected].
B.5 How long we keep it, and what deleting can’t remove
Items that the customer's scientists confirm as possible cases or as reports to follow up, and every item's trail, are kept for the customer for ten years, the period 21 CFR 314.80(j) and 600.80(k) set for an applicant's adverse-event records, and exported to the customer as PDF/A and CSV every quarter.
Items confirmed as not a case are kept for 24 months after confirmation, or the period the head of pharmacovigilance sets on the streams page, and then deleted; the trail line saying who confirmed them and when stays with the other trails.
Training pairs and the customer's own model are kept while the contract runs and deleted within 30 days after it ends. After the contract ends we keep a read-only archive of the trails for ten years at no charge, unless the customer asks us to hand it over and delete it.
Account details are kept for the life of the account and 24 months after it closes. Invoices and the tax records behind them are kept for as long as US federal and Massachusetts tax law requires.
B.6 Requests from people whose data is in the service
If you wrote to a drug company, called its line, filled in an agency's form or commented on its page, and your words reached us as a copy, that company holds your data and decides what happens to it under its pharmacovigilance duties, which can require it to keep a report for many years. Write to that company. If you write to us instead, we pass your request on to it within five business days. If you use Dagnul at one of our customers, write to us directly about your account details.
For everyone
4. Moving data between countries
Dagnul, Inc. is a company in the United States. When personal data from the EEA or the UK reaches us, for example because someone there writes to us or a customer there uses the service, it is protected by the European Commission’s Standard Contractual Clauses, a transfer impact assessment and the extra technical measures described in our security documentation. You can ask us for a copy of the clauses.
EU representative (Article 27 GDPR). Write to [email protected] with “EU representative” in the subject line and we will send you our representative’s details.
5. Security
We protect data in line with the risk. That includes encryption in transit and at rest, access limited to the people and systems that need it, each customer’s data kept separate from every other’s, and a log of every access to production systems.
If a personal data breach affects you, we tell you without undue delay, and at the latest within 36 hours of finding out, with the information you need to meet your own reporting duties.
6. Children
The service is sold to businesses and is not meant for children. We don’t knowingly collect personal data from anyone under 16.
7. Changes to this policy
We may update this policy. If a change matters, we email customers at least 30 days before it takes effect. The version number and date at the top of this page change every time.
8. Contact
Privacy questions and anything else: [email protected]
By post: Dagnul, Inc., 451 D Street, Suite 702, Boston, MA 02210, United States