Blockchain Health-Record Concepts

Health data can harm if it leaks. You will identify which parts of a health record could single out a person, and explain why collecting less data is the safest starting rule.

• Who sees what: patient, doctor, lab, insurer, family.
• Rights: access, correction, consent, deletion where allowed.
• Duties: keep records for a set time; keep them accurate.
• Errors can harm a patient.
• List the kinds of information a record holds, such as name, diagnosis code, test result and appointment date, and mark which ones could identify a person on their own or in combination.
• Treat every record as something its owner would not want a stranger to read, and before storing any field ask: who needs it, for what purpose, and for how long?
• Draw who creates, changes and reads a health record today.
• List the harm if one record is shown to the wrong person.

Activity. Map five people who touch a record.

Standard to meet. Map shows what each may see.

Common mistake. Thinking more sharing is always better.

Check yourself. Who needs what in your map?

A ledger is a shared list that is hard to change in secret. You will explain a shared ledger with an everyday analogy and compare it to an ordinary database, so you can judge when it adds anything.

• Blocks hold entries; each block carries the fingerprint of the one before.
• Change one old entry and every later fingerprint breaks.
• Many copies are kept by different parties.
• It records that something happened; it does not make it true.
• Explain a ledger to a friend as a notebook many people hold identical copies of, where each new page refers to the one before it, so changing an old page is noticed.
• Compare a shared ledger with a normal database in a table of four rows: who controls it, who can edit, how fast, and how easily data can be deleted.
• Practise the toy ledger with five invented rows.
• Check that no invented record looks like a real person.

Activity. Build a 5-row toy ledger in a spreadsheet.

Standard to meet. Link rows with a fingerprint column and show that a change breaks the chain.

Common mistake. Believing a ledger prevents wrong data.

Check yourself. What fixes wrong data?

A hash turns any data into a short fixed code. You will see a fingerprint code change when one character changes, and understand why storing proofs rather than content protects privacy.

• Same input gives same code; tiny change gives different code.
• You cannot work backwards from the code.
• Hash a file to prove it is unchanged.
• Never hash small guessable values alone (like a phone number).
• Show a hash with a tiny test: hash the sentence 'visit on 5 May', then change 5 to 6 and see the whole fingerprint change; this is why altered records stand out.
• Remember that a hash is one-way: you can check a record against its fingerprint, but you cannot rebuild the record from the fingerprint, so storing only hashes keeps content off the shared copy.
• Explain the idea to a friend in two minutes without jargon.
• List what must remain in a clinic system by law.

Activity. Hash three practice files and one edited copy.

Standard to meet. Compare and explain the codes.

Common mistake. Hashing small guessable values.

Check yourself. Which value would you not hash alone?

Patients should decide who sees what. You will write consent choices in plain language and plan identity steps, so people stay in control of who may see their information.

• Consent record: who, what, why, when, until.
• Withdraw consent as easily as giving it.
• Use pseudonyms, not names, on a shared ledger.
• Check who is who before granting access.
• Write consent as plain choices a person can understand in under a minute: who may see what, for how long, and how to withdraw, with a default of nothing shared.
• Plan identity checks in two steps, such as something they know and something they have, and decide what happens when someone loses access to their device.
• Ask how long records must be kept in your place.
• Note how consent can be withdrawn in an emergency.

Activity. Design a consent entry and a withdrawal entry.

Standard to meet. Check that entries contain no personal health data.

Common mistake. Putting names in consent entries.

Check yourself. What does your entry avoid?

Keep patient data off a shared ledger. You will sort every data item into kept off the chain, possibly on it, or never on it, avoiding the most damaging design mistake.

• Store records in protected systems; put only proofs and consents on the ledger.
• A ledger cannot delete: never put personal data on it.
• Think about access logs as evidence.
• Costs and speed of writing entries.
• Make a three-column table of items: kept off the chain (the record itself), possibly on the chain (a fingerprint, a consent receipt, a timestamp), and never on the chain (names, results).
• Decide where each item lives before building: records stay in a normal, secured store, and the shared ledger holds only small proofs pointing to them.
• Compare cost and speed of a ledger with a normal database.
• List who runs the ledger and who can stop it.

Activity. Draw a two-layer design.

Standard to meet. Diagram marks what is on and off the ledger.

Common mistake. Putting records on the chain "so they are safe".

Check yourself. Where does your record live?

A ledger is not always the answer. You will apply four screening questions to a proposed idea and tell a sensible use from one where a simpler tool works better.

