Emne 4.1 — Platforme og fælles tjenester

I sundhed og pleje er en fælles platform ikke en besparende bekvemmelighed, men en måde at gøre sikkerhed, lighed og tillid gentagelige — så hvert team arver dem i stedet for at genopfinde dem, ofte dårligt.

Hvorfor det er vigtigt i sundhed og pleje#

Når du driver digital leverance på tværs af et sundheds- og plejesystem, bemærker du hurtigt, at de samme kapabiliteter genopbygges igen og igen. Hver tjeneste vil autentificere en patient, slå en demografisk journal op, sende en notifikation, registrere et revisionsspor eller tjekke en klinikers rolle. Overladt til sig selv bygger hvert team sin egen version. Man ender med et dusin login-skærme, et dusin måder at håndtere en patients identitet på, et dusin revisionslogs af svingende kvalitet — og et dusin steder, hvor en sikkerhedsfejl kan gemme sig.

Denne duplikering er dyr, men det dybere problem er, at den er farlig og uretfærdig. I sundhed og pleje bærer infrastrukturen klinisk risiko. Hvis ét teams patientmatchlogik er svagere end et andets, kan en patient få den forkerte journal. Hvis én tjenestes tilgængelighed er ringere, udelukkes nogle mennesker i det stille. Hvis revisionsspor er forskellige, går en informationsstyringsundersøgelse i stå. En fælles platform lader dig bygge en kapabilitet én gang, til høj standard, med klinisk sikkerheds- og tilgængelighedsarbejde gjort ordentligt, og lade mange teams arve den standard frem for at hver især gamble på at få det rigtigt alene.

Platforme former også tempoet i hele systemet. En god platform betyder, at en ny tjeneste kan nå patienter på uger frem for år, fordi de svære, generiske dele allerede findes. En dårlig eller fraværende platform betyder, at hvert team bærer hele infrastrukturens vægt, og levering går i det langsomste, mindst ressourcestærke teams tempo. I en sektor under vedvarende økonomisk og arbejdskraftmæssigt pres, hvor de samme nationale og lokale kapabiliteter er nødvendige for hundredvis af organisationer, er det at få platforme rigtige en af de beslutninger med størst løftestang, I vil træffe. Dette emne handler om at bygge og drive dem godt — som produkter med rigtige brugere, ikke som påbudt infrastruktur, ingen elsker.

Kernebegreber#

En platform er i denne sammenhæng et sæt kapabiliteter, andre teams bygger på frem for selv at bygge. Den mest nyttige moderne rammesætning er, at en platform er et produkt med interne brugere. Dens kunder er jeres egne udviklere, leveranceteams og partnerorganisationer, og dens succes måles, som ethvert produkts: ved adoption, ved oplevelsen hos de mennesker, der bruger den, og ved de udfald, den muliggør.

Flere beslægtede idéer ligger under. Fælles tjenester er det ældre organisatoriske mønster, hvor en kapabilitet leveres én gang til mange dele af en organisation i stedet for at blive duplikeret i hver. Digital offentlig infrastruktur udvider dette til niveauet for et helt samfund — de fælles, genbrugelige, interoperable byggeklodser (identitet, betalinger, dataudveksling), som offentlige og private tjenester bygges på. "Government as a platform", en vending skabt af Tim O’Reilly og taget op af digitale forvaltningsteams verden over, anvender samme logik på staten: myndigheden leverer fælles komponenter, og afdelinger sammensætter tjenester af dem frem for at hver bygger hele stakken.

Teknisk eksponerer platforme ofte deres kapabiliteter gennem en applikationsprogrammeringsgrænseflade (API) — en defineret kontrakt, der lader ét system bruge et andets kapabilitet uden at kende dets indre. De trækker ofte på cloud-modeller for platform som en tjeneste (PaaS), og fælles nationale platforme bygger typisk på multitenancy, hvor én instans betjener mange organisationer, mens deres data og konfiguration holdes adskilt.

Tre begreber afgør, om en platform hjælper eller skader. Det første er kognitiv belastning: en god platform mindsker det, et leveranceteam skal holde i hovedet, så teamet kan koncentrere sig om det kliniske eller plejemæssige problem, det findes for at løse. Det andet er den "asfalterede vej" eller "gyldne sti" — en veludstyret, holdningspræget standardmåde at udføre en almindelig opgave på, der er lettere at følge end at undgå, tilbudt gennem selvbetjening frem for portvogtning. Det tredje er undgåelsen af leverandørlåsning, hvorfor platforme bør bygges på åbne standarder, så organisationer kan skifte mellem leverandører uden uoverkommelige skiftomkostninger.

