What this subject family covers
Health informatics and digital health sit where health care, data and information systems meet. The field is less about the biology of disease, as in biomedicine, or the patterns of disease in populations, as in epidemiology. It is less about running services, as in health policy and management. Its main concern is how health information is recorded, stored, shared, analysed and used, and how digital tools change care.
Courses under this heading lean in different directions. Make sure your evidence fits the one you are applying to:
- Health informatics deals with how information flows through care: electronic records, clinical coding, interoperability between systems, decision support and the people who use these systems. Strong evidence shows that you understand both the technical side and the clinical or organisational context.
- Biomedical informatics often extends to genomic, imaging or laboratory data and can be heavily computational. Evidence of programming, statistics or work with biological data matters more here.
- Health information management centres on records, data quality, governance, coding, privacy and information law in practice. Careful, accurate work with records and an interest in standards and accountability count for more than coding skill.
- Digital health looks at apps, telehealth, remote monitoring, wearables and online services. It also covers design, adoption, evaluation and equity. Interest in users, implementation and evidence of benefit is central.
- Health data science focuses on analysing routinely collected or research data with statistical and machine-learning methods. Quantitative ability and an understanding of bias, missing data and confounding are the core.
Your statement should show which of these problems interests you. Saying only that technology and health are both important does not do that.
Interests that give a statement substance
Name a specific problem and show that you have thought about it. Useful starting points include:
- why hospitals, GP practices and social care often cannot share records easily, and what standards or governance would be needed to change that;
- how the quality of clinical coding affects research, funding and planning that use routine data;
- whether a digital tool actually improves outcomes, or simply moves work around or excludes people with low digital access;
- how algorithms trained on one population can perform worse for another, and how that bias might be detected;
- the tension between using patient data for research and respecting consent, confidentiality and public trust;
- alert fatigue and the usability of clinical systems, and how poor design affects safety;
- how remote monitoring changes the relationship between patients and clinicians.
Pick one or two of these and go into depth. Explain what first made the problem visible to you, what you read or tried, and what you still find unresolved. A list of buzzwords such as AI, big data or blockchain suggests surface interest. Be especially careful with claims that technology will solve health care.
Relevant preparation and activities
None of these is required. They are ways to produce evidence you can reflect on.
- Working with a public health dataset. Clean it, summarise it and note its limitations, using a spreadsheet, R or Python. The value lies in describing what was missing or inconsistent and how that limited your conclusions. The headline result matters less.
- A short programming or statistics course. This is most relevant for biomedical informatics and health data science. Mention what you built or analysed, not just that you finished the course.
- Reading about a real digital health rollout or data-sharing controversy. Reports, reputable journalism and academic papers can all help. Discuss what went wrong or right in terms of trust, governance, usability or evidence.
- Evaluating a health app you or a relative use. Consider who it suits, what data it collects, what evidence supports it and who might struggle with it. This is a reasoned critique, not research.
- Learning about a data standard or coding system. Find out at a basic level why structured clinical terminology exists, and say what problem it addresses.
- EPQ, dissertation or coursework projects. A project on data privacy, an algorithm audit or the uptake of telehealth is strong if you can explain your method and its weaknesses.
Connecting ordinary experience to this subject
Many applicants have no placement in a health IT team. Everyday experience can still be relevant if you state the connection precisely and do not overstate it.
- Reception or administrative work at a surgery, pharmacy, dental practice or care home. You may have seen booking systems, record-keeping, duplicate or incomplete records, or patients struggling with online services. This shows real contact with how health information works in practice. It does not show knowledge of clinical systems design or of governance beyond what you were trained in. Respect confidentiality and describe processes, never patients.
- Caring for a relative. Coordinating medicines, appointments, letters between services or remote consultations can show you how fragmented information affects patients. This gives you a user’s view of interoperability and digital access. It is one family’s experience, not evidence about systems in general.
- Retail, warehouse or hospitality jobs. Stock systems, tills and ordering tools are examples of how data entry errors spread and how staff work around clumsy software. The parallel to clinical systems is real but limited, because health data carries clinical risk and legal protection that stock data does not.
- Helping older people or neighbours use technology, or volunteering at a digital skills session. This connects directly to digital exclusion and to adoption, which matters in digital health. It shows awareness of users’ needs, not expertise in design.
- Maths, computing, biology or statistics coursework. A statistics project on sampling bias, or a computing project involving a database, can be linked to questions about health data. Spell out that link yourself rather than leaving it implied.
- Hobbies such as building websites, data visualisation, fitness tracking or gaming communities. Personal tracking data can lead into questions of accuracy and data ownership. A self-built tool shows technical initiative. Neither is clinical experience.
What useful reflection looks like
Reflection in this subject shows that you can see information as something produced by people and systems, with consequences. These are signs of strong reflection:
- Noticing where data comes from and why it might be wrong. Examples include who entered it, under what pressure, and with what categories available.
- Recognising that a technical fix can fail for human or organisational reasons.
- Weighing benefit against risk, such as convenience against exclusion, or research value against privacy.
- Stating the limits of your own evidence honestly, for example that a small dataset or a single app review cannot support general conclusions.
- Showing how an experience changed what you want to study, linked to the branch of the course.
For example, a weak sentence would be “Working at a pharmacy showed me the importance of technology in healthcare.” A stronger version describes noticing that prescriptions arrived with inconsistent information from different systems. It then explains what you learned about why that happens and which part of the course would help you understand it. Only write about what actually happened to you.
Subject-specific pitfalls
- Treating the field as computer science with a health label. Even very computational courses expect awareness of clinical context, ethics and data governance.
- Treating it as medicine by another route. Writing mainly about wanting to treat patients suggests the wrong course. Patient-facing motivation should lead to information or system problems.
- Uncritical enthusiasm for AI and apps. Show that you know tools need evidence and can cause harm or widen inequality.
- Ignoring privacy and confidentiality, including in your own anecdotes. Never include identifiable patient details.
- Overclaiming technical or professional roles. Using a booking system is not working in health informatics. Completing a tutorial is not developing a clinical tool.
- Mismatching the branch. Machine-learning ambitions sit poorly in a records management application. Interest in policy and governance needs some quantitative footing for a health data science course.
- Drifting into neighbouring subjects. Population disease patterns belong to epidemiology, and service strategy to health management. Mention them only where they connect to information and data.
Postgraduate applicants
Many courses in this area are taught at master’s level and take people from clinical, technical and administrative backgrounds. Make your starting point clear and explain what you need to add to it.
- Clinicians can describe a specific information or system problem they have met. They should be honest about limited technical skill and say how they are addressing it.
- Computing or data graduates should show understanding of health contexts, such as regulation, safety and clinical workflow. Technical credentials alone are not enough.
- Health administrators or coders can draw on detailed knowledge of records and data quality. They should name the analytical or design skills they want to develop.
In each case, describe your own contribution to any project and the result you can actually verify. Avoid assigning yourself a team’s achievement.
For general advice on planning, structure and editing, read our personal statement writing guide.
Health informatics and digital health personal statement examples