• Helps: proof of unchanged records, consent trail, audit among many parties.
• Does not help: speed, privacy by itself, fixing wrong data.
• Ordinary databases are often better and cheaper.
• Ask: do several parties distrust each other and need a shared truth?
• Test a use case with four questions: is trust missing between parties, do many parties need the same record, is tamper-evidence valuable, and can a simpler tool do it?
• A good fit might be proving that a supply batch of equipment was checked on a date; a poor fit is storing full patient notes where corrections are routine.
• Write what you will not claim about security.
• List three alternatives to a ledger.

Activity. Score four ideas against five questions.

Standard to meet. Justify scores and reject at least one idea.

Common mistake. Choosing a ledger by fashion.

Check yourself. Which idea did you reject?

Think about harm first. You will rate five harms by likelihood and impact and plan for the worst two, treating ethics as part of design rather than an afterthought.

• Privacy law, health law and cross-border limits.
• Security of keys and devices.
• Fairness: who is left out if they lack a phone?
• What happens when something goes wrong?
• List at least eight risks with a likelihood and impact rating from 1 to 5. Start with leaked keys, wrong data entered, lost access, legal non-compliance and unfair exclusion. Address the top two first.
• Plan to check the rules in each place where the system would operate, and ask a qualified adviser before handling any real records, because this course teaches concepts only and uses invented data.
• Show the design to a health worker for comments.
• Keep a list of legal questions for an adviser.

Activity. Write a risk table with eight rows.

Standard to meet. Give each risk a control.

Common mistake. Ignoring people without phones.

Check yourself. How can a person without a phone take part?

Explain it to a decision maker in plain words. You will build a five-slide pitch with answers to hard questions, so a non-technical decision maker can weigh the idea fairly.

• One page: problem, idea, what is on and off the ledger, risks, cost.
• Show the toy ledger working.
• State clearly what it cannot do.
• Plan 90 days: consult adviser, test with fake data.
• Structure a short five-slide pitch to go with the one-page summary: the problem, who is affected, what goes on the chain and what does not, the risks, and the next small test using invented data.
• Prepare answers to three hard questions in advance: why not a normal database, who holds the keys, and what happens when someone withdraws consent.
• Record the limits of your toy in the summary.
• Plan how to test with only invented data.

Activity. Present to a peer circle and a mentor.

Standard to meet. Obtain the mentor's confirmation of no real data and no live-use claims.

Common mistake. Overstating readiness.

Check yourself. What limits does your summary state?

A patient asks for deletion of a record whose hash is on a ledger.

Question: What happens?

Model answer: Delete the record from the clinic system; the hash alone reveals nothing; document it.

An insurer wants access to all records.

Question: Your response?

Model answer: Only with specific, limited, time-bound consent, and the patient may refuse.

On the slide: L1 Basic · Basics of records

Notes: Explain what a health record holds and why it is private. Notes: list what is on a vaccination card and who needs to see it. Standard: each item has a reason to share or not.

On the slide: L2 Awareness · Awareness

Notes: Describe in plain words how a ledger links records so that tampering shows, and what it cannot do. Notes: toy ledger demo with paper cards or a spreadsheet. Standard: the demo shows a changed entry breaking the chain.

On the slide: L3 Foundation · Foundation

Notes: Map the people, data and consent in a record-sharing idea, and mark what must never go on a shared ledger. Notes: patient, clinic, lab and insurer on one page. Standard: no health detail on the ledger; only references and proofs.

On the slide: L4 Practitioner · Practitioner

Notes: Build a toy ledger with practice data and test one change, one consent withdrawal and one lost key. Notes: no real patient data, ever. Standard: each test is recorded with the result and the lesson.

On the slide: L5 Specialist · Specialist

Notes: Produce a concept design and risk review for a privacy-first health-record sharing idea, with a working toy ledger on practice data. Notes: the review lists legal limits, deletion rights and key loss. Standard: design keeps records off-ledger, and each risk has a control.

On the slide: L6 Advanced · Advanced

Notes: Review a design with a legal and clinical reviewer, set standards for consent and audit, and plan a safe pilot. Notes: add an ethics note and a withdrawal process. Standard: reviewers' comments answered in writing, and pilot limits stated.

On the slide: L7 Super expert · Super expert

Notes: Set the method for describing record integrity and consent without storing health data on a ledger, and teach it. Notes: re-read the health-data law for the place each year and update the examples.