Portfolio & projects
In a field where anyone can generate a plausible answer, the thing that proves you can do the work is work you did — and can explain. How to build a portfolio that survives an interview.
In one line
A portfolio is the only claim about your ability that doesn't depend on someone believing you. In a field where a convincing answer to any question is now a few seconds away, work you did and can explain is the scarce thing.
The rule that comes before everything else
Never, ever put real patient data in a portfolio.
Not anonymised-by-you. Not "just a few rows". Not from your current employer. Not from your training hospital. This is the fastest way to end a health-informatics career before it starts, and it is a genuine breach of the people whose records they are — not a technicality.
Use synthetic data, and say so plainly:
- Synthea — realistic synthetic patients with full FHIR histories.
- The ABDM Sandbox — real APIs, test identities.
- Public reference data — LOINC, RxNorm, ICD.
- The labs on this platform, which are synthetic by design for exactly this reason.
A reviewer who sees you reached for synthetic data unprompted has learned something real about your judgement. That signal is worth more than the project.
What makes a project worth showing
Most portfolios fail the same way: they show that something works. Nobody is impressed that your code works — they assume it does, or that you'd have fixed it. What they're trying to find out is how you think when it doesn't.
So the projects that land are the ones that show a decision:
- An HL7 v2 → FHIR mapper where you documented what you couldn't map cleanly, and why.
The unmapped field is the interesting part. See
ConceptMap equivalences —
unmatchedis an honest answer. - A terminology mapping where you show the cases that were
narrowerrather thanequivalent, and what you decided to do about the loss. - An analysis where you found a confound and reported it — the readmission "trend" that was really a coding change.
- An ABDM integration at M1 that handles the consent callback arriving twice.
Notice the pattern. Every one of those showcases judgement under ambiguity, which is precisely the thing that can't be looked up and can't be generated for you.
Small and finished beats large and abandoned
Three small projects you can explain end-to-end are worth more than one ambitious repo that stops at 60%. A reviewer spends four minutes on your portfolio. They are looking for a reason to have a conversation, not a monument.
For each project, write a short README that answers:
- What problem? One sentence a non-engineer would understand.
- What did you decide, and what did you reject? This is the part they actually read.
- What broke? The bug that took you a day. What it taught you.
- What's still wrong with it? Naming your own project's weakness is the strongest credibility signal available to you, and almost nobody does it.
That fourth question is the one that separates a portfolio from a brochure.
Where the certificate fits
A certificate gets you past a filter. A portfolio gets you the job. They're not in competition — they answer different questions, at different stages, for different people. If you can only invest in one right now, and money is the constraint, build the portfolio: the FHIR spec, the sandboxes, the terminologies and the labs here are free, and the result is yours regardless of who does or doesn't recognise it.
The credential can be bought later, with the salary the portfolio earned you.