I sundhed specifikt er nationale fælles tjenester allerede en del af landskabet. Historiske programmer som NHS Connecting for Health etablerede NHS Spine, et sæt nationale tjenester, der bærer kerne-data som Personal Demographics Service. Moderne ækvivalenter omfatter nationale API’er, NHS login til borgerautentificering og NHS Notify til beskeder — kapabiliteter tilbudt, så enkelte tjenester ikke behøver genopbygge dem. Hvor en platform giver en fælles måde at bevise, hvem nogen er, eksponerer den ofte single sign-on, så en kliniker autentificerer én gang frem for gentagne gange. Dette emne handler om, hvordan sådanne platforme bygges og drives; detaljerne om, hvem man er, og hvad man må, hører til emne 4.2 — Identitets- og adgangsstyring, og de standarder, der lader systemer udveksle data, hører til emne 4.3 — Interoperabilitet og datastandarder.

Bedste praksis#

1. Behandl platformen som et produkt, ikke et projekt. En platform har en køreplan, en produktansvarlig, løbende finansiering og brugere, hvis tilfredshed I måler — ikke en slutdato og en overdragelse. Projekter afsluttes og forfalder; platforme må drives på ubestemt tid, fordi teams kommer til at afhænge af dem. Finansiér og bemand i overensstemmelse hermed, og se emne 5.0 — Produktledet arbejde for den driftsdisciplin, det indebærer.

2. Start med den tyndest mulige platform. Byg det mindste sæt fælles kapabiliteter, der reelt aflaster teams, og tilføj mere kun, når reel efterspørgsel og reel smerte berettiger det. Denne "tyndest mulige platform"-idé, introduceret i emne 1.1 — Driftsmodellen, værner mod det mest almindelige svigt: en ambitiøs central platform, der forsøger at gøre alt, kommer for sent og passer til ingen. Lad platformen vokse ud af evidens for brug, ikke arkitektonisk aspiration.

3. Gør den asfalterede vej til den lette vej. En platform optjener adoption ved at gøre den understøttede vej hurtigere og enklere end at bygge sin egen — gennem selvbetjent onboarding, klar dokumentation, sandkasser og fornuftige standarder med klinisk sikkerhed og tilgængelighed indbygget. Hvis det er langsommere eller mere smertefuldt at bruge platformen end at gå udenom, vil teams gå udenom, og I har brugt penge på at skabe en flaskehals. Design til udviklerens første time og deres værste dag.

4. Mål succes på adoption og brugeroplevelse, ikke på eksistens. De rette metrikker er, hvor mange teams der bruger platformen villigt, hvor lang tid onboarding tager, hvor ofte platformen er tilgængelig, og hvordan dens brugere bedømmer oplevelsen. Forfængelighedsmetrikker som antallet af udrullede tjenester fortæller intet om, hvorvidt teams hjælpes. Instrumentér platformen, kør regelmæssig forskning med de teams, der bygger på den, og behandl en faldende eller stagnerende adoptionskurve som et produktproblem at rette, ikke et overholdelsesproblem at håndhæve.

5. Byg på åbne standarder, og hold udgangen billig. Foretræk åbne, bredt tagne standarder og grænseflader, så hverken I eller teams på jeres platform er fanget. Dokumentér, hvordan et team ville forlade den, og sørg for, at de kunne. Paradoksalt er det at gøre det let at forlade det, der gør teams trygge ved at ankomme, og det holder platformen ærlig, fordi den må optjene sin plads frem for at stole på fangenskab. Det mindsker direkte leverandørlåsning i hele landskabet, som drøftet i emne 4.0 — Teknisk arkitektur, cloud og legacy.

6. Vær eksplicit om, hvem der betaler, og hvem der beslutter. En fælles platform har brug for en finansieringsmodel og en styringsmodel aftalt på forhånd: om den er centralt finansieret, viderefaktureret til brugere eller en hybrid, og hvordan dens køreplan prioriteres mellem konkurrerende tenants. Tvetydighed her er det, der gør platforme til politiske slagmarker. Offentliggør modellen, giv brugerne en reel stemme i køreplanen, og gensyn den, efterhånden som platformen vokser.

