[{"data":1,"prerenderedAt":1457},["ShallowReactive",2],{"work-index":3,"site":1377},[4,279,512,629,855,1062,1184],{"id":5,"title":6,"body":7,"client":256,"deliverables":257,"description":258,"displayTitle":259,"extension":43,"featured":260,"hero":261,"heroAlign":262,"heroAspect":41,"heroComponent":263,"meta":264,"navigation":260,"path":265,"role":266,"seo":267,"stem":268,"tags":269,"team":274,"timeline":275,"tldr":276,"year":277,"__hash__":278},"work\u002Fwork\u002Fintelligent-incident-reporting.md","AI Isn't the Hard Part",{"type":8,"value":9,"toc":252},"minimark",[10,28,49,71,83,146,168,191,204,235],[11,12,15,22,25],"case-section",{"number":13,"title":14},"02","Context & Stakes",[16,17,18],"p",{},[19,20,21],"em",{},"Patient-safety incidents are inevitable in healthcare. Learning from them is not, and in Finland the data you would need to learn from was scattered across a dozen systems that don't talk to each other.",[16,23,24],{},"These incidents (the wrong dose, an avoidable infection, a complication that should have been caught) happen in every health system. Reporting them and learning from them is how you stop the avoidable harm from happening again. It's mandatory, but in practice often neglected. The estimates around the stakes are large: international figures put the cost of errors and harm at up to 13% of healthcare spending, and in Finland alone safety incidents are estimated to add up to roughly a billion euros a year. Reform of incident reporting is one of the 10 key metrics in Finland's national Client and Patient Safety Strategy for 2022 to 2026.",[16,26,27],{},"The problem is that the data needed to drive that learning barely exists in usable form. Mandatory adverse events flow into Hilmo, the national care registry, coded in ICD-10 and fed automatically from records, but near-misses never reach it. Voluntary reporting happens in local systems like HaiPro that stay at the level of a single organisation and never aggregate nationally. The result is incomplete, inconsistent, uncomparable data: enough to file, not enough to learn from, and not enough to steer a wellbeing services county's funding or safety work. That was the situation I was asked to study.",[11,29,32,35,38,46],{"number":30,"title":31},"03","Role & Approach",[16,33,34],{},"I ran the project end to end: the research and analysis, the process design, and the build. It was a research subproject inside Varha, the Wellbeing Services County of Southwest Finland, sitting under the national reform of incident reporting that the Ministry of Social Affairs and Health was funding. Varha's data-services team provided the secure environment the work had to run inside, and a Varha surgeon evaluated the reports the system generated. Being one person across the whole thing is why it spans research, design, and engineering rather than sitting in just one.",[16,36,37],{},"I framed the whole thing as design-science research, following the established six-stage model: identify the problem, define what a solution needs to do, design and build an artifact, demonstrate it, evaluate it, and communicate the result. In practice that meant interviewing my way to the requirements before I wrote a line of code, then building something real and putting it in front of a clinician to test, rather than arguing about AI in the abstract.",[39,40],"case-image",{"aspect":41,"caption":42,"size":43,"src":44,"align":45},"3\u002F2","The design-science research frame: from problem identification through to a built, evaluated artifact. Stage three is the GPT-4o proof-of-concept.","md","\u002Fimg\u002Fwork\u002Fintelligent-incident-reporting\u002Fmethodology.png","right",[16,47,48],{},"The interviews ran to 14 people: six doctors at Varha, all in senior surgical or clinical-information roles, and eight people across the national authorities (the ministry, the national health institute, the social-insurance institution, and the agency running the national data platform). I analysed them with reflexive thematic analysis, then used what I learned to design the process and the proof-of-concept.",[11,50,53,56,59,66],{"number":51,"title":52},"04","What I Found",[16,54,55],{},"Four requirements came up again and again: the systems need to integrate so the same thing isn't reported five times; classification needs to be standardised so data is comparable; AI could genuinely cut the reporting burden; and clinicians need feedback so reporting feels worth doing. The first three are technical. The fourth turned out to be the one that explains the others.",[16,57,58],{},"The sharpest recurring theme was that reporting feels futile. Clinicians are overworked and skip reporting unless an incident is clearly serious, partly because nothing visibly comes back when they do. You file into a system, and you never see it change anything, so the next time you don't bother. Underreporting isn't mostly a discipline problem; it's a feedback problem.",[60,61,63],"pull-quote",{"attribution":62},"Clinician, study interviews",[16,64,65],{},"THL collects adverse events in Hilmo, but I have never seen any feedback.",[39,67],{"aspect":41,"caption":68,"size":69,"src":70},"The synthesised findings: the four requirements (RQ1), the proof-of-concept's feasibility result (RQ2), and the national-level opportunities and barriers (RQ3). Underreporting and uncomparable data sit at the centre.","lg","\u002Fimg\u002Fwork\u002Fintelligent-incident-reporting\u002Fkey-findings.png",[11,72,75,80],{"number":73,"title":74},"05","Problem Definition",[16,76,77],{},[19,78,79],{},"Could a commercial LLM write the reports? Yes, and that turned out to be the simple bit. The harder, unfixed thing was the data beneath it: fragmented, uncomparable, and underreported.",[16,81,82],{},"This is the line the work lands on, in plain words: AI isn't the silver bullet here; a shift in the reporting culture is. A model that writes beautiful structured reports on top of data that is still entered five times, in five formats, into five systems that never aggregate, just produces nicer fragments. The real leverage is recording the event once, in the record where it already happens, auto-structuring it, and only then letting it flow somewhere it can be compared. The exact national report structure can't be settled by one project; that has to be defined with the authorities and clinicians, reusing international templates. But the shape of the fix was clear: change the process, and use the model inside it.",[11,84,87,110,128],{"number":85,"title":86},"06","Key Decisions",[88,89,91,98,104],"case-decision",{"title":90},"Human clinical evaluation, not automated text metrics",[16,92,93,97],{},[94,95,96],"strong",{},"Discarded:"," the convenient options. Automated NLP scores (BLEU, ROUGE, METEOR) measure textual overlap against a reference summary, not whether a clinical report is correct, and there is no established metric for structured output. Using another LLM as the judge is unreliable for factual medical knowledge.",[16,99,100,103],{},[94,101,102],{},"Chosen:"," a real clinician evaluating every generated report on a one-to-five scale across completeness, correctness, relevance, and coherence. The only evaluation that actually tells you if the output is clinically sound.",[16,105,106,109],{},[94,107,108],{},"Tradeoff:"," a single evaluator limits objectivity and reliability. I owned that as a known weakness rather than hiding behind a metric that looked rigorous but measured the wrong thing.",[88,111,113,118,123],{"title":112},"A general-purpose commercial model, run inside the county's walls",[16,114,115,117],{},[94,116,96],{}," building or fine-tuning a domain-specific or self-hosted model, which would have been a project in itself and was out of scope for a feasibility study.",[16,119,120,122],{},[94,121,102],{}," GPT-4o, at a low temperature (0.1) tuned for consistent clinical output, running inside Varha's own secure data environment so real patient records never left it. The pragmatic way to answer the actual question: can an off-the-shelf model do this at all?",[16,124,125,127],{},[94,126,108],{}," general-purpose models may not be the right long-term answer for healthcare. Whether a domain-specific or self-hosted open model would do better is a genuine open question I flagged for future work rather than pretended to have settled.",[88,129,131,136,141],{"title":130},"Design the process, don't just bolt on a tool",[16,132,133,135],{},[94,134,96],{}," treating the LLM as a standalone feature that summarises records on demand, which would have left the underlying duplicate-entry problem untouched.",[16,137,138,140],{},[94,139,102],{}," a single-entry reporting process with the model embedded in it and the clinician kept in the loop. Record the event once where care is documented, let the model generate a structured report, have the clinician review and sign it, then store it and send an anonymised copy onward.",[16,142,143,145],{},[94,144,108],{}," this only works if the national report structure gets defined centrally, which is beyond one project. But designing the process exposed exactly that dependency, which is more useful than a tool that hides it.",[11,147,150,153,157,160,165],{"number":148,"title":149},"07","Solution & Deliverables",[16,151,152],{},"The proof-of-concept ran on real, pseudonymised records inside Varha's environment: 40 patients, each with at least 10 free-text entries over five years, of which 21 had adverse-event codes and were used for the test. Per patient that was anywhere from 20,000 to over 700,000 characters of messy clinical text. The pipeline extracts the records flagged with adverse-event ICD-10 codes, combines them into one timestamped narrative per patient, and prompts GPT-4o with that text plus the required report structure, returning a structured incident report per distinct event.",[154,155],"poc-pipeline",{"caption":156},"The proof-of-concept pipeline: extract the adverse-event records (ICD-10 codes I26, J38.0, J93.8, L89, Y40–Y84, Y88), combine them into one timestamped narrative per patient, prompt GPT-4o with that text and the required report structure, and return one structured report per distinct event.",[16,158,159],{},"The designed artifact is the process the model belongs in: a single-entry reporting flow across three lanes (the clinician, the LLM, and the record system). The clinician records the event once as part of normal documentation; the system detects a likely incident; the model generates a prefilled, standardised report; the clinician reviews, edits if needed, and signs it; and the report is stored with the patient record while an anonymised copy is sent to a national database. Human oversight stays in; duplicate entry comes out.",[39,161],{"aspect":162,"caption":163,"size":69,"src":164},"2\u002F1","The single-entry process model (BPMN). Record once, auto-structure with the LLM, clinician reviews and signs, then store locally and send an anonymised copy to a national database. The fix is the process, not the model.","\u002Fimg\u002Fwork\u002Fintelligent-incident-reporting\u002Fprocess-model.png",[16,166,167],{},"What landed: a 113-page master's thesis; the single-entry process model; the working proof-of-concept and its clinical evaluation; and an international peer-reviewed publication of the interview insights and the PoC study.",[11,169,172,179,185],{"number":170,"title":171},"08","Outcomes",[173,174,176],"case-outcome",{"title":175},"The model held up clinically",[16,177,178],{},"Across the evaluation the generated reports scored a perfect five for coherence on every single one, with correctness and relevance consistently high and, notably, no hallucinations and no malformed structure. Completeness was the soft spot: on multi-faceted incidents the model sometimes missed details.",[173,180,182],{"title":181},"56 reports, 40 of them real",[16,183,184],{},"Across the 21 test patients the system generated 56 reports, of which 40 were genuinely treatment-related adverse events and 16 were not. So the quality of the structured writing was high; the real weakness was telling a care-related adverse event apart from other clinical issues. That looked like an artifact of asking the model to find many incidents at once, which the one-incident-at-a-time process is designed to avoid.",[173,186,188],{"title":187},"A validated concept that fed a national pilot",[16,189,190],{},"To the stakeholders' knowledge this was the first time a commercial LLM had been run on real patient data in this setting. It was published in an international peer-reviewed journal, and it fed directly into the Sitra-funded national pilot and architecture work that followed, and into the national vision for intelligent incident reporting. No national system has shipped: this is validated feasibility that set a direction, not a deployment, and I'm careful to call it that.",[11,192,195,198,201],{"number":193,"title":194},"09","Honest Reflection",[16,196,197],{},"The title is the reflection. The AI wasn't the hard part. The model did its job, and then the work argued that the model was the easy half: the bottleneck was the system around it, the fragmented data, the missing comparable structure, and a reporting culture where nothing comes back to the person who reported. That's still true for public healthcare, and it's the part I'd want anyone reading this to take away.",[16,199,200],{},"The honest limitations are real. I'd intended two or three clinicians to evaluate the output; delays meant a single evaluator, which is a genuine reliability caveat I own rather than gloss over. The research drew on one organisation and a narrow set of specialist surgeons, so the findings may not transfer cleanly to primary care or elsewhere. And a real share of the effort went not into the model but into territory nobody had charted, running a commercial LLM on real patient records under data-protection rules that partly pull against each other. None of that is a complaint; it's just where the difficulty actually lived.",[16,202,203],{},"It's also worth pinning to a date. This was 2024 into 2025, when doing this on real patient data was still close to uncharted, which is a big part of why the permissions and data-protection work above was so heavy. A couple of years on it already looks almost routine, and nobody would reach for GPT-4o for it now. The pace LLMs have moved at is genuinely wild, and a useful reminder that the model was always the part most likely to date, while the problem underneath it hasn't.",[205,206,208],"case-links",{"title":207},"Read more",[209,210,211,221,228],"ul",{},[212,213,214],"li",{},[215,216,220],"a",{"href":217,"rel":218},"https:\u002F\u002Furn.fi\u002FURN:NBN:fi:aalto-202503182886",[219],"nofollow","Master's thesis · Aalto University, 2025",[212,222,223],{},[215,224,227],{"href":225,"rel":226},"https:\u002F\u002Fpubmed.ncbi.nlm.nih.gov\u002F40588877\u002F",[219],"Peer-reviewed article · Studies in Health Technology and Informatics, 2025",[212,229,230],{},[215,231,234],{"href":232,"rel":233},"https:\u002F\u002Fasiakasjapotilasturvallisuuskeskus.fi\u002Fjusa-annevirran-blogikirjoitus-alykkaan-kansallisen-haitta-ja-vaaratapahtumien-raportointijarjestelman-kehittaminen-suomessa\u002F",[219],"Blog · Finnish Centre for Client and Patient Safety, 2025",[205,236,238],{"title":237},"Related work",[209,239,240,246],{},[212,241,242],{},[215,243,245],{"href":244},"\u002Fwork\u002Fpatient-safety-reform","Patient Safety Reform (the national reform this fed into)",[212,247,248],{},[215,249,251],{"href":250},"\u002Fwork\u002Fsurgical-complication-ai","Surgical Complication AI (the clinical pilot it seeded)",{"title":253,"searchDepth":254,"depth":254,"links":255},"",2,[],"Wellbeing Services County of Southwest Finland (Varha)","GPT-4o proof-of-concept, single-entry process model, clinical evaluation, peer-reviewed paper","A GPT-4o proof-of-concept turning free-text patient records into structured incident reports, for a Finnish healthcare authority. The model was the easy part.","Intelligent Incident Reporting",true,"\u002Fimg\u002Fwork\u002Fintelligent-incident-reporting\u002Fhero.png","full",null,{},"\u002Fwork\u002Fintelligent-incident-reporting","Researcher, designer & developer",{"title":6,"description":258},"work\u002Fintelligent-incident-reporting",[270,271,272,273],"Design Research","Healthcare","AI","LLM","Solo","2024–2025","Working solo inside a Finnish wellbeing services county, under the national patient-safety reform that funded it, I built a working proof-of-concept that prompts GPT-4o to turn free-text patient records into structured patient-safety incident reports. I ran the whole project end to end: research with clinicians and national authorities, a designed single-entry reporting process, and the model itself. In clinical evaluation it held up well, with no hallucinations. The harder finding was that the model was never the bottleneck: Finland's incident data is fragmented across a dozen systems and badly underreported, and a reporting culture where nothing comes back to the clinician is what actually needs fixing. The work was published in a peer-reviewed journal and fed directly into the Sitra-funded national pilot that followed.\n","2025","WkS8gWQrc2S4NeOEyRKc6upPH3YiMSyOup2fZdbN1ck",{"id":280,"title":281,"body":282,"client":493,"deliverables":494,"description":495,"displayTitle":496,"extension":43,"featured":260,"hero":263,"heroAlign":262,"heroAspect":41,"heroComponent":497,"meta":498,"navigation":260,"path":499,"role":500,"seo":501,"stem":502,"tags":503,"team":274,"timeline":508,"tldr":509,"year":510,"__hash__":511},"work\u002Fwork\u002Fiot-product-discovery.md","A Discovery That Outgrew Its Brief",{"type":8,"value":283,"toc":491},[284,297,326,347,364,420,460,480],[11,285,286,291,294],{"number":13,"title":14},[16,287,288],{},[19,289,290],{},"A portal built as an internal production tool had quietly become the primary customer touchpoint for tens of thousands of buildings.",[16,292,293],{},"The client is a European IoT provider. One of its services monitors tens of thousands of buildings, and a single web portal had become the one digital surface where customers and partners use that service: checking status, managing access, responding to alerts.",[16,295,296],{},"The portal was never designed as a customer product. It had been built as an internal production tool, and it hadn't been properly evaluated from the customer's side. It had become business-critical faster than it was ever designed to be. By the time I came in, the experience had grown fragmented, customers and support were absorbing the gaps with manual workarounds that didn't scale, and the product team knew it needed work but had no agreed picture of what to fix first, or why. The brief was practical: run a product discovery to improve the customer experience.",[11,298,299,302,305,308,311,315,318,323],{"number":30,"title":31},[16,300,301],{},"I ran this solo, owning the whole process end to end: research planning, fieldwork, synthesis, prototyping, the roadmap, and the stakeholder facilitation around it. The client's product, operations, and commercial leads acted as sponsors and as my route to customers and partners. The design and synthesis work was mine.",[16,303,304],{},"Across more than 20 sessions, moving fluently between the design questions and the technical architecture earned trust: I could follow a customer's surface complaint down to an integration gap or an undefined product model inside the same conversation, instead of handing the technical half to someone else.",[16,306,307],{},"The discovery had to fit inside the client's strategy-refresh window, so I kept it tight: three months, three loosely overlapping phases of research, synthesis, and strategy.",[16,309,310],{},"What made a one-person discovery viable at that pace was embedding AI in every phase of the work, not bolting it onto one task at the end. AI tooling transcribed and analysed hours of interviews and workshops in minutes, turning raw sessions into structured analyses; it held the full research context as a persistent second brain, so I could cross-reference findings across every session at once; and it synthesised patterns across more than 50 research artefacts. The same tooling generated interactive concept prototypes from research-grounded briefs in hours, and drafted the session guides, analyses, and deliverables I'd otherwise have queued behind myself. In practice, it did the work I'd otherwise have needed a team for.",[312,313],"process-double-diamond",{"caption":314},"A discovery-weighted double diamond. I owned the front half (Discover and Define) with AI running under every phase; the dotted second diamond is the delivery the roadmap scoped, not part of this engagement.",[16,316,317],{},"The point was never just speed.",[60,319,320],{},[16,321,322],{},"The real value wasn't doing it faster. It was depth: every design decision could trace back to a specific piece of customer evidence, because the whole research context was available at once.",[16,324,325],{},"I also wrote my assumptions down before fieldwork as hypotheses to test rather than conclusions to confirm; the strongest, that the portal's problems would look like UI problems but turn out to be structural, is the one the research validated most clearly.",[11,327,328,331,334,337,341],{"number":51,"title":52},[16,329,330],{},"The fieldwork came to more than 20 sessions in total, spanning internal stakeholders across product, commercial, operations, and technical roles and a range of customer and partner organisations, run as semi-structured interviews, focus groups, co-design workshops, and live portal walkthroughs. The customers ranged from large organisations managing many sites down to partners and resellers who touch the portal only occasionally. AI transcribed and analysed each session within minutes of it ending, so synthesis built continuously rather than waiting for a separate analysis phase.",[16,332,333],{},"The surface complaints were predictable: confusing navigation, internal jargon, weak feedback after you act, and a constant fallback to phoning a person. What the research made clear is that none of those were the actual problem. They were symptoms of how the service was wired underneath.",[16,335,336],{},"The sharpest pattern was that customers couldn't get a complete picture from the portal alone, so larger customers kept their own records on the side and reconciled by hand whenever the two disagreed. That manual workaround was the emotional low point of the journey, the place where trust quietly eroded. The other recurring theme was the human layer: customers genuinely valued and trusted the support people, and that trust was carrying the service, but it was also masking the cost, because support was effectively acting as a manual bridge between systems.",[338,339],"journey-map",{"caption":340},"The current-state journey, drawn from the research. Confidence holds while customers check status and place orders, then drops sharply at reconciliation, where the portal's data and their own records disagree and have to be squared by hand.",[60,342,344],{"attribution":343},"Customer & partner research, recurring theme",[16,345,346],{},"For the occasional user, the portal costs more effort than the phone call it was supposed to replace.",[11,348,349,354,357,361],{"number":73,"title":74},[16,350,351],{},[19,352,353],{},"\"Improve the customer experience\" was the brief. The discovery found those experience problems were downstream of a product one: the portal had never been defined or owned as a customer-facing product, so there was no shared picture of what it was for, who it served, or how it fit the wider service.",[16,355,356],{},"The reframe mattered because a UX-only engagement would have shipped a nicer interface on top of the same foundations: the same integration gaps, the same role ambiguity, the same manual reconciliation, now hidden behind cleaner screens. Laddering the pain points down through repeated \"why\" questions surfaced a small set of structural causes underneath the complaints: gaps in how systems were integrated, an undefined product and segmentation model with one portal trying to serve very different audiences at once, and too much of how the service worked concentrated in a few people rather than in the product itself.",[358,359],"reframe-ladder",{"caption":360},"The loud surface complaints were symptoms. Laddering each one down through 'why' kept landing on the same three structural causes.",[16,362,363],{},"The team didn't just need a list of fixes. They needed the evidence and the language to make the case for structural work to leadership.",[11,365,366,384,402],{"number":85,"title":86},[88,367,369,374,379],{"title":368},"Solo and three months, scoped to the decision window",[16,370,371,373],{},[94,372,96],{}," A larger engagement covering every customer segment in depth, with parallel workstreams and a longer runway. More coverage and more confidence, but at a much higher cost and outside the decision window.",[16,375,376,378],{},[94,377,102],{}," A solo three-month discovery focused on the highest-leverage customer and partner segments, sized to land inside the client's strategy-refresh cycle with a light footprint on the team's week.",[16,380,381,383],{},[94,382,108],{}," Less segment depth and no internal team to carry the work forward. I mitigated it by running the internal working group as an active sponsor rather than an audience, so the findings had owners before the final presentation.",[88,385,387,392,397],{"title":386},"AI-built prototypes as research probes, not a final reveal",[16,388,389,391],{},[94,390,96],{}," Polished interactive prototypes saved for a stakeholder reveal at the end of the engagement.",[16,393,394,396],{},[94,395,102],{}," Five interactive concept prototypes generated from research-grounded briefs with AI-assisted tooling, built and iterated in days rather than weeks and used as probes to provoke sharper conversations. Because they took hours to stand up, I could put them into the research itself rather than waiting for a separate design sprint, then hand them on as a concrete starting point to build from.",[16,398,399,401],{},[94,400,108],{}," They were starting points rather than production-ready design, but they turned abstract findings into something stakeholders could click, which moved internal conversations from defensive to generative. \"The portal lacks a single source of truth\" became \"here is what a unified view could look like.\"",[88,403,405,410,415],{"title":404},"A phased roadmap, not a single redesign brief",[16,406,407,409],{},[94,408,96],{}," One comprehensive redesign specification handed straight to engineering to build.",[16,411,412,414],{},[94,413,102],{}," A phased roadmap that deliberately sequenced foundational work ahead of surface work, so the visible UX improvements would land on solid ground instead of papering over the structural gaps underneath.",[16,416,417,419],{},[94,418,108],{}," Less immediately satisfying than a single redesign to point at, but it matched how the organisation actually makes investment decisions and let leadership commit incrementally. It also named why past attempts had stalled: surface work kept getting prioritised over foundations, then failing to hold.",[11,421,422,425,448,452,456],{"number":148,"title":149},[16,423,424],{},"What landed:",[209,426,427,430,433,436,439,442,445],{},[212,428,429],{},"A research synthesis, built with AI across 50+ research artefacts and written for a mixed product-and-leadership audience, anchored on personas spanning the customer-facing and internal roles",[212,431,432],{},"A current-state customer journey map identifying the manual-reconciliation step as the trust low point",[212,434,435],{},"A service blueprint exposing where manual work and single-person knowledge hide behind the portal UI",[212,437,438],{},"Process maps and a structured analysis laddering surface complaints down to their structural causes",[212,440,441],{},"Five interactive concept prototypes built with AI-assisted tooling, used as probes: a unified view, bulk operations, role-based dashboards, guided task flows, and clearer confirmation and feedback states",[212,443,444],{},"A phased roadmap sequencing foundations ahead of surface work",[212,446,447],{},"An executive presentation to the C-level, built around the symptoms-versus-structure reframe",[449,450],"portal-dashboard",{"caption":451},"Concept prototype, the dashboard: a real-time overview of sites by status (operational, attention, fault), the items needing action, open orders, and recent events. Built mid-discovery with AI-assisted tooling; layout shown, data fictional.",[453,454],"prototype-collage",{"caption":455},"Two of the other concepts, built with AI-assisted tooling. Left: order tracking on a parcel-delivery model (Ordered → Processing → Delivered → Installed → Commissioned), with the systems and event history that used to live in scattered email threads. Right: a single site profile that pulls one building's systems, connections, and remote-access log into one view, the thing the missing integration layer had made impossible. Layout shown, data abstracted.",[457,458],"workstream-roadmap",{"caption":459},"The phased roadmap: three workstreams with foundations leading. Surface UX ships quick wins early, but the larger redesign waits on the integration foundations underneath, so it lands on solid ground rather than papering over the gaps.",[11,461,462,468,474],{"number":170,"title":171},[173,463,465],{"title":464},"The reframe landed with leadership",[16,466,467],{},"Leadership engaged strongly with the symptoms-versus-structure framing. It changed the conversation from \"which screens do we redesign\" to \"who owns this as a customer product, and what do we fund first.\"",[173,469,471],{"title":470},"Input to the company's strategy update",[16,472,473],{},"The discovery surfaced structural dependencies the organisation hadn't had named before, and the findings fed directly into the company's strategy update, with the phased framing adopted as the basis for next steps.",[173,475,477],{"title":476},"A customer-perspective baseline, in writing",[16,478,479],{},"For the first time the portal had a documented reading of the customer experience. The journey map, service blueprint, personas, and process maps became reusable reference inside the product team.",[11,481,482,485,488],{"number":193,"title":194},[16,483,484],{},"What surprised me: how much of the \"UX problem\" was really a service-ownership problem. The portal's confusion about who it served traced straight back to organisational ambiguity about who owned which part of the customer relationship. No redesign could have fixed that, and it took the blueprint to make it visible.",[16,486,487],{},"What I learned: AI changes the economics of a discovery when it's embedded across the whole process, not bolted onto one task. Transcription and analysis dropped from days to hours, prototyping from weeks to days, but the deeper shift was that holding the entire research context at once kept every design decision traceable to specific evidence, even as a team of one. It's why a solo consultant could go both deep and wide in 12 weeks. Used carelessly it just adds noise; used well, it pulls the hard conversations forward to when they're still cheap to have, and keeps the work honest to what customers actually said.",[16,489,490],{},"And the part I'd keep: bringing the hard version to the room. The easy deliverable was \"here's a nicer portal\"; the honest one was \"the portal isn't the problem.\"",{"title":253,"searchDepth":254,"depth":254,"links":492},[],"Confidential","Research synthesis, journey map, service blueprint, concept prototypes, phased roadmap","A solo product-discovery engagement for a European IoT provider. A customer-experience brief uncovered a deeper product-strategy problem, and an AI-augmented way of working that let one designer move at the pace of a team.","IoT Product Discovery","SiteFieldHero",{},"\u002Fwork\u002Fiot-product-discovery","Service designer",{"title":281,"description":495},"work\u002Fiot-product-discovery",[504,505,506,507],"Service Design","Product Discovery","IoT","AI-assisted Design","12 weeks","As the sole consultant, I ran a 12-week product discovery for a European IoT provider, end to end: 20+ research sessions across internal teams, customers, and partners, with AI embedded in every phase, transcribing and analysing sessions in minutes, holding the full research context as a persistent second brain, and synthesising across 50+ artefacts. The brief was to fix the customer experience of the company's portal, but the loud UX complaints turned out to be symptoms of deeper structural causes, not a design problem. I made the findings tangible with five AI-built concept prototypes and delivered a phased roadmap, presented to the C-level, that fed directly into the company's strategy update.\n","2026","3V1WTVQDdi9xY9W_W1Rld0UJqkqAYRfPr6Fqhrf8d_Q",{"id":513,"title":514,"body":515,"client":609,"deliverables":610,"description":611,"displayTitle":612,"extension":43,"featured":613,"hero":614,"heroAlign":45,"heroAspect":41,"heroComponent":263,"meta":615,"navigation":260,"path":616,"role":617,"seo":618,"stem":619,"tags":620,"team":624,"timeline":625,"tldr":626,"year":627,"__hash__":628},"work\u002Fwork\u002Fnokia-6g.md","Why Would People Care About 6G?",{"type":8,"value":516,"toc":607},[517,527,543,563,572,599],[11,518,519,524],{"number":13,"title":14},[16,520,521],{},[19,522,523],{},"6G was years from standardisation, and almost all the research framed it as an engineering problem. We came at it as a human one.",[16,525,526],{},"Nokia is one of the world's network and telecommunications leaders, and in the summer of 2023 I joined as a design-research trainee working on the future of 6G. The brief was open: apply design thinking to 6G mobile-communication research and explore where it might go. The move we made early was one of framing. Most 6G research at the time sat in the enterprise and industrial domains; our project moved into the consumer realm, into the intersection of the digital, physical, and human worlds in everyday life, with sustainability and the UN Sustainable Development Goals as a guiding lens.",[11,528,529,532,535,539],{"number":30,"title":31},[16,530,531],{},"I worked as one of two design-research trainees, and the work was genuinely shared between us. We ran the summer on a double-diamond process: desk research on 6G technologies and emerging trends, expert interviews with domain specialists on 6G, sustainability, and use cases, and a series of brainstorming workshops to turn the research into ideas.",[16,533,534],{},"My clearest thread was on the design-thinking side. I co-created and helped run a design-thinking workshop that took the human-centric lens and made it something other people could use, walking the whole 6G standards team, leaders included, through a single provocation: what could Nokia's role be in the future of human augmentation.",[39,536],{"caption":537,"size":69,"src":538},"The double-diamond process across the summer: discover, define, develop, deliver.","\u002Fimg\u002Fwork\u002Fnokia-6g\u002Fprocess-doublediamond.png",[39,540],{"caption":541,"size":43,"src":542,"align":45},"The design-thinking worksheets in use during the workshop.","\u002Fimg\u002Fwork\u002Fnokia-6g\u002Fworkshop-5whys.jpg",[11,544,546,549,556,560],{"number":51,"title":545},"What We Found",[16,547,548],{},"The interviews kept circling the same point. The technical leaps mattered less than a basic human question: why would anyone care to move to 6G at all. The themes that came back were about value, not throughput. 6G has to be human-centric and bring tangible value to people's lives. It has to be sustainable, in energy and in hardware. It has to be inclusive, reaching users who are usually left out. And it has to make economic sense for the operators who carry it. Organised against the SDGs and broader megatrends, the opportunity clustered into a few domains: health and wellbeing, learning and education, and the future of work.",[16,550,551,552,555],{},"Out of that, one thesis pulled the rest together: ",[94,553,554],{},"human augmentation through wearables."," Wearables that extend human senses and cognition, from AR glasses to brain-computer interfaces, with 6G as the connective tissue that makes them viable, carrying low-latency, high-bandwidth traffic between body and cloud in a way 4G and 5G couldn't.",[39,557],{"caption":558,"size":69,"src":559},"The synthesis: human augmentation through wearables, with 6G as the enabler between the digital and physical worlds.","\u002Fimg\u002Fwork\u002Fnokia-6g\u002Fhuman-augmentation.png",[16,561,562],{},"That shift, from performance to human value, is what turned a broad technology scan into a focused point of view.",[11,564,566,569],{"number":73,"title":565},"Deliverables",[16,567,568],{},"Two things came out of the summer. The first was a design-research vision: the human-augmentation thesis, the interview insights and sustainability framing behind it, and a set of speculative \"what if\" use-case scenarios across health, learning, and work, each anchored to a real present-day product so the future felt concrete rather than abstract.",[16,570,571],{},"The second was a design-thinking workshop format: a reusable method that took the human-centric lens and handed it to others to apply, so the perspective could outlast a single deck.",[11,573,574,580,586,592,596],{"number":85,"title":171},[173,575,577],{"title":576},"A human-centric vision for 6G",[16,578,579],{},"A synthesized point of view, human augmentation through wearables, that reframed 6G around human value rather than raw technical performance.",[173,581,583],{"title":582},"A reusable design-thinking method",[16,584,585],{},"A workshop format, run with the 6G standards team so an engineering-led group could apply the human lens to 6G itself.",[173,587,589],{"title":588},"Presented to the team and its leaders",[16,590,591],{},"The work landed in a seminar to the whole standards team, leaders included, on top of separate presentations to other Nokia leaders along the way. It fed into how the team framed and talked about value in its 6G work.",[39,593],{"caption":594,"size":69,"src":595},"Presenting the 6G design-research vision to the standards team at the closing seminar.","\u002Fimg\u002Fwork\u002Fnokia-6g\u002Fseminar-team.jpg",[16,597,598],{},"This was exploratory, pre-standard foresight, so the deliverables are a point of view and a method rather than a shipped product or a metric. What they shifted was the conversation.",[11,600,601,604],{"number":148,"title":194},[16,602,603],{},"The most valuable thing the project did was that reframe. Getting to put it in front of the standards team and its leaders, and watching it feed into how they framed value, was the part I'm proudest of. It's the one I still reach for.",[16,605,606],{},"This was foresight, not validation. The scenarios were speculative, built on today's reference products rather than tested concepts, and 6G itself was years from standardisation. In work that far ahead, the most you can really claim is that you changed how a few smart people frame the question. That, I think, we did.",{"title":253,"searchDepth":254,"depth":254,"links":608},[],"Nokia","Research vision, use-case scenarios, reusable workshop method","A summer design-research traineeship at Nokia, reframing 6G from a technical question into a human one and converging on human augmentation through wearables.","Future of 6G",false,"\u002Fimg\u002Fwork\u002Fnokia-6g\u002Fcontext-sdg.png",{},"\u002Fwork\u002Fnokia-6g","Design researcher",{"title":514,"description":611},"work\u002Fnokia-6g",[270,621,622,623],"Strategic Foresight","6G","Sustainability","2 design-research interns","Jun–Aug 2023","As one of two design-research trainees at Nokia over a summer, I helped reframe 6G from an engineering question into a human one. Through desk research, expert interviews, and design-thinking workshops, we moved the question from \"what can 6G do\" to \"why would people care\", and converged on human augmentation through wearables as the through-line, with 6G as the connectivity that makes it viable. We delivered a research vision and a reusable workshop method to seed that human-centric lens inside an engineering-led field.\n","2023","LbKzBFvY2irqb-dN7eW-PxxwlR2fdx7TCwTdHHNm5BQ",{"id":630,"title":631,"body":632,"client":838,"deliverables":839,"description":840,"displayTitle":841,"extension":43,"featured":260,"hero":842,"heroAlign":262,"heroAspect":719,"heroComponent":263,"meta":843,"navigation":260,"path":844,"role":845,"seo":846,"stem":847,"tags":848,"team":851,"timeline":852,"tldr":853,"year":627,"__hash__":854},"work\u002Fwork\u002Fnordea-green-banking.md","A Bank That Did the Work but Couldn't Show It",{"type":8,"value":633,"toc":836},[634,647,667,702,720,780,806,825],[11,635,636,641,644],{"number":13,"title":14},[16,637,638],{},[19,639,640],{},"Nordea did a great deal on sustainability. Almost none of it reached the young customers it most wanted to win.",[16,642,643],{},"Nordea is the largest bank in the Nordics: 9 million customers, two centuries of history, and a substantial sustainability program behind it. But 45% of its customers didn't know what sustainability even meant in a banking context.",[16,645,646],{},"For a generation that increasingly picks brands on values, that gap was a strategic risk, not just a PR one. A 2022 Tink survey of UK consumers found that 43% would switch to a provider that let them see the environmental impact of their spending. The brief was direct: design a concrete \"green\" offering for 18-to-30-year-olds, and communicate it without tipping into greenwashing.",[11,648,650,653,656,660,663],{"number":30,"title":649},"Role & Team",[16,651,652],{},"This was a university design capstone, an industry project run over roughly seven months with a five-person multidisciplinary team: two of us from business, two from design, and me from the technology side. The work was genuinely shared. We made most calls by consensus and split tasks by what each phase needed rather than by fixed titles, working through a double-diamond process and reporting to Nordea's Personal Banking team with weekly mentoring from a design lead.",[16,654,655],{},"Two threads were clearly mine. I led the feasibility meeting with Nordea's tech and design contact, where we walked through whether our mobile-app concepts could actually be built on the platform they already ran. And I was the main person running the wireframe prototyping sessions with users. In Figma I worked shoulder-to-shoulder with two teammates, splitting the build between us. That suited me: I was most useful moving between what users said, what the design needed, and what was technically realistic.",[39,657],{"caption":658,"size":43,"src":659,"align":45},"The team mid-project: synthesis on one screen, wireframes on the table.","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Fteamwork.jpg",[16,661,662],{},"We worked through a double-diamond process across four phases, from discovery and field research, through synthesis, into design and prototyping.",[39,664],{"caption":665,"size":69,"src":666},"The double-diamond timeline: discover, define, develop, deliver, mapped to the project's milestones.","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Fprocess-timeline.png",[11,668,669,672,675,689,693,696],{"number":51,"title":545},[16,670,671],{},"On top of desk research and benchmarking, we ran a three-part qualitative study. An online survey reached 47 young adults, which we treated qualitatively given that the sample skewed toward Aalto students. We interviewed 10 people across three life stages: upper-secondary students, university students, and graduates under 30 in working life. We ran expert interviews inside Nordea (responsible investments, responsible product and finance, diversity and inclusion) and outside it, and spent a week in Hamburg and Berlin meeting sustainable and neo-banks, among them Tomorrow, N26, and Cooler Future. Then we synthesised everything with affinity mapping.",[16,673,674],{},"A few findings reset our assumptions:",[209,676,677,680,683,686],{},[212,678,679],{},"Young customers saw banks as old-school, opaque, and hard to trust, and didn't connect banking to sustainability at all.",[212,681,682],{},"They were least interested in the things banks love to report: carbon-neutral offices, less paper, even green home loans. They read those as the bare minimum, or as quiet greenwashing.",[212,684,685],{},"What they cared about was where the bank's money goes. Both the users and the experts agreed that a bank's lending and investment choices matter far more than any individual's habits.",[212,687,688],{},"They wouldn't pay extra for \"sustainability\" in the abstract, only for something with concrete, tangible value.",[39,690],{"caption":691,"size":69,"src":692},"Synthesising the research on a shared board: hundreds of observations clustered until one central gap surfaced.","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Fsynthesis-board.png",[16,694,695],{},"One finding already pointed to the answer: the single place all of this had to live was the mobile app. It was their main, often only, touchpoint with a bank, and several had switched banks purely for a better one.",[60,697,699],{"attribution":698},"User interviews, recurring theme",[16,700,701],{},"How you actually use your money matters more than whether a single loan happens to be labelled green.",[11,703,704,709,712,715],{"number":73,"title":74},[16,705,706],{},[19,707,708],{},"Design a green product, said the brief. The research pointed somewhere else: not at a missing product, but at a bank whose work no one could see.",[16,710,711],{},"Nordea wasn't failing on sustainability. It was failing to make its sustainability visible and meaningful to young customers. The real problem was a communication and education gap: a bank doing a great deal, customers who couldn't see it, and a subject that stayed abstract right up until it touched their own money.",[16,713,714],{},"We drew it as a systems map, with the youth's perception of banks on one side, their unmet need for transparency and education on the other, and tightening regulation pushing the whole field from above. The opportunity sat in the middle, and it wasn't a new product or a campaign. It was making sustainability tangible and actionable inside the one place young customers actually showed up. We also accepted there was no single answer for everyone, since needs shift sharply across the 18-to-30 years.",[39,716],{"caption":717,"size":43,"src":718,"aspect":719},"The systems map: youth perception of banks on one side, demand for transparency and education on the other, our solution bridging the middle through mobile.","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Fsystems-map.png","16\u002F9",[11,721,722,740,758,776],{"number":85,"title":86},[88,723,725,730,735],{"title":724},"Build inside the existing app, not a new product",[16,726,727,729],{},[94,728,96],{}," A standalone sustainable product or a fresh communications push, which was the most literal reading of the brief.",[16,731,732,734],{},[94,733,102],{}," New features inside Nordea's existing mobile app, the youth's primary touchpoint. I took our concepts into a feasibility session with Nordea's tech and design side, and we confirmed they could be built without a new app.",[16,736,737,739],{},[94,738,108],{}," Less of a flashy \"new offering\" to point at in a pitch, but far more likely to reach real users and to survive contact with the platform Nordea already runs.",[88,741,743,748,753],{"title":742},"Give the bank the same yardstick as the user",[16,744,745,747],{},[94,746,96],{}," Presenting Nordea's sustainability work as the bank's own good-news story, the way an annual report does.",[16,749,750,752],{},[94,751,102],{}," A comparable impact score for the bank, on the same scale as the user's. We made this call after prototype users dismissed Nordea's self-reported impact as PR and flagged it as greenwashing.",[16,754,755,757],{},[94,756,108],{}," It puts the bank on the same measured footing as a 23-year-old's grocery spend, which is humbling for a 200-year-old institution. It was also the only version users actually trusted.",[88,759,761,766,771],{"title":760},"Prototype as a probe, and kill what failed",[16,762,763,765],{},[94,764,96],{}," Polishing a single hero concept to reveal at the end.",[16,767,768,770],{},[94,769,102],{}," Low-fidelity wireframes and paper prototypes tested with nine users, routed by a short onboarding survey into a consumption, investing, or learning flow.",[16,772,773,775],{},[94,774,108],{}," Rougher artefacts, but we learned fast, and we got to drop a feature that didn't work. A peer-to-peer advice forum sounded right on paper, since young people trust friends over bank advisors, but it fell apart in testing: users distrusted answers from strangers, and it would have needed heavy moderation to be safe.",[39,777],{"caption":778,"size":69,"src":779},"Paper prototypes of the Impact Hub: a personal impact score, the bank's own sustainability actions, and its impact, sketched to test fast with users.","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Fpaper-prototypes.jpg",[11,781,782,785,792,796,802],{"number":148,"title":149},[16,783,784],{},"We proposed a redesigned mobile banking experience for 18-to-30-year-olds, built into Nordea's existing app, with two features.",[16,786,787,788,791],{},"The ",[94,789,790],{},"Impact Hub"," turned sustainability into something a person could see. It gave each user a personal impact score across their consumption and investments, broken down by category and benchmarked two ways: against the Paris Agreement's 1.5°C goal, and against \"people like you.\" It also gave Nordea its own impact score on the same scale, with bite-sized summaries of what the bank was actually doing. Transparency became a shared number rather than a brochure.",[39,793],{"caption":794,"size":69,"src":795},"Impact Hub concept: a personal impact score, with consumption benchmarked against the Paris 1.5°C goal and against similar users.","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Fimpact-hub.png",[16,797,787,798,801],{},[94,799,800],{},"Learning Hub"," made financial and sustainability education feel like the apps young people already use: gamified, bite-sized, personalised, with progress to track. We framed it as a natural extension of Nordea's existing school workshops, carried into the app.",[39,803],{"caption":804,"size":69,"src":805},"Learning Hub concept: gamified, bite-sized finance and sustainability lessons, personalised to the user.","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Flearning-hub.png",[11,807,808,814,820],{"number":170,"title":171},[173,809,811],{"title":810},"A concept the product team called buildable",[16,812,813],{},"In the feasibility session, Nordea's customer-experience and product-strategy people confirmed the features could be implemented for the 18-to-30 segment inside the existing app, with no need for a separate product.",[173,815,817],{"title":816},"It landed with leadership",[16,818,819],{},"We presented the final concept in a one-hour session to Nordea's leadership. It was nerve-wracking, and it drew a lot of strong, engaged feedback rather than polite nods.",[821,822],"case-video",{"caption":823,"id":824},"Our pitch at the IDBM Impact Gala (2023), presenting the concept publicly.","6KLubeYoLDk",[11,826,827,830,833],{"number":193,"title":194},[16,828,829],{},"What surprised me was how confidently we could be wrong about an \"obvious\" feature. The peer-advice forum followed straight from our own research, that young people trust friends over bank advisors, and users still rejected it the moment they saw it. It taught me to treat even well-evidenced ideas as hypotheses until someone actually tries them.",[16,831,832],{},"What I'd do differently is recruitment. Our sample leaned heavily on Aalto students and the Helsinki area, and the young people who go straight from vocational school into working life, probably the least engaged with this topic and the most interesting to convince, were exactly the ones we struggled to reach. I'd design the recruiting around that gap from the start, not discover it at the end.",[16,834,835],{},"The thing I'm still sure of is the core move. Transparency for this audience was never about more information. It was about giving the bank and the customer the same number to look at.",{"title":253,"searchDepth":254,"depth":254,"links":837},[],"Nordea","Impact Hub + Learning Hub concepts, systems map, paper prototypes","A university design capstone for Nordea. Research with young customers turned a \"green product\" brief into a mobile concept that made the bank's sustainability tangible.","Green Banking","\u002Fimg\u002Fwork\u002Fnordea-green-banking\u002Fhero.jpg",{},"\u002Fwork\u002Fnordea-green-banking","Service & UX designer",{"title":631,"description":840},"work\u002Fnordea-green-banking",[504,849,850,623],"UX Research","FinTech","5-person team, business\u002Fdesign\u002Ftechnology","Nov 2022 – Jun 2023","Over seven months, a five-person team and I ran research with 18-to-30-year-olds for Nordea and reframed a \"design a green product\" brief into the real problem: a communication and education gap, not a missing product. We proposed a redesigned mobile experience inside Nordea's existing app, with an Impact Hub that scored the customer's and the bank's sustainability on the same scale, and a gamified Learning Hub. Nordea's product team confirmed it was buildable, and we presented it to leadership.\n","o34zZUtNP-S-e7wF9uCCJOd20FX0WnGXPtqFEodr0Wc",{"id":856,"title":857,"body":858,"client":1046,"deliverables":1047,"description":1048,"displayTitle":1049,"extension":43,"featured":260,"hero":263,"heroAlign":262,"heroAspect":41,"heroComponent":1050,"meta":1051,"navigation":260,"path":244,"role":1052,"seo":1053,"stem":1054,"tags":1055,"team":1059,"timeline":263,"tldr":1060,"year":277,"__hash__":1061},"work\u002Fwork\u002Fpatient-safety-reform.md","A Shared Picture Before a Shared System",{"type":8,"value":859,"toc":1044},[860,873,884,901,911,967,983,1003,1014,1030],[11,861,862,867,870],{"number":13,"title":14},[16,863,864],{},[19,865,866],{},"Finland has no single place to see the harm its own health system causes. The data exists. It's just scattered across a dozen registers that were never built to talk to each other.",[16,868,869],{},"There is no national repository that lets anyone track, compare, and learn from patient-safety incidents across Finnish social and health care. Incident data is fragmented across many separate statutory registers, recorded inconsistently, and rarely current, so the country can't reliably see where harm is happening or whether anything is improving.",[16,871,872],{},"The stakes are not small. The reform plan estimates that correcting healthcare harm costs Finland over a billion euros a year; in 2024 alone, 25 million euros was paid out in patient-injury compensation, with the cost to providers many times higher. Up to roughly half of these events are thought to be preventable, and voluntary reporting systems typically capture only 5 to 20 percent of the harm that actually occurs. The mandate to fix this is real: the WHO Global Patient Safety Action Plan makes incident-reporting uptake one of its top indicators, Finland's national patient-safety strategy puts reporting reform in 10 of its 12 objectives, and national audits and research had all already recommended a national system to monitor, compare, and learn. The Ministry of Social Affairs and Health tasked the Finnish Centre for Client and Patient Safety with delivering exactly that.",[11,874,875,878,881],{"number":30,"title":31},[16,876,877],{},"After building a proof-of-concept on AI-assisted incident reporting inside a wellbeing services county, the Finnish Centre brought me onto the national reform. For most of it there were two of us working full-time: the programme director and me. My half was the systems and the technical view.",[16,879,880],{},"My core job was to map the entire fragmented current state: every statutory way an incident gets recorded and reported in Finland, and every system and authority involved. In practice that meant interviewing and meeting a large part of Finnish public healthcare, plus every patient and client record-system vendor, since I was the only person on the project with the technical depth to engage them on how the systems actually work. In parallel I scoped possible collaborations and joint funding bids with public and private partners, one of which became a Sitra-funded pilot on surgical-complication reporting. I also owned the AI thread, keeping the reform current with a field that was arriving in healthcare very fast, through meetings with AI companies, startups, and cloud providers.",[16,882,883],{},"The rest of the work was designing the future-state vision and then validating it, round after round, with the national bodies that hold the data: the Finnish institute for health and welfare, the expected home for a future national repository, and the social-insurance institution, which runs the national Kanta data platform. How data ownership should work across them, where it should live, who holds it, how it moves, was still an open question, and a large part of the design was reconciling the options into something everyone could stand behind, along with the agencies (the medicines authority, the radiation-safety authority, and others) that ultimately consume incident data. It's strategic and systems design, but it only worked because I could also read the architecture.",[11,885,886,889,893,896],{"number":51,"title":52},[16,887,888],{},"The mapping turned up at least 10 distinct statutory recording and reporting procedures, each with its own law and its own receiving authority: ordinary patient-record entries, national care notifications, healthcare-associated infections, medically-related deaths, drug adverse effects, medical-device incidents, radiation-safety deviations, and more. Each was a separate pipe to a separate place.",[890,891],"fragmentation-map",{"caption":892},"The current state, simplified. A single incident at the point of care is recorded and reported separately into a dozen authorities and registers, in inconsistent terminology, with no path that aggregates it into a national picture or feeds anything back.",[16,894,895],{},"Laid side by side, the pattern was unmistakable. The same harm gets entered many times, in incompatible ways, into systems that never aggregate. Terminology drifts (the same event is called different things by different authorities), recording quality varies, voluntary systems capture only a fraction of real events, and the lessons that local incident systems do produce almost never spread beyond the organisation that learned them.",[60,897,898],{},[16,899,900],{},"The problem was never a missing reporting form. It was that the same incident is recorded over and over, in formats that don't match, and none of it flows anywhere it can be compared or learned from.",[11,902,903,908],{"number":73,"title":74},[16,904,905],{},[19,906,907],{},"The procedures everyone wanted reformed were the symptom, not the cause. The real task was to redesign the whole data lifecycle so an incident is recorded once and then flows, through shared structures, to the authorities and into one national repository that feeds learning back to providers.",[16,909,910],{},"This is the spine the target state is built on, recording once. Today a single harm can be entered into the patient record, and a medicines-authority report, and a local voluntary system, separately, by hand, in mismatched terms. The future-state principle is to record it once where care already happens, in a nationally defined structure with standard classifications, and let it move from there. Transparency and national learning aren't a new form to fill in. They're what you get when an event is recorded once, in a shared structure, and allowed to flow.",[11,912,913,931,949],{"number":85,"title":86},[88,914,916,921,926],{"title":915},"Three architecture options, not one forced answer",[16,917,918,920],{},[94,919,96],{}," picking a single future architecture up front and asking everyone to commit to it. Cleaner to present, but it would have collapsed under the first disagreement about data ownership.",[16,922,923,925],{},[94,924,102],{}," three target-state scenarios for how incident data could flow nationally, framed as alternatives with explicit tradeoffs, with the first two designed as sequential phases (start close to today's direct deliveries, evolve toward a single national channel as standardised transfer matures).",[16,927,928,930],{},[94,929,108],{}," more to align on and slower to a single answer. But it matched how national infrastructure actually changes, incrementally, and gave the data holders a real choice to reason about instead of a verdict to resist.",[88,932,934,939,944],{"title":933},"Build on international standards, not a bespoke Finnish code set",[16,935,936,938],{},[94,937,96],{}," defining a quick, Finland-specific data model that could ship sooner.",[16,940,941,943],{},[94,942,102],{}," anchoring the future state on international classifications and a shared national data model, so incident data is interoperable and reusable without separate extractions, and so the model can extend across counties and report types rather than becoming another island.",[16,945,946,948],{},[94,947,108],{}," the standards it depends on are years from full adoption, which puts much of the roadmap on a timeline the project does not control. I treated that as a known dependency to design around, not a reason to cut a faster but disposable corner.",[88,950,952,957,962],{"title":951},"AI as a staged capability, not an immediate autopilot",[16,953,954,956],{},[94,955,96],{}," positioning AI as the thing that fixes reporting now: identify the incident, classify it, file it, automatically.",[16,958,959,961],{},[94,960,102],{}," sequencing structures and data processes first, with AI's role growing as it can be slotted into recording, transfer, analysis, and reporting. The vision is genuinely AI-assisted, but staged.",[16,963,964,966],{},[94,965,108],{}," less exciting than \"AI solves it,\" and I said as much in the plan: full automation isn't possible yet, models misread complex cases, severity grading is still imperfect, and output quality has to be assured. Being honest about that was the point.",[11,968,969,972,976,979],{"number":148,"title":149},[16,970,971],{},"The core deliverable was a national master plan for reforming how patient-safety incident data is produced: the background and justification, the goals and scope, a full documented current state of every statutory recording and reporting channel, the target state on a five-to-ten-year horizon with its risks, and the follow-up work. Underneath it sat the design.",[973,974],"record-once-flow",{"caption":975},"The future-state principle: record the incident once, in a nationally defined structure with standard classifications, then let it flow through the national data platform to one repository that aggregates it and feeds learning back to providers. One entry, many uses, instead of many entries and no learning.",[16,977,978],{},"What I designed and assembled into it: a documented current-state model of the whole fragmented landscape; a single service-agnostic future reporting process (record once, structure with a shared data model, route through the national platform); three future-state architecture scenarios for how the data flows nationally; a concept for a national incident repository that aggregates the statutory data; the target-state change tables mapping today's fragmentation to a unified, AI-assisted future; and an AI-assisted reporting vision running through all of it. The plan also names its own next deliverable: the five-to-ten-year roadmap that turns this into a sequence of fundable steps.",[39,980],{"caption":981,"size":69,"src":982},"One of the main future-state options I drafted, and the detailed version of the record-once principle above. An incident is recorded once into the patient record, carrying the shared data model and international classifications (ICD-11, SNOMED CT), then flows via HL7 FHIR to the national Kanta platform and on to a national repository, with the medicines and radiation authorities, the supervisory authority, and the EU health-data space connected in. How the national authorities would split the roles, and who would ultimately hold the data, was still open, so this is one of a few configurations explored at the time; the work is ongoing.","\u002Fimg\u002Fwork\u002Fpatient-safety-reform\u002Fvision.png",[11,984,985,991,997],{"number":170,"title":171},[173,986,988],{"title":987},"A delivered national plan and the architecture beneath it",[16,989,990],{},"The master plan was completed and dated as a Centre publication, carrying the current-state map, the record-once future process, the three architecture scenarios, and the AI vision. It is a concrete artifact that did not exist before: the first shared, end-to-end picture of how patient-safety incident data is produced in Finland and how it could be produced instead.",[173,992,994],{"title":993},"A foundation, honestly, not a finished reform",[16,995,996],{},"The reform itself is a five-to-ten-year programme that was being planned, not delivered. There is no shipped system, no adoption metric, and no measured drop in harm yet: most of the changes sit at \"need identified\" or \"in progress,\" much of the roadmap depends on national standards and platforms maturing, and the plan wasn't yet public when I left it. What it did was set direction and build alignment, which in a system this fragmented is the part that has to come first.",[173,998,1000],{"title":999},"Tied to work that did produce a result",[16,1001,1002],{},"The reform grew directly out of the proof-of-concept I had built and validated earlier, which demonstrated technical feasibility, was published in a peer-reviewed journal, and seeded the Sitra-funded pilot scoped during this engagement. The strategy and the working prototype reinforced each other.",[11,1004,1005,1008,1011],{"number":193,"title":194},[16,1006,1007],{},"What this came down to was alignment, not technology. Pulling policy, process, and technology into one shared national vision, across ministries, national data holders still settling who owns what, the authorities who consume the data, and the vendors who build the systems, was the actual work. In a system this fragmented, most of the design is building a shared picture before anyone can build a shared system. The map and the vision weren't preludes to the work. They were the work.",[16,1009,1010],{},"What I would be honest about: the future state leans heavily on programmes I didn't control, international classifications and national platform development that are years out, so a real share of the roadmap is gated on other people's timelines. We also deliberately scoped out near-misses and no-harm events to keep the first reform tractable, even though they matter for prevention, and that's a coverage gap worth naming rather than hiding. And the AI vision, real as it is, is staged on purpose, not magic.",[16,1012,1013],{},"More than anything, this needed someone who could sit between the policy and the architecture and translate in both directions: enough of a designer to draw the future state, enough of an engineer to know it could actually be built. That bridge, not a better reporting form, is what a reform this fragmented runs on.",[205,1015,1016],{"title":207},[209,1017,1018,1025],{},[212,1019,1020],{},[215,1021,1024],{"href":1022,"rel":1023},"https:\u002F\u002Fasiakasjapotilasturvallisuuskeskus.fi\u002Fammattilaisille-ja-opiskelijoille\u002Fhankkeet-2\u002Fhaitta-ja-vaaratapahtumien-ilmoitusmenettelyjen-alykas-uudistaminen\u002F",[219],"Project page · ILMO, Finnish Centre for Client and Patient Safety",[212,1026,1027],{},[215,1028,234],{"href":232,"rel":1029},[219],[205,1031,1032],{"title":237},[209,1033,1034,1039],{},[212,1035,1036],{},[215,1037,1038],{"href":265},"Intelligent Incident Reporting (the proof-of-concept this grew from)",[212,1040,1041],{},[215,1042,1043],{"href":250},"Surgical Complication AI (the pilot scoped during it)",{"title":253,"searchDepth":254,"depth":254,"links":1045},[],"Finnish Centre for Client and Patient Safety","Current-state map, future-state architecture, national master plan, AI vision","As one of two full-time people on Finland's national patient-safety reform, I mapped a dozen disconnected registers and designed the record-once future model.","Patient Safety Reform","ReformFieldHero",{},"Strategic & systems designer",{"title":857,"description":1048},"work\u002Fpatient-safety-reform",[1056,271,1057,1058],"Strategic Design","Systems Design","Public Sector","2 full-time, wide stakeholder network","As one of only two full-time people on Finland's national patient-safety reform, I mapped the entire fragmented current state, interviewing much of Finnish public healthcare and every patient-record vendor. I designed the future-state model, record an incident once and let it flow, and validated it over many rounds with the national data holders and the authorities who consume the data, while who should ultimately hold it was still unsettled. The deliverable was a national master plan and the architecture options beneath a five-to-ten-year reform. The reform itself is a decade of work, not a shipped system, and I don't claim otherwise.\n","nLke_dqbs78oEccJ-2geTiFDSO1fty_GCJikulY4Npc",{"id":1063,"title":1064,"body":1065,"client":1166,"deliverables":1167,"description":1168,"displayTitle":1169,"extension":43,"featured":260,"hero":1170,"heroAlign":262,"heroAspect":41,"heroComponent":263,"meta":1171,"navigation":260,"path":1172,"role":1173,"seo":1174,"stem":1175,"tags":1176,"team":274,"timeline":1181,"tldr":1182,"year":510,"__hash__":1183},"work\u002Fwork\u002Fristo-reipas.md","One Design System Across Web and Mobile",{"type":8,"value":1066,"toc":1164},[1067,1083,1091,1099,1109,1128,1156],[11,1068,1069,1074,1077,1080],{"number":13,"title":14},[16,1070,1071],{},[19,1072,1073],{},"Two apps, built fast over several years, with no shared design system underneath them.",[16,1075,1076],{},"Risto Reipas is a small Finnish startup running a two-sided car-transport marketplace, sometimes described internally as \"Wolt for car transport.\" The web app is for the demand side: the companies booking transport, and the dispatchers who coordinate it from a desk. The mobile app is for the supply side: the self-employed drivers out doing the jobs.",[16,1078,1079],{},"It had grown fast, shipping features first, with both apps built by an outsourced engineering team and no designer involved, so there was no design system holding them together. Colours, type, spacing, shadows and corner radii were hardcoded throughout both codebases, in the hundreds, and the web app still ran on a legacy UI stack of Bootstrap and an old Argon theme. Over the years the two products had drifted into looking and behaving like distant relatives rather than one brand.",[16,1081,1082],{},"A technical and design audit done just before this project had catalogued that inconsistency, along with a set of UX and accessibility issues. Accessibility was the most pressing: the EU Accessibility Act deadline had passed, and the forms carried no accessibility support at all, so the gap was a legal one and not only a matter of polish. Netlight brought me in to build the foundation that had never existed, and to do it quickly.",[11,1084,1085,1088],{"number":30,"title":31},[16,1086,1087],{},"The work was solo and full-stack, from the design decisions down to the code that carries them, across both the web and mobile codebases. Moving between design and implementation, rather than handing work off between them, is where I'm most useful.",[16,1089,1090],{},"I leaned heavily on Claude Code to get a job this broad done in four weeks. The one rule I kept was not to trust its output on faith: nothing it produced was final until I had checked it against the real code and the audit.",[11,1092,1093,1096],{"number":51,"title":52},[16,1094,1095],{},"Going through both codebases confirmed what the audit had found. Dozens of slightly different shadows. Several typefaces and weights, used inconsistently. Spacing and corner radii picked case by case. Colours hardcoded in the hundreds. On the web side, the legacy theme layered its own defaults on top of all of it.",[16,1097,1098],{},"None of this was careless work. It was the result of there never having been a design layer to build on. With no shared system to draw from, each screen had defined its own values, and across years and two codebases that became two apps that no longer agreed with each other.",[11,1100,1101,1106],{"number":73,"title":74},[16,1102,1103],{},[19,1104,1105],{},"The quick win was to make the apps look consistent. The fix that would last was to give them a shared foundation, so they'd stay that way on their own.",[16,1107,1108],{},"Restyling each app by hand would have helped for a while and then drifted back, because nothing underneath would have changed. What was missing was a single source of truth: one set of design tokens, for colour, type, spacing, shadow and radius, that both apps draw from directly. With that in place, staying consistent stops being something to police screen by screen and becomes the default. Building that foundation, rather than repainting the surface, was the real job.",[11,1110,1111,1114,1118,1121,1125],{"number":85,"title":149},[16,1112,1113],{},"I built the system as a set of design tokens that both codebases use, so each value is defined once and applied everywhere. A Figma library is generated from those same tokens, which keeps the design source and the code in step, and a set of lint rules flags any hardcoded value and points to the token that should replace it, so the system can't quietly drift apart again.",[39,1115],{"caption":1116,"size":69,"src":1117},"From sprawl to system: the colours as they were, scattered across overlapping groups, beside the single structured palette that replaced them.","\u002Fimg\u002Fwork\u002Fristo-reipas\u002Fcolors.png",[16,1119,1120],{},"The brand colours stayed as they were; what I changed was the structure beneath them. I reduced a sprawl of overlapping colours and text styles to a small, deliberate set, separated the brand colours from the functional ones the interface uses day to day, and put both apps on a single shared type scale.",[39,1122],{"caption":1123,"size":69,"src":1124},"The rest of the system: one type scale, spacing, corner radii and shadows, and the core components built from them.","\u002Fimg\u002Fwork\u002Fristo-reipas\u002Ffoundations-components.png",[16,1126,1127],{},"Since I was already inside both codebases, I worked through the UX fixes the audit had raised. The biggest was on web: the form for setting up a new transport job, which had been spread across several screens, collapsed into a single view that's much quicker to complete. I reworked the web login screen, redid the type hierarchy and most of the main screens on mobile so they're clearer and easier to read, and fixed a scatter of smaller things, including modal dialogs whose confirm and cancel buttons had been the wrong way round. The legacy web app came onto the new tokens at the same time, so it could share the foundation without a full rebuild.",[11,1129,1130,1136,1142,1148,1152],{"number":148,"title":171},[173,1131,1133],{"title":1132},"From a sprawl to one system",[16,1134,1135],{},"The colour palette came down from roughly 160 tokens to 70, and the text styles from 18 to six, now defined once and shared by both apps instead of redrawn in each.",[173,1137,1139],{"title":1138},"Accessibility built into the foundation",[16,1140,1141],{},"The colours were redone to meet WCAG 2.1 AA, and every pairing is checked against it, so the standard the apps had been missing is built into the foundation rather than retrofitted later.",[173,1143,1145],{"title":1144},"Handed over to carry forward",[16,1146,1147],{},"I built it to be handed over, and kept the in-house owner who'll run it involved throughout, so picking it up is a continuation rather than a fresh start. The web app goes out to a small group of users for testing next, with a wider rollout to follow.",[39,1149],{"caption":1150,"size":69,"src":1151},"The web app before and after: login, dashboard and the transport list, brought onto the new design system.","\u002Fimg\u002Fwork\u002Fristo-reipas\u002Fweb-before-after.png",[39,1153],{"caption":1154,"size":69,"src":1155},"The mobile driver app before and after, with a reworked type hierarchy and clearer screens.","\u002Fimg\u002Fwork\u002Fristo-reipas\u002Fmobile-before-after.png",[11,1157,1158,1161],{"number":170,"title":194},[16,1159,1160],{},"I'll be honest that the project kept changing shape. The scope grew and shrank as I learned what the two codebases actually needed, and the plan I finished with wasn't the one I started with. For a few weeks of work sitting on top of years of accumulated inconsistency, that was probably unavoidable.",[16,1162,1163],{},"For all the speed the AI added, the design judgment was the part that mattered: deciding what the small, deliberate set of values should be, and recognising that a real foundation, built once and shared, was what these apps had been missing all along.",{"title":253,"searchDepth":254,"depth":254,"links":1165},[],"Risto Reipas","Design tokens, Figma library, lint enforcement, UX fixes, handover docs","How I built a unified, token-based design system across Risto Reipas's web and mobile apps with Claude Code, after years of fast feature work had left no shared design foundation.","Design System","\u002Fimg\u002Fwork\u002Fristo-reipas\u002Fhero.png",{},"\u002Fwork\u002Fristo-reipas","Designer & developer",{"title":1064,"description":1168},"work\u002Fristo-reipas",[1177,1178,1179,1180],"Design Systems","Design Tokens","Front-End","AI Workflow","4 weeks, May–Jun 2026","Over four weeks, working solo, I used Claude Code to build a unified, token-based design system for Risto Reipas, whose web and mobile apps had grown for years with no shared design foundation: hundreds of hardcoded values, mismatched fonts, and dozens of one-off shadows and spacings. I also worked through a round of UX fixes that an earlier audit had flagged on both apps. The result is one consistent, accessible foundation that both codebases draw from, handed to an in-house owner to carry forward.\n","cTPj_39IrUlAiC4f5PLKO2jxxtTEYe3gJ_tnJNuMwZA",{"id":1185,"title":1186,"body":1187,"client":256,"deliverables":1363,"description":1364,"displayTitle":1365,"extension":43,"featured":260,"hero":263,"heroAlign":262,"heroAspect":41,"heroComponent":1366,"meta":1367,"navigation":260,"path":250,"role":1368,"seo":1369,"stem":1370,"tags":1371,"team":1374,"timeline":263,"tldr":1375,"year":277,"__hash__":1376},"work\u002Fwork\u002Fsurgical-complication-ai.md","Grading Surgical Complications with an LLM",{"type":8,"value":1188,"toc":1361},[1189,1202,1213,1228,1238,1294,1302,1322,1336,1347],[11,1190,1191,1196,1199],{"number":13,"title":14},[16,1192,1193],{},[19,1194,1195],{},"Some surgical complications can't be prevented, only learned from. But here the data that learning needs lived as free text nobody could analyse.",[16,1197,1198],{},"A large share of patient harm involves surgery, and some of those complications are preventable. To prevent the next one you have to be able to see patterns, which means the data has to be structured and comparable. The Clavien-Dindo classification is the international standard for grading how severe a surgical complication is, from grade I (a minor deviation) up to grade V (death). But in Finland it isn't applied systematically or structurally. At this county, surgeons did grade complications with Clavien-Dindo in gastrointestinal surgery, but they recorded the grade as free text inside the patient notes.",[16,1200,1201],{},"Free text is almost useless for learning. You can't aggregate it, you can't trend it, and because the complication data sitting in the county's data lake came without patient identifiers, you couldn't even follow a graded complication back to the patient or the operation it came from. All of the management and patient-safety value was locked behind a missing structure. The pilot, run by Varha with the Finnish Centre for Client and Patient Safety and funded by Sitra, set out to unlock it, with AI tested as support for the recording rather than a replacement for the clinician.",[11,1203,1204,1207,1210],{"number":30,"title":31},[16,1205,1206],{},"I worked on this pilot embedded with Varha's surgical and IT teams. The reason I was brought in was specific: I'd already built LLM pipelines on real patient data inside their environment, and nobody else had. I came in to set the foundations.",[16,1208,1209],{},"That meant a few distinct things. I was responsible for the initial planning, including the bid for the Sitra grant the pilot ran on. I planned the technical approach with the surgeons: what data a complication grade actually depends on, and how a model could propose one without adding work to a surgeon's day. And I built the initial pipeline that does it. Around me, Varha was the lead implementer for the clinical content and the system connections, the Finnish Centre was the expert partner and the route to national scale, and an IT vendor handled the structured-recording side.",[16,1211,1212],{},"It's a design, code, and AI role more than a service-design one: the same person led the planning, defined the clinical data, and built the pipeline. I owned the foundational phase and then moved on, and the pilot has kept running since.",[11,1214,1215,1218,1221,1225],{"number":51,"title":52},[16,1216,1217],{},"The core insight came quickly and shaped everything: the information needed to grade a complication already exists in the records. It's just scattered across many systems and written as prose, so it's neither analysable nor linkable. The bottleneck is structure and consistency, not missing data.",[16,1219,1220],{},"So with the surgeons I defined the inputs a grade actually depends on: the patient notes, medication, endoscopies, re-operations, anaesthesias, dialyses, imaging, stoma procedures, lab results, and the fact and timing of death. The pipeline assembles those into a single 90-day post-operative timeline per patient.",[1222,1223],"complication-pipeline",{"caption":1224},"How it works. The pipeline pulls the data a grade actually depends on, assembles a 90-day post-operative timeline for the patient, and prompts a locally hosted model for the Clavien-Dindo grade plus a one-to-two sentence justification. The surgeon confirms or overrides; the result is validated against the grade the clinician had already recorded.",[16,1226,1227],{},"One subtlety was worth getting right: the timeline's anchor. The obvious choice is the operation plus 90 days, but clinicians sometimes record the grade before that window has closed, which means the natural timeline wouldn't contain what they actually saw. So the pipeline also assembles a second timeline anchored on the moment the clinician recorded the grade, to make sure the model is reasoning from the same evidence the clinician had. The grade the surgeon had already written becomes the ground truth I validate against.",[11,1229,1230,1235],{"number":73,"title":74},[16,1231,1232],{},[19,1233,1234],{},"Asking whether a model can guess the grade skips what actually mattered: complication data that nobody can analyse, compare, or even link to a patient. The point was to make it structured and reusable without adding a minute to a surgeon's day.",[16,1236,1237],{},"That framing changes the design. The moment recording feels like extra, disconnected admin, it stops happening, no matter how clever the model is. So the model couldn't be a separate tool that produces a verdict; it had to be a suggestion that slots into the existing flow, proposing a grade the surgeon confirms or corrects in a moment. And because the whole reason to do this is national learning, it had to be scalable by design, built on a shared data model and standard classifications rather than a one-county workaround.",[11,1239,1240,1258,1276],{"number":85,"title":86},[88,1241,1243,1248,1253],{"title":1242},"The model proposes; the clinician decides",[16,1244,1245,1247],{},[94,1246,96],{}," an autonomous classifier that writes the grade into the record on its own. Tidy on a slide, untrustworthy in a clinic.",[16,1249,1250,1252],{},[94,1251,102],{}," the model proposes the most likely Clavien-Dindo grade with a short justification, and the surgeon confirms or overrides it. The human stays in the loop by design.",[16,1254,1255,1257],{},[94,1256,108],{}," it doesn't remove the human step, but that's the point. Clinical accountability stays with the clinician, the suggestion is something a busy surgeon will actually accept, and the accept-or-override action gives a real signal (an acceptance rate) to measure later.",[88,1259,1261,1266,1271],{"title":1260},"Open models, run inside the hospital walls",[16,1262,1263,1265],{},[94,1264,96],{}," a commercial cloud API, by far the easiest thing to call.",[16,1267,1268,1270],{},[94,1269,102],{}," open-weight models (gpt-oss-20 and gpt-oss-120) running inside the county's own secure data-services environment, because real patient records cannot leave it.",[16,1272,1273,1275],{},[94,1274,108],{}," considerably more to stand up and operate than an API key, but it's the only architecture that is both lawful and trustworthy for this data. The privacy constraint wasn't a footnote; it set the whole shape of the build.",[88,1277,1279,1284,1289],{"title":1278},"Validate against the grade clinicians already assigned",[16,1280,1281,1283],{},[94,1282,96],{}," scoring the model against a clean synthetic benchmark.",[16,1285,1286,1288],{},[94,1287,102],{}," compare the model's grade to the Clavien-Dindo grade the surgeons had recorded by hand, on real gastrointestinal-surgery data.",[16,1290,1291,1293],{},[94,1292,108],{}," that ground truth is only as consistent as the free-text recording it came from, which is the very weakness the project exists to fix. I treated it as a known limit to be honest about, not a clean accuracy number to wave around.",[11,1295,1296,1299],{"number":148,"title":149},[16,1297,1298],{},"What I built and tested was the pipeline above: pull the defined data for a patient, assemble the two 90-day post-operative timelines, prompt the locally hosted models for the Clavien-Dindo grade and a one-to-two sentence justification, and compare the answer to the clinician's recorded grade.",[16,1300,1301],{},"Around it, the pilot aimed to produce an operating model for structured Clavien-Dindo recording that could live inside the patient-information system; the AI solution proposing the grade as recording support; a management dashboard aggregating the structured complication data for leadership and root-cause work; and an effectiveness evaluation. The structural payoff is the part that matters: with the grade captured as data rather than prose, serious complications (grades III to V) can for the first time be linked with patient identifiers and followed back to a pathway, instead of sitting as anonymous free text. It was designed from the start to scale, with the Finnish Centre as the route to other counties and other adverse-event types.",[11,1303,1304,1310,1316],{"number":170,"title":171},[173,1305,1307],{"title":1306},"I set the foundations the pilot ran on",[16,1308,1309],{},"I owned the early planning, including the bid for the Sitra grant, then built the technical foundations: the data the model depends on, the approach for proposing a grade, and the initial working pipeline. The pilot existed to run because that groundwork was in place.",[173,1311,1313],{"title":1312},"A working pipeline on real data",[16,1314,1315],{},"I built and tested the pipeline on real gastrointestinal-surgery records: assemble the post-operative timeline, prompt the locally hosted model for a Clavien-Dindo grade and a short justification, and check it against the grade the surgeon had recorded. It showed the approach was feasible, carrying that earlier work forward onto a live clinical problem.",[173,1317,1319],{"title":1318},"Still running, so the numbers aren't mine to claim",[16,1320,1321],{},"I owned the early, foundational phase and then handed it on; the pilot has continued through to 2026, beyond my involvement. So there's no measured accuracy or adoption figure for me to put here, and I won't invent one. What is honestly mine is the planning, the foundations, and a pipeline that worked.",[11,1323,1324,1327,1330,1333],{"number":193,"title":194},[16,1325,1326],{},"The real risk was never the model's accuracy. It was whether surgeons would adopt the recording at all. A grading tool that sits to one side of the workflow, however accurate, is a tool nobody opens. That is why the whole thing is built as a suggestion that drops into the existing flow, and why I spent as much time with the surgeons on where the grade lands as on how the model produces it.",[16,1328,1329],{},"The limitation I would name first is the ground truth. I validated against the grades clinicians had already written, which means my reference inherits exactly the inconsistency the project set out to fix. A cleaner evaluation would need a curated, adjudicated reference set, which is a project in itself, and an honest next step rather than something to paper over.",[16,1331,1332],{},"What shaped the build most was the privacy constraint. \"Patient data never leaves the building\" isn't a compliance line at the end; it's the reason the models are open-weight and self-hosted, and that single decision rippled through the entire architecture.",[16,1334,1335],{},"The distilled version: in clinical AI, the goal is a good suggestion, not a verdict. The model earns its place by making the right record the easy one to keep, and by being humble enough to be overruled.",[205,1337,1338],{"title":207},[209,1339,1340],{},[212,1341,1342],{},[215,1343,1346],{"href":1344,"rel":1345},"https:\u002F\u002Farkisto.sitra.fi\u002Fhankkeet\u002Fennakoiva-sote\u002F#rahoitus-on-myonnetty-neljalle-hankkeelle",[219],"Project funding · Sitra, Ennakoiva sote",[205,1348,1349],{"title":237},[209,1350,1351,1356],{},[212,1352,1353],{},[215,1354,1355],{"href":265},"Intelligent Incident Reporting (the proof-of-concept this built on)",[212,1357,1358],{},[215,1359,1360],{"href":244},"Patient Safety Reform (the national reform it was scoped within)",{"title":253,"searchDepth":254,"depth":254,"links":1362},[],"LLM grading pipeline, post-op data model, grade validation","I led the foundational phase of a Sitra-funded pilot: an LLM pipeline that proposes a surgical complication's Clavien-Dindo grade for the surgeon to confirm.","Surgical Complication AI","ClavienScaleHero",{},"Designer & technical lead",{"title":1186,"description":1364},"work\u002Fsurgical-complication-ai",[1372,271,273,1373],"AI Product","Clinical","Pilot across a county and the national centre","Because thesis work I'd done had already put LLM pipelines inside Varha's secure environment, and nobody else had, I was brought in to lead the foundational phase of a Sitra-funded pilot. Surgeons there already graded complications by the international Clavien-Dindo scale, but recorded the grade as free text, so it couldn't be analysed, compared, or even linked back to the patient. I led the early planning, shaped the technical approach with the surgeons, and built the initial pipeline: it assembles a patient's post-operative history and proposes the Clavien-Dindo grade, with a short justification, for the surgeon to confirm, all inside the hospital's secure environment. I set the foundations and then handed it on; the pilot is still running through 2026, so the measured results are honestly not mine to claim.\n","_SJrbt5xA7sZ71YRbepSE-OKFRUR9XtJuUPMk21pg8w",{"id":1378,"archive":1379,"cv":1404,"extension":1429,"home":1430,"meta":1436,"socials":1437,"stem":1441,"work":1442,"__hash__":1456},"site\u002Fsite.yml",{"description":1380,"meta":1381,"order":1382},"A selection of my creations, designed and built with love by me.","Things made by hand: furniture, instruments, garments, lighting and sculpture.",[1383,1384,1385,1386,1387,1388,1389,1390,1391,1392,1393,1394,1395,1396,1397,1398,1399,1400,1401,1402,1403],"counterbalance-wall-lamp","entry-organizer","wool-pants","cap","guitar-n3","oak-shelf","books","handles","steel-table","guitar-strap","plate-reverb","racekit","cantilever-bike-rack","potence-wall-lamp","pendant-light","eurorack","pedals","linen-shirt","bike-rack","safety-pins","cassette",[1405,1410,1415,1420,1425],{"period":1406,"role":1407,"company":1408,"description":1409},"2026–present","Design Consultant","Netlight","Multidisciplinary design across product, systems and AI, often as close to front-end and AI engineering as to design itself.\n",{"period":1411,"role":1412,"company":1413,"description":1414},"2023–present","Co-founder · design, brand & tech","Juoksut Run Club","Co-founded one of Finland's largest running communities; designed the brand and built its full-stack web app and shop from scratch.\n",{"period":1416,"role":1417,"company":1418,"description":1419},2025,"Planning Officer","Finnish Centre for Client & Patient Safety","Designed Finland's future national patient-safety incident reporting: a 5–10 year roadmap and LLM pilots, aligning ministries, authorities and vendors.\n",{"period":1421,"role":1422,"company":1423,"description":1424},2024,"Researcher","Varha, Southwest Finland","Master's thesis plus a GPT-4 proof-of-concept turning free-text patient records into structured safety reports.\n",{"period":1426,"role":1427,"company":609,"description":1428},2023,"Design Research Trainee","Explored the human side of early 6G through interviews and design-thinking workshops with engineering teams.\n","yml",{"wordmark":1431,"aboutShort":1432,"aboutLong":1433,"email":1434,"location":1435},"jusa annevirta","Designer and nerd by trade; runner and maker by nature.","I'm a full-stack designer working across design, AI and digital systems. I like turning ambiguity into clarity, and I'm comfortable anywhere from early strategy to building the thing itself. Outside work you'll find me outdoors, chasing marathons and beyond. When not running I'm making things with my hands: guitars, furniture, garments, or whatever sparks my creativity.\n","jusa.annevirta@netlight.com","Helsinki, Finland",{},{"linkedin":1438,"github":1439,"instagram":1440},"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fannevirtajusa","https:\u002F\u002Fgithub.com\u002Fjusa-a","https:\u002F\u002Fwww.instagram.com\u002Fjusa.a","site",{"roleLines":1443,"description":1446,"meta":1447,"order":1448},[1444,1445],"Full-stack designer,","strategy, AI","Selected case studies across healthcare, telecom, finance, IoT and mobility.","Selected case studies in design, strategy and AI, across healthcare, IoT, telecom, finance and mobility.",[1449,1450,1451,1452,1453,1454,1455],"risto-reipas","iot-product-discovery","intelligent-incident-reporting","patient-safety-reform","surgical-complication-ai","nokia-6g","nordea-green-banking","wxLJYf7BM2zUYN8z-fKh2WB0Mj_5tkP4vb5yG7wWedw",1780999143297]