E N A B L I N G E F F I C I E N T H E A L T H C A R E Cynefin Framework by Dave Snowden. Sketch by Edwin Stoop

E N A B L I N G E F F I C I E N T H E A L T H C A R E Strategies to Learn Complex Domains Mufrid Krilic, Senior Software Developer/Coach DIPS AS, Norway Experiences from Developing Enterprise Software for Healthcare

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Ignited curiosity about Domain Driven Design and Event Storming ▪ Lessons learned when dealing with complexity in healthcare Takeaways

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Definition of Complexity – “the state of having many parts and being difficult to understand or find an answer to” • Cambridge Dictionary ▪ How to recognize complexity in a domain? – Complexity on strategic level – Complexity on tactical level About complex domains

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Many-to-many relationships between domain terms ▪ Matrix-like relationships – Use case: Admission Letters sent from Hospital Complexity on Tactical Level

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Letter template depending on required treatment – Level of Care • Outpatient or hospitalization? – What department? – What is the health issue? • Related to the field of discipline within each department – Each discipline is related to a set of coded diagnoses that patient’s health issue fall within • Is patient entitled to health care provided by the state? ▪ In total 5 parameters Complexity in Healthcare - Admission Letters

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Letter template depending on a stage in admittance process – Referral Reception Letter • When hospital initially receives referral from patient’s GP – Referral Evaluation Result Letter • When hospital decides to either refer patient to another hospital or decline health care for a valid reason – Appointment Notice Letter • When hospital schedules patient for a visit – Without fixed appointment time – With tentative time – With fixed appointment time ▪ In total 6 parameters Complexity in Healthcare - Admission Letters

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ The matrix of parameters respectively related to required treatment and stage of admission process yields the letter template ▪ Precedence between parameters on the left-hand side ▪ Orthogonal complexity – Letter to next of kin, GP. Printed letter or electronic message. Cross- department letter templates. Complexity Revealed Referral received Referral rejected Referred to another hospital Appointment w/o fixed time Appointment w/ tentative time Appointment w/ fixed time Level of care Department Discipline Diagnosis Healthcare entitlement

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ The complexity matrix should be explicitly modeled in code – Preferably not mixed with technological concerns • UI framework • Persistency technology ▪ Why? – Reducing accidental complexity introduced by technology choices – Expose inherent complexity in business rules • Rules described in previous slides are there regardless of technology Complexity Exposed

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Use Case: Referral Flow in Norwegian Hospitals – Basic flow • GP creates referral on behalf of patient and sends it to a relevant hospital • Pre-sorting of received referrals followed by referral reception in each department • Referral made ready for evaluation by a supervising physician • Referral is evaluated by a physician – Accepted i.e. patient is entitled for public healthcare in a hospital – Or rejected on some formal or clinical basis • Patient is scheduled for admittance – Significant alternative flows • Patient is referred to another department for supplementary treatment • Patient is referred to another hospital for more specialized or extensive treatment – The flow involves multiple roles and takes time to complete Complexity on Strategic Level

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ The complexity in the overall business process should be visible early in the project – Without time-consuming studies and extensive documentation ▪ Why? – Can we reduce complexity on the strategic level by aligning teams with inherent subdomains in the problem space? • to enable teams to be efficient in dealing with complexity on tactical level – Establishing common language between developers and the business – Investing heavily in learning early on • A.K.A. «Knowledge Crunching» Complexity Exposed

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ What is DDD? – My personal definition or why I value DDD: • DDD is an approach for dealing with complex problems with emphasis on learning the domain in a close collaboration with domain experts in order to focus on the most important problems to solve. ▪ The term coined by Eric Evans in 2004 – The “Blue Book” • Tackling Complexity in the Heart of Software About Domain Driven Design (DDD)

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Ubiquitous Language – Develop domain model based on domain terms ▪ Bounded Context – tackle complexity by splitting application via inherent subdomain boundaries – The boundaries are primarily linguistic per the Ubiquitous Language • If a domain term has different meaning in different use-cases it is an indication of separate bounded contexts – Example: Patient » Patient as a subject of care » Patient as a customer paying the bill after visiting the clinic – Bounded Contexts are defined by the semantics of the Ubiquitous Language! The Two Pillars of DDD

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Knowledge Crunching technique – The term introduced by Eric Evans in the Blue Book ▪ Event Storming – Introduced to community by Alberto Brandolini in 2013 – Discovery and collaboration with domain experts put in practice • People with questions meet people with answers – Massive learning and sharing of different perspectives – Making the most important problems visible – Unlimited modelling space ▪ Multiple levels – Big picture, process modelling or software design About Event Storming

E N A B L I N G E F F I C I E N T H E A L T H C A R E – Use Case: Referral flow in Norwegian hospitals Big Picture Event Storming

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Domain Event – Orange sticky note – Verb at past tense – Relevant for domain experts Big Picture Event Storming Referral received from patient’s GP Referral for evaluation sent to attending physician Referral accepted Medical consultant Attending physician How is attending physician notified when GP sends a reminder on non- evaluated referral? Will GP send another referral (duplicate) if GP wants to remind hospital about non- evaluated referral? ▪ User/Actor/Persona – Yellow sticky note ▪ Hot Spots – Pink sticky note – This is where interesting discovery happens

E N A B L I N G E F F I C I E N T H E A L T H C A R E Complexity Revealed: Referral From GP to Hospital

E N A B L I N G E F F I C I E N T H E A L T H C A R E Complexity Revealed: Referral Evaluation in Hospital

E N A B L I N G E F F I C I E N T H E A L T H C A R E Complexity Revealed: In-Hospital and Inter-Hospital Referral

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Strong hints about Bounded Contexts – Suddenly visible when taking time into account! • One-way communication and work hand-off between roles and tasks – Identifying different roles in the business process • Medical consultant makes sure received referral is ready for evaluation • Attending physician evaluates the referral • Planning consultant schedules patience for admittance – Same role with different tasks at different points in time • Attending physician evaluates received referral • Patient is admitted but the treatment requires services from another hospital • Attending physician refers patient to another hospital by creating new referral ▪ Bounded Contexts emerged only in aftermath Lessons Learned - Big Picture Event Storming

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Assert perceived Bounded Contexts against the Ubiquitous Language – Referral with different meaning in different stages of the business process • Referral as in received referral • Referral as in evaluated referral • Referral as in referral to another department or hospital ▪ Perceived Bounded Contexts should be challenged throughout the development process – Learning is an iterative process, after all….. Lessons Learned – Bounded Contexts Assertions

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Respect, embrace and expose inherent complexity in the domain ▪ Reveal complexity by applying Knowledge Crunching methods – Event Storming, Domain Storytelling – Get an overview of the business process in a quick and efficient way ▪ Assess inherent subdomains and establish Bounded Contexts – Input for modularization in the application ▪ For multiple teams project align teams with subdomains and Bounded Contexts ▪ Apply appropriate technology on each problem within a Bounded Context Lessons Learned while Applying DDD

E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Eric Evans – «Tackling Complexity in the Heart of Software» • «The Blue Book» ▪ Vaughn Vernon – «Implementing Domain Driven Design» • «The Red Book» – «Domain Driven Design Distilled» • «The Green Book» ▪ Alberto Brandolini – «Introducing EventStorming – an Act of Deliberate Collective Learning» • Book on LeanPub Further Reading