7. Kør platformsteamet med klare ansvarsområder og grænser. Organisér omkring et dedikeret platformsteam, hvis opgave er at muliggøre strømorienterede leveranceteams gennem selvbetjening, som beskrevet i Team Topologies-mønstrene i emne 7.0 — Teamstrukturer, roller og ansvar. Hold grænsefladen mellem platform og forbrugere eksplicit — hvad platformen lover, hvad den ikke gør, og hvordan man får support — så platformen muliggør frem for at portvogte.

8. Design til multitenancy, isolation og sikkerhed fra starten. Hvis mange organisationer deler én platform, er adskillelse af deres data, konfiguration og fejldomæner et grundlæggende krav, ikke en senere funktion. I sundhed og pleje er det også et informationsstyrings- og klinisk sikkerhedskrav: én tenants hændelse må ikke blotlægge eller bringe en andens patienter i fare. Bag isolation, observerbarhed pr. tenant og et klinisk sikkerhedscase for selve platformen under DCB0129 ind.

Spørgsmål at drøfte med dit team#

1. Hvad er den tyndeste platform, der reelt ville aflaste vores teams, og hvad er vi fristede til at bygge, som vi ikke bør? Det er let at designe en omfattende platform på en tavle og svært at levere en, teams elsker. Start fra den reelle, gentagne smerte, jeres leveranceteams føler i dag — den kapabilitet, tre eller flere teams hver genopbygger — og modstå at tilføje noget, som kun ét team har brug for, eller som ingen endnu har bedt om. Spørg, hvilke kapabiliteter der er reelt fælles versus dem, der blot ligner hinanden på afstand, men adskiller sig i de detaljer, der betyder noget klinisk. Overvej omkostningen ved at tage fejl: en for tidlig fælles kapabilitet, teams må arbejde udenom, er værre end ingen platform. Aftal en eksplicit linje mellem, hvad platformen vil eje nu, og hvad den bevidst udskyder. Gensyn linjen efter en plan og flyt kun emner over, når efterspørgsel og smerte er påvist. Disciplinen er at sige nej til gode idéer, der endnu ikke optjener deres plads.

2. Hvordan finansierer vi platformen og afgør dens køreplan, når tenants er uenige? En platform betjener mange teams med konkurrerende prioriteter, og i det øjeblik to vigtige tenants vil have uforenelige ting, testes jeres styring. Beslut nu, om platformen er centralt finansieret, viderefaktureret eller hybrid, og vær ærlige om de incitamenter, hver model skaber: viderefakturering kan undertrykke adoption, mens central finansiering kan løsrive platformen fra brugerbehov. Beslut, hvem der holder køreplanen, hvordan tenants påvirker den, og hvordan I arbitrerer mellem en stor organisations akutte behov og en lille organisations grundlæggende. Overvej lighed eksplicit, fordi en viderefaktureringsmodel kan prissætte mindre eller fattigere organisationer ud af fælles sikkerhedskapabiliteter. Aftal, hvordan I håndterer en tenant, der vil finansiere en funktion, de andre ikke vil. Skriv modellen ned og offentliggør den, så beslutninger føles som styring frem for favorisering. Forpligt jer derefter til at gensyne den, efterhånden som platformen og dens brugerbase vokser.

3. Hvordan vil vi vide, at platformen er elsket frem for blot påbudt, og hvad vil vi gøre, hvis den ikke er? En platform kan være teknisk sund, officielt påkrævet og i det stille hadet — og en påbudt, men uelsket platform akkumulerer omgåelser, skyggesystemer og harme. Beslut på forhånd, hvilke signaler der fortæller jer sandheden: villig adoption, hvor teams har et valg, tid-til-første-succes for et nyt team, tilgængelighed og hændelseshistorik og direkte feedback fra de udviklere, der bruger den. Tal om, hvordan I indsamler ærlig feedback, når I også har magt over jeres brugere, da folk er tilbageholdende med at kritisere en platform, de er forpligtet til at bruge. Aftal, hvordan en sund adoptionskurve ser ud, og hvilken tærskel der ville udløse en alvorlig genovervejelse. Beslut, om I nogensinde ville være villige til at nedlægge eller erstatte platformen, hvis evidensen krævede det. At være villig til at høre, at jeres platform ikke virker, er det, der holder den i gang. Alternativet er at opdage sandheden først, når en større tjeneste router udenom jer.

