Jersey Clinic Register
Concept · Draft proposal For discussion with clinics

Jersey Clinic Register

A shared patient register for Jersey's medicinal cannabis clinics

At the moment each clinic only knows about its own patients. This is a proposal for a simple shared register. It would hold one entry per patient and show which clinic they're with, so a second clinic can't sign them up as well.

It would also give the police and social services a way to pass on concerns. A clinician checks each one before anything is added.

About 72,000
medicinal cannabis prescriptions in Jersey this year
End of 2026
when new controls are due
No shared list
of which patients are registered where

Rough figures, included for background.

The problem

Prescriptions are monthly and can run for a long time. Nobody can currently see which clinic a patient is with.

No shared view

Clinics can't see each other's patient lists. When someone new comes in, there's no way to check whether they're already being treated elsewhere.

The one-clinic rule is being broken

Patients are only meant to be registered with one clinic. Some are getting a monthly prescription from more than one.

Concerns don't reach the clinic

The police or social services may know that a patient is misusing their prescription, selling it on the black market, or has mental health problems. They have no way of telling the clinic.

What we're proposing

Clinics would share only what's needed to enforce the one-clinic rule. Names and clinical details stay encrypted, and only the clinic treating the patient can read them.

1

One entry per patient

There's one entry for each patient rather than one per prescription. It records that the person is being treated at a particular clinic, and it stays in place for as long as treatment continues.

2

A code instead of a name

A patient's details are turned into a code that can't be reversed. The register matches codes, so it never has to read a name to spot a duplicate.

3

Encrypted details

Name, date of birth and the current prescription are encrypted. Each entry has its own key, and those keys are locked with a master key kept in a separate vault.

4

One clinic at a time

Any other clinic that looks the patient up sees "Already registered with <Clinic>". The register won't accept a second entry, and it logs the attempt.

What this means in practice
5

Moving clinic

The new clinic asks for a transfer and the old one confirms it. If the old clinic doesn't reply, it goes through after a set number of days. The details are then re-encrypted for the new clinic.

6

Concerns from police and social services

They can send in a flag but can't search or read the register. A named clinician reviews each flag first, and anyone opening one has to record why.

How a lookup works

  1. The clinic enters the patient's detailsFull name, date of birth and Jersey social security number.
  2. The details are put into a standard formNames go into capitals with spaces and accents removed. The date of birth is written year first (1984-03-07). The social security number, which has the format JY000000A, goes into capitals with spaces removed. This step is called normalising. It means "Zoë Le Brun" and "ZOE LEBRUN" count as the same person.
  3. The register turns them into a lookup codeIt uses HMAC-SHA256, a standard method for producing a fixed-length code from some text and a secret key. Only the register holds the key. The same details always give the same code. You can't work back from the code to the name, and without the key nobody can generate codes for likely names and birthdays to find a match.
  4. It checks whether that code is already thereThis is a straight comparison of codes. No names are decrypted.
  5. One of two things happensIf there's no match, a new entry is created and this clinic holds it. If there is a match, the clinic sees "Already registered with <Clinic name>". No second entry is created, and the attempt is logged.
What this means in practice Say a patient is registered with Clinic A and Clinic B tries to sign them up. The register won't add them. Clinic B just sees "Already registered with Clinic A", so the patient can't be on two clinics' books. The register also records the attempt: which clinic, which member of staff, and when. Over time that shows which patients keep trying to register at more than one clinic, and whether any clinic keeps trying to sign up patients who are registered elsewhere.
Prescriptions are monthly, so the register tracks who is treating the patient rather than each prescription. The entry stays put while treatment continues, and the prescription details on it are kept up to date.
How a lookup works 1 · Clinic enters details Name, date of birth, social security number 2 · Normalise ZOELEBRUN|1984-03-07|JY123456C 3 · HMAC-SHA256 with the secret key Lookup code: 60967eaa…7ae96181 4 · Register compares codes No names are decrypted No match Match New entry created This clinic becomes the holding clinic “Already registered with Clinic X” No second entry Lookup logged who, when and why Attempt logged kept on record
How a lookup works. The example details are made up.

A worked example

A made-up person with a made-up social security number, run through the same steps using a demo key. The real register would use its own secret key, so its codes would look nothing like these.

As typed

Zoë Le Brun
7 March 1984
JY 12 34 56 C

Normalised

ZOELEBRUN|1984-03-07|JY123456C

Code (demo key)

60967eaa3e4b1bcadf1d6fb014089b32a43835a420f2268119f8089b7ae96181
Typing ZOE LEBRUN or zoe le brun gives the same code. Move the date of birth on by one day (1984-03-08) and the code changes completely: 6587382bb4dd0a4f…71bbba13ef.

Try it yourself

This runs in your browser and nothing is sent anywhere. It uses the same demo key. Please use made-up details rather than a real person's.

normalised …
code       …
format     …

Keeping the data safe

What isn't encrypted

Only what the register needs in order to work: the lookup code, which clinic holds the entry, the start date, the date of the last review, and a yes or no for whether there's a flag. None of it names the patient or says anything about their treatment.

