Module guide · Clinical

Record Transfer

Move a patient's whole record to another hospital — pushed straight over the link between two installations, or assembled as a sealed file somebody carries. Optionally locked with a key that travels by a different route, so the record is unreadable to anyone holding only the file.

Overview Sending a record The transfer key What travels Receiving a record Unlocking History Partner hospitals Good practices

What this module is for

A patient moving between hospitals should arrive with their record, not with a photocopied summary and a phone call.

Who uses it

Clinicians and records staff send and receive. Registering the partner hospitals themselves, and the keys the two systems use to recognise each other, is an administrative action.

Where to find it

Open Record Transfer from the patient area. Four tabs: Send a record, Receive a record, History, and Partner hospitals.

1
Pick the patient and the destination
A partner hospital over the direct link, or a sealed file to hand over.
2
Say why
Required. This is a disclosure of protected health information, and the sentence you write is what the audit trail will show.
3
Decide whether to lock it
A locked record needs a transfer key before a single line of it is readable.
4
Watch it assemble
The console shows each section being collected, sealed, locked and transmitted.
5
The other end files it
The seal is verified first; then the mergeable sections are filed onto the chart and the rest is kept as read-only history.

Sealed and locked are two different things

Every bundle is sealed: a checksum that proves it has not been altered since it left. A record altered after it was sent is refused outright at the far end. Locking is separate and optional — it encrypts the contents so that only a holder of the transfer key can read them.

Sending a record

Whose record, where it goes, and why it is being released.

The send form

Field	What it means
Whose record*	Search by name or MRN.
Where it goes*	To a partner hospital, transmitted directly over the link between the two systems; or as a downloadable file — a sealed JSON bundle to hand over on a drive or attach to a referral.
Why the record is being released*	e.g. "Patient transferred to cardiology for surgical management". This sentence is what the audit trail will show.
Note to the receiving hospital	Optional — anything the clinician at the other end should read first.

If no partner hospital is registered, only the file route is available; an administrator registers partners under Partner hospitals. A partner that is suspended, or has no outbound key configured, is shown as unavailable rather than silently omitted.

The transfer key

A locked record cannot be read by anyone who does not hold the key — not on the wire, not on a drive, not in an inbox.

Lock this record

The receiving hospital has to enter the key before a single line of it is readable. Generate one — twenty characters, avoiding letters that get misheard — or use a key the two hospitals already agreed. It is shown once, when the transfer starts.

Send it unlocked

Readable by whoever ends up holding the file. Only for a link you already trust end to end.

The key travels separately, by a different route

You telephone it, or hand it over in person. A key emailed alongside the bundle protects nothing — both halves are then in the same inbox.

A key hint — for example "the ward sister will telephone it to Dr Mballa" — is written on the outside of the locked file so the receiving hospital knows who to ask. Never put the key itself there.

What travels

The preview lists exactly what the bundle will contain before you send it.

Filed as live rows

Identity and demographics, next of kin, insurance cover, allergies, active conditions, medication, immunisations, vital signs and consultations. These are filed onto the chart at the far end.

Carried, not merged

Admissions, surgery, laboratory results and imaging studies. They travel in full and stay readable as history.

Why some sections are carried rather than merged

They hang off the sending hospital's own theatre list, test menu and vaccine lots. They arrive complete and stay readable, but they are not turned into local records — an invented bed number or a guessed formulary entry on a real chart is worse than no entry at all.

The console shows each stage as it happens: locating the record, collecting each section in turn, sealing, locking, transmitting, and waiting for confirmation. It can be shrunk to the corner while it runs.

Receiving a record

A bundle a colleague sent you as a file, or one a partner hospital pushed on its own.

Records pushed directly by a partner hospital arrive on their own and appear in the history. A file is dropped onto the Receive tab — a .json bundle produced by a Medi360 export.

What happens on arrival

Field	What it means
The seal is checked first	Verified before a single row is written. A record altered after it was sent is refused outright.
The patient is matched	Filed onto an existing record where one is found; otherwise a new patient record is created, and the outcome says which happened.
Duplicates are left alone	Entries the chart already holds are skipped and counted, rather than filed twice.
Nothing new is a real answer	If this hospital already held everything in the bundle, the outcome says so.

Unlocking a locked record

It arrived locked, and shows nothing about the patient until the key is entered.

A locked bundle is stored exactly as it arrived. The patient is not even named until it is opened — the transfer waits in an Awaiting key state, and the receiving hospital enters the key the sender gave them. That key comes from the sending hospital, never from this system.

Queued — accepted and waiting to start

Running — collecting, sealing or filing

Awaiting key — arrived locked; unreadable until the key is entered

Complete — sent, or filed onto the chart

Failed — stopped with a reason on the record

History

Every transfer, in both directions.

When, which direction, which patient, the other hospital, who did it and how it ended — filterable by Exported, Sent, Imported and Received. Because a release of a record is a disclosure, this is the list an audit will ask for.

Partner hospitals

The hospitals records may be exchanged with, and the keys the two systems use to recognise each other.

Registering a partner (administrators only)

Field	What it means
Hospital name, short code, city, country	How the partner appears throughout the module.
Their system address	The base URL of their Medi360 installation, e.g. https://records.stmarys.example
Key they present to us	Stored hashed and never shown again. Leave blank to keep the current one.
Key we present to them	Held encrypted so it can be sent. Leave blank to keep the current one.
Can send / can receive	Each direction is enabled separately.

A partner can be suspended and reactivated, and a new inbound key issued at any time — it is shown once and cannot be retrieved afterwards. Removing a partner takes away the destination and its keys; transfers already made stay in the history.

Good practices

Write the release reason as if it will be read out

It will be. It is the sentence the audit trail carries, and "transfer" on its own explains nothing to somebody reviewing a disclosure two years later.

Never put the key in the key hint

The hint rides on the outside of the locked file. It exists to say who to telephone, not to save the telephone call.

Send unlocked only over a link you already trust

A sealed but unlocked bundle proves it has not been altered. It does nothing to stop whoever holds the drive from reading it.

Back to all guides Book a live demo