4. Hvordan holder vi udgangen billig, og kunne et team på vores platform faktisk forlade den, hvis det var nødvendigt? Det er let at påstå, at I er bygget på åbne standarder, og noget ganske andet at bevise, at et team kunne gå uden en uoverkommelig omskrivning. Tal ærligt om, hvor lock-in sniger sig ind — en proprietær grænseflade, et udokumenteret dataformat, en national afhængighed uden alternativ — og om omkostningen ved at forlade stiger stille over tid. Beslut, hvem der er ansvarlig for at dokumentere og periodisk teste en udgangsvej, frem for at antage at en findes. Overvej, at lock-in-risikoen i sundhed og pleje forstærkes: en national platform bygget på fangenskab kan fange et helt system i en generation, og de teams, der er mindst i stand til at absorbere skiftomkostninger, er som regel de mindste udbydere. Et ærligt svar nævner de specifikke afhængigheder, I ville have svært ved at afvikle, beskriver en konkret udgang for mindst én reel tenant og behandler portabilitet som en funktion, I vedligeholder, frem for et slogan, I gentager. Husk, at det at gøre det let at forlade ofte er det, der gør teams trygge ved at ankomme.

5. Bærer platformen sit eget kliniske sikkerhedscase, og hvordan forhindrer vi, at én tenants svigt skader en andens patienter? Når mange organisationer deler én platform, bærer dens infrastruktur klinisk risiko på vegne af hver tjeneste bygget på den, så en fejl i patientmatching eller en lækage mellem tenants er ikke ét teams problem, men alles. Beslut, om platformen har sit eget DCB0129-sikkerhedscase, forbrugende teams reelt kan stole på, eller om hver tjeneste i det stille revurderer den samme fælles risiko. Drøft, hvordan I isolerer tenants’ data, konfiguration og fejldomæner, og hvordan I ville vide, om den isolation blev brudt — observerbarhed pr. tenant er forskellen mellem at inddæmme en hændelse og at opdage den sent. Overvej også informationsstyringskonsekvenserne: en undersøgelse af én tenant må ikke kræve at blotlægge en andens journaler. Et ærligt svar kan pege på et vedligeholdt sikkerhedscase, en afprøvet isolationsgrænse og en klar redegørelse for, hvad platformen lover om sikkerhed versus hvad der forbliver hver tjenestes ansvar. At behandle sikkerhed og isolation som grundlæggende, ikke senere funktioner, er det, der lader teams arve assurance frem for at gamble.

6. Hvor går linjen mellem platformsteamet og de teams, det betjener, og hvordan forhindrer vi, at platformen bliver en flaskehals? En fælles platform kan accelerere hvert team eller bremse alle til hastigheden af én central kø, og forskellen ligger i, hvor skarpt I har trukket grænsefladen mellem platform og forbrugere. Beslut, hvad platformen ejer og lover, hvad den eksplicit ikke gør, og hvordan et team får support uden at vente på en ticket til rutinearbejde. Tal om selvbetjening som standard: hvis onboarding, provisionering eller en almindelig ændring alle kræver, at platformsteamet handler i hånden, har I bygget en port frem for en asfalteret vej. Overvej kognitiv-belastnings-handlen i hjertet af en god platform — den bør mindske det, et leveranceteam skal holde i hovedet, så de kan koncentrere sig om det kliniske problem, ikke tilføje endnu et lag at forhandle med. Et ærligt svar nævner de opgaver, der stadig tragter gennem platformsteamet som en flaskehals, sætter en retning for at gøre dem selvbetjente og er åbent om, hvor platformen muliggør versus hvor den portvogter.

I praksis: et eksempel fra sundhed og pleje#

Et integreret plejesystem (ICS), der dækker flere NHS-hospitaler, kommunale udbydere og en kommunes voksensocialpleje, støder gentagne gange ind i den samme mur. Hver ny digital tjeneste — en virtuel afdeling, en selvhenvisningsformular til kommunal fysioterapi, et tilsynsværktøj til plejehjem — bruger de første tre måneder på at genopbygge de samme fundamenter: at bevise, hvem patienten er, tjekke fagpersonens rolle, sende sms-påmindelser og skrive et revisionsspor. Den virtuelle afdelings patientmatching viser sig at være svagere end fysioterapiteamets, og en næsten-hændelse opstår, da en påmindelse sendes til den forkerte person. ICS’ets digitale ledelse genkender mønstret: de betaler mange gange for kapabiliteter, der burde findes én gang, og variationen er en sikkerhedsrisiko.