What is encrypted

The patient's name and date of birth, and their current prescription. That covers the type of product (flower or oil, for example), the monthly amount (say 30 g) and when it last changed. These are encrypted with AES-256-GCM, a widely used encryption standard that also shows if the data has been tampered with.

How the keys work

Each entry has its own key. Those keys are themselves encrypted ("wrapped") with a master key, which is kept apart from the register in a key vault. This arrangement is known as envelope encryption. Every time a key is unlocked, it's logged. If one entry's key ever leaked, it would expose that entry and nothing else.

Underneath

Disks and backups are encrypted. Every connection uses TLS, the same kind of encryption your browser uses for secure websites.

Flag details are kept in a separate record with a separate key. There's more on this under concerns from police and social services.
The layers of protection around one entry TLS on every connection Encrypted disks and backups One entry per patient Not encrypted (needed to run it) Lookup code · Holding clinic · Start date Last review date · Flag (yes or no) Encrypted with AES-256-GCM Name · Date of birth Prescription: product type, monthly amount, date last changed The entry's own key (wrapped) wrap and unwrap Key vault (kept separately) Master key wraps each entry's key Every unlock is logged
The layers of protection around one entry.

Who can see what

Prescribing clinicians

Can look patients up. At the clinic holding the entry, they can read and update the prescription details. They can open a flag, but only after recording a reason.

Clinic admin staff

Can check whether someone is registered and where. They can't see clinical details or flags.

Clinic lead

Sets up and manages the clinic's staff accounts.

Police and social services

Can submit flags through a separate secure form. They can't search the register or read anything on it.

Action or dataPrescribing clinicianClinic adminClinic leadPolice and social servicesPatient
Check if someone is registered✓ Yes✓ Yes–✕ No✓ Own entry
See "Already registered with <Clinic>"✓ Yes✓ Yes–✕ No✓ Own entry
Read name, date of birth and prescription◐ Holding clinic only✕ No–✕ No✓ Own entry
Create an entry◐ If none exists––✕ No–
Submit a flag–––✓ Secure form–
Review a flag before it's added◐ Named clinician✕ No–✕ No–
Open flag details◐ After recording a reason✕ No–✕ No◐ Can challenge a flagWhat patients are told is still undecided
Search or browse the register◐ Lookup by details only◐ Lookup by details only–✕ No✕ No
Manage staff accounts––✓ Yes––
Two-factor sign-inA second check on top of the password✓ Required✓ Required✓ Required✓ Required✓ Required

Scroll sideways to see every role.

✓ allowed◐ allowed with a condition✕ not allowed– not part of the role
Every lookup is logged with who did it, when and why, and someone independent reviews the logs. Patients can see their own entry and challenge a flag.

Concerns from police and social services

The police and social services sometimes know things a clinic doesn't. A prescription might be being misused or sold on, or there may be concerns about someone's mental health. At present there's no way for that to reach the prescriber.

  1. They submit a flagThrough a separate secure form. They can't search the register or read anything on it.
  2. A clinician reviews itA named clinician looks at each flag before it's added to an entry.
  3. It's stored separatelyThe flag goes on the entry held by the patient's clinic. Its details sit in their own record, encrypted with a separate key, and the entry itself only shows that a flag exists.
  4. A reason is needed to open itA prescribing clinician has to record why before they can read it.
  5. It's loggedWho opened it, when and why. The logs are reviewed independently, and the patient can challenge the flag.
How a flag reaches the clinic Police or social services submit Secure form only, no access to the register Named clinician reviews it Nothing is added before review Flag added to the entry Own record, encrypted with a separate key Prescriber records a reason Only then can the details be opened Access logged Who, when and why, reviewed independently
How a flag reaches the clinic.

Moving to another clinic

Patients can change clinic. The register handles this as a transfer, so the move is recorded and the patient is never registered twice.

  1. The new clinic asks for a transferUntil it goes through, the old clinic still holds the entry.
  2. The old clinic confirmsIf it doesn't respond, the transfer goes through automatically after a set number of days.
  3. The entry moves acrossThe new clinic becomes the holding clinic.
  4. The details are re-encryptedThey're encrypted again for the new clinic, so only it can read them.
How a transfer works New clinic asks for a transfer The old clinic still holds the entry Old clinic confirms the transfer Or there's no reply and it goes through after a set number of days Entry moves to the new clinic It becomes the holding clinic Details re-encrypted Only the new clinic can read them
How a transfer works.

Questions still to answer

Patient data on the register is health data under the Data Protection (Jersey) Law 2018. These points need working through with the clinics, regulators and legal advisers. Nothing here is legal advice.

?

What is the legal basis for the police and social services to share flags with clinics, particularly flags about mental health?

?

Should patients be told when a flag is added? If so, when and how?

?

How long should a flag stay on an entry before it expires or is reviewed?

?

Who is accountable if a flag turns out to be wrong, and how does it get corrected?

?

What consent do patients need to give, and what should the privacy notices say?

?

Does the register need a data protection impact assessment (DPIA) before it goes live?

?

How many days should an unanswered transfer request wait before it goes through?