I stedet for at bestille en stor ICS-platform starter de tyndt. De opretter en enkelt fælles tjeneste, der gør én ting godt: den ombryder NHS login og den nationale Personal Demographics Service bag en ren, dokumenteret API med en sandkasse, så ethvert team kan verificere en borgers identitet og hente en bekræftet demografisk journal gennem én understøttet vej. Et lille platformsteam på fem behandler den som et produkt. De offentliggør en guide til den asfalterede vej, tilbyder selvbetjent onboarding og sætter et mål om, at et nyt team bør foretage sit første vellykkede kald inden for en dag. Afgørende påbyder de den ikke. De gør den til den letteste mulighed og lader den virtuelle afdelings team være den første villige adopter.

Finansieringsmodellen aftales åbent: ICS’et finansierer centralt platformens kerne de første to år, så adoption ikke undertrykkes af viderefakturering, med en gennemgang efter atten måneder. En gruppe på tværs af udbydere, herunder kommunen, holder køreplanen og mødes månedligt. Da fysioterapiteamet beder om en notifikationskapabilitet næste gang, tilføjer platformsteamet en tynd ombrydning omkring NHS Notify i stedet for at bygge beskeder fra bunden — byg én gang, brug mange gange. Inden for et år har seks teams villigt taget identitetstjenesten i brug, onboarding er faldet fra måneder til dage, og platformsteamet offentliggør åbent sine tal for tilgængelighed og adoption. Da ét hospitals skræddersyede system router udenom platformen, behandler teamet det som forskning frem for trods, lærer den friktion, der drev beslutningen, og retter den. Platformen vokser, fordi teams vælger den, og ICS’et arver en enkelt, veltestet, tilgængelig måde at gøre de risikable, almindelige ting på.

Sektorperspektiver#

Startup#

En sundhedsteknologisk startup bygger sjældent platforme til andre; den bygger på dem. Jeres løftestang kommer af at forbruge nationale og cloudplatforme — NHS login, nationale API’er, en cloududbyders administrerede tjenester — så jeres lille team bruger sin energi på det kliniske problem, ikke på at genopfinde identitet eller beskeder. Vær alligevel opmærksomme på lock-in: vælg åbne standarder og hold jeres data portable, fordi den kapabilitet, I lejer billigt i dag, kan blive den afhængighed, der begrænser jer i morgen. Internt hold jeres egen "platform" tynd til næsten usynlighed; et team på to har ikke brug for en gylden-sti-abstraktion, det har brug for at levere. Disciplinen er at vide, hvornår I er vokset nok til, at en fælles intern kapabilitet er værd at udtrække.

Lille virksomhed#

En etableret lille udbyder — en lægepraksis, et lokalt apotek, et plejehjem eller en enkelt klinik — er næsten altid platformsforbruger med ringe eller ingen egen digital kapabilitet, så de platforme, den afhænger af, reelt fastsætter dens gulv for sikkerhed og lighed. Jeres praktiske opgave er at vælge understøttede fælles tjenester frem for skræddersyede løsninger, I ikke kan bemande eller vedligeholde, og at foretrække nationale kapabiliteter som NHS login, demografisk opslag og NHS Notify, der allerede bærer tilgængeligheds- og klinisk sikkerhedsarbejde, I aldrig kunne finansiere alene. Insistér på ægte selvbetjent onboarding og klar dokumentation, fordi I ikke har noget platformsteam at eskalere til og ikke har råd til et langt integrationsprojekt. Følg finansieringsmodellen nøje: en viderefaktureret platform kan prissætte en lille udbyder ud af netop de sikkerhedskapabiliteter, den mest har brug for, så pres på for ligelig adgang og rejs det i enhver køreplansstyring, I kan nå. Hold også øje med udgangen, da proprietær leverandørlåsning er sværest at slippe ud af, når I ikke har internt teknisk personale til at migrere jer. Gevinsten er, at en god fælles platform lader jer arve standarder, I ikke kunne bygge, og opfylde de samme pligter som store organisationer uden deres ressourcer.

Stor virksomhed#

Et stort hospital eller et nationalt organ har skalaen til at berettige reelle platforme og bureaukratiet til at ødelægge dem. Risikoen er et centralt platformsteam, der bliver et elfenbenstårn — arkitektonisk elegant, langsomt til at reagere og løsrevet fra de leveranceteams, det angiveligt tjener. Modvirk det ved at finansiere platforme som langlivede produkter med egne køreplaner og brugerforskning og ved at måle dem på adoption og udvikleroplevelse frem for på overholdelse af påbud. Multitenancy, isolation og et klinisk sikkerhedscase for selve platformen bliver essentielle i denne skala. Gevinsten er enorm: en kapabilitet bygget én gang til høj standard og arvet af dusinvis af tjenester, hvilket hæver gulvet for hele organisationen.

Myndighed#

På nationalt og systemniveau er rammen digital offentlig infrastruktur og government as a platform: byg fælles komponenter — identitet, notifikationer, demografisk opslag, dataudveksling — som hundredvis af organisationer sammensætter til tjenester. Indsatsen for åbenhed er højest her, fordi en national platform bygget på proprietær lock-in kan fange et helt sundhedssystem i en generation. Styring og finansiering må afklares åbent, med reel indflydelse for de mindre og fattigere organisationer, som fælles platforme delvist findes for at beskytte. Fristelsen til at påbyde er stærkest og farligst på dette niveau; en national platform, der er påkrævet, men uelsket, avler skyggesystemer over hele landet. Optjen adoption gennem kvalitet og support, og behandl hver omgåelse som et signal om at forbedre.

Typiske fejlmønstre#

• Flaskehalsen. Hvert team må vente på det centrale platformsteam for at gøre noget, så platformen bremser levering i stedet for at accelerere den. Kuren er selvbetjening: teams bør kunne onboarde og handle uden en ticket.
• Elfenbenstårnet. Platformen er designet af mennesker langt fra levering, er teknisk beundringsværdig og passer til intet reelt teams behov. Kuren er at drive platformen som et produkt med kontinuerlig brugerforskning.
• Påbudt, men uelsket. Platformen er krævet af politik, men omgået i praksis, og akkumulerer skyggesystemer og harme. Kuren er at optjene adoption gennem kvalitet og at lytte, når teams router udenom.
• Alt-platformen. Et overambitiøst omfang betyder, at platformen kommer for sent, gør for meget og ingenting godt. Kuren er den tyndest mulige platform, vokset ud af evidens for efterspørgsel.
• Lock-in ved snigende. Platformen binder i det stille teams til en proprietær leverandør eller grænseflade, og omkostningen ved at forlade bliver uoverkommelig. Kuren er åbne standarder og en dokumenteret, afprøvet udgangsvej.
• Finansieringstvetydighed. Ingen aftalte, hvem der betaler eller hvem der beslutter, så platformen sultes eller bliver en politisk slagmark. Kuren er en eksplicit, offentliggjort finansierings- og styringsmodel.
• Sikkerhed som eftertanke. Platformen har intet eget klinisk sikkerhedscase, så hver forbrugende tjeneste arver uvurderet risiko. Kuren er at behandle platformens DCB0129-sikkerhedscase som grundlæggende.

Modenhedsmodel#

Tjekliste#

• Platformen har en navngiven produktansvarlig, en køreplan og løbende (ikke projekt-)finansiering.
• I startede med den tyndest mulige platform og kan nævne, hvad I bevidst udskød.
• Den understøttede vej er reelt hurtigere og lettere end at teams bygger deres egen.
• Nye teams kan onboarde gennem selvbetjening, med en sandkasse og klar dokumentation.
• I måler adoption, tid-til-første-succes, tilgængelighed og udvikleroplevelse.
• Finansieringsmodellen (central, viderefakturering eller hybrid) er aftalt og offentliggjort.
• Køreplansstyring giver tenants, også mindre organisationer, en reel stemme.
• Platformen er bygget på åbne standarder, og en dokumenteret udgangsvej findes.
• Multi-tenant data- og fejlisolation er designet ind, ikke boltet på.
• Platformen har sit eget kliniske sikkerhedscase (DCB0129), som forbrugende teams kan stole på.
• I behandler teams, der router udenom platformen, som forskning, ikke trods.

Centrale kilder#

• GOV.UK Service Manual og Government Digital Services skrifter om government as a platform og fælles komponenter.
• Matthew Skelton og Manuel Pais, Team Topologies — platformsteams, tyndest mulige platform og kognitiv belastning.
• NHS England udvikler- og API-vejledning (NHS login, NHS Notify, nationale API’er og Spine-tjenesterne).
• DCB0129- og DCB0160-standarderne for klinisk risikostyring for sundheds-it-systemer.
• Verdensbanken og FN’s skrifter om digital offentlig infrastruktur og genbrugelige offentlige byggeklodser.
• Tim O’Reilly, "Government as a Platform", i Open Government (O’Reilly Media).

Referencer#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation