Ämne 4.1 — Plattformar och gemensamma tjänster

Inom hälsa och vård är en gemensam plattform inte en kostnadsbesparande bekvämlighet utan ett sätt att göra säkerhet, jämlikhet och förtroende upprepbara — så att varje team ärver dem i stället för att uppfinna dem på nytt, ofta dåligt.

Varför detta är viktigt inom hälsa och vård#

När ni driver digital leverans över ett hälso- och vårdsystem märker ni snart att samma förmågor byggs om om och om igen. Varje tjänst vill autentisera en patient, slå upp en demografisk post, skicka ett meddelande, registrera ett granskningsspår eller kontrollera en klinikers roll. Lämnade åt sig själva bygger varje team sin egen version. Ni får ett dussin inloggningsskärmar, ett dussin sätt att hantera en patients identitet, ett dussin granskningsloggar av varierande kvalitet — och ett dussin ställen där en säkerhetsdefekt kan gömma sig.

Denna dubblering är dyr, men det djupare problemet är att den är farlig och orättvis. Inom hälsa och vård bär rörmokeriet klinisk risk. Om ett teams patientmatchning är svagare än ett annats kan en patient få fel journal. Om en tjänsts tillgänglighet är sämre utesluts vissa människor i tysthet. Om granskningsspår skiljer sig stannar en utredning om informationsstyrning av. En gemensam plattform låter er bygga en förmåga en gång, till hög standard, med arbetet för klinisk säkerhet och tillgänglighet gjort ordentligt, och sedan låta många team ärva den standarden i stället för att var och en chansar på att få rätt ensam.

Plattformar formar också takten för hela systemet. En god plattform innebär att en ny tjänst kan nå patienter på veckor i stället för år, eftersom de svåra, generiska delarna redan finns. En dålig eller saknad plattform innebär att varje team bär hela tyngden av infrastrukturen, och leveransen saktar ned till takten hos det minst resursstarka teamet. I en sektor under ihållande ekonomiskt tryck och personaltryck, där samma nationella och lokala förmågor behövs av hundratals organisationer, är det ett av de beslut med störst hävstång ni kommer att fatta att få plattformar rätt. Detta ämne handlar om hur man bygger och driver dem väl — som produkter med verkliga användare, inte som föreskriven infrastruktur ingen älskar.

Grundläggande begrepp#

En plattform är i detta sammanhang en uppsättning förmågor som andra team bygger på snarare än bygger själva. Den mest användbara moderna ramningen är att en plattform är en produkt med interna användare. Dess kunder är era egna utvecklare, leveransteam och partnerorganisationer, och dess framgång mäts som varje produkts: genom införande, genom upplevelsen hos dem som använder den och genom de utfall den möjliggör.

Flera närliggande idéer ligger under detta. Gemensamma tjänster (shared services) är det äldre organisatoriska mönstret att tillhandahålla en förmåga en gång för många delar av en organisation i stället för att duplicera den i var och en. Digital offentlig infrastruktur (digital public infrastructure) utvidgar detta till ett helt samhälles nivå — de delade, återanvändbara, interoperabla byggstenar (identitet, betalningar, datautbyte) som offentliga och privata tjänster byggs på. ”Government as a platform” (staten som plattform), en fras myntad av Tim O'Reilly och upptagen av digitala förvaltningsteam världen över, tillämpar samma logik på staten: staten tillhandahåller gemensamma komponenter, och myndigheter sätter ihop tjänster av dem i stället för att var och en bygger hela stacken.

Tekniskt exponerar plattformar ofta sina förmågor genom ett programmeringsgränssnitt (application programming interface, API) — ett definierat kontrakt som låter ett system använda ett annats förmåga utan att känna till dess inre. De bygger ofta på molnmodeller för plattform som tjänst (platform as a service, PaaS), och delade nationella plattformar förlitar sig typiskt på multitenans (multitenancy), där en enda instans betjänar många organisationer samtidigt som deras data och konfiguration hålls åtskilda.

Tre begrepp styr om en plattform hjälper eller skadar. Det första är kognitiv belastning (cognitive load): en god plattform minskar mängden ett leveransteam måste hålla i huvudet, så att teamet kan koncentrera sig på det kliniska eller vårdmässiga problem det finns till för att lösa. Det andra är den ”asfalterade vägen” eller ”gyllene stigen” (golden path) — ett väl stött, åsiktsstarkt standardsätt att utföra en vanlig uppgift som är enklare att följa än att undvika, erbjudet genom självbetjäning snarare än grindvakt. Det tredje är undvikande av leverantörsinlåsning (vendor lock-in), vilket är skälet till att plattformar bör byggas på öppna standarder så att organisationer kan flytta mellan leverantörer utan oöverkomliga byteskostnader.

Inom hälsa specifikt är nationella gemensamma tjänster redan en del av landskapet. Historiska program såsom NHS Connecting for Health etablerade NHS Spine, en uppsättning nationella tjänster som bär kärndata såsom Personal Demographics Service. Moderna motsvarigheter inkluderar nationella API:er, NHS login för medborgarautentisering och NHS Notify för meddelanden — förmågor som erbjuds så att enskilda tjänster inte behöver bygga om dem. Där en plattform tillhandahåller ett gemensamt sätt att styrka vem någon är exponerar den ofta enhetlig inloggning (single sign-on) så att en kliniker autentiserar sig en gång i stället för upprepade gånger. Detta ämne rör hur man bygger och driver sådana plattformar; detaljerna om vem ni är och vad ni får göra hör hemma i Ämne 4.2 — Identitets- och åtkomsthantering, och standarderna som låter system utbyta data hör hemma i Ämne 4.3 — Interoperabilitet och datastandarder.

Bästa praxis#

1. Behandla plattformen som en produkt, inte ett projekt. En plattform har en färdplan, en produktansvarig, löpande finansiering och användare vars nöjdhet ni mäter — inte ett slutdatum och en överlämning. Projekt avslutas och förfaller; plattformar måste drivas på obestämd tid eftersom team blir beroende av dem. Finansiera och bemanna därefter, och se Ämne 5.0 — Produktledt arbete för den operativa disciplin detta innebär.

2. Börja med den tunnaste fungerande plattformen. Bygg den minsta uppsättning gemensamma förmågor som genuint avlastar team, och lägg bara till mer när verklig efterfrågan och verklig smärta motiverar det. Denna idé om den ”tunnaste fungerande plattformen”, introducerad i Ämne 1.1 — Den operativa modellen, skyddar mot det vanligaste felet: en ambitiös central plattform som försöker göra allt, anländer sent och passar ingen. Låt plattformen växa av evidens för användning, inte av arkitektonisk aspiration.

3. Gör den asfalterade vägen till den enkla vägen. En plattform vinner införande genom att göra den stödda vägen snabbare och enklare än att bygga sitt eget — genom självbetjäning vid introduktion, tydlig dokumentation, sandlådor och förnuftiga standardinställningar med klinisk säkerhet och tillgänglighet inbyggda. Om det är långsammare eller mer smärtsamt att använda plattformen än att gå runt den kommer team att gå runt den, och ni har spenderat pengar för att skapa en flaskhals. Designa för utvecklarens första timme och deras värsta dag.

4. Mät framgång med införande och användarupplevelse, inte existens. De rätta måtten är hur många team som använder plattformen frivilligt, hur lång tid introduktionen tar, hur ofta plattformen är tillgänglig och hur dess användare betygsätter upplevelsen. Fåfängemått såsom antal driftsatta tjänster säger ingenting om huruvida team hjälps. Instrumentera plattformen, kör regelbunden forskning med de team som bygger på den och behandla en fallande eller stagnerande införandekurva som ett produktproblem att åtgärda, inte ett efterlevnadsproblem att verkställa.

5. Bygg på öppna standarder och håll utträdet billigt. Föredra öppna, brett antagna standarder och gränssnitt så att varken ni eller teamen på er plattform är fångade. Dokumentera hur ett team skulle lämna, och se till att de kunde. Paradoxalt nog är det att göra det lätt att lämna det som gör att team känner sig trygga med att komma, och det håller plattformen ärlig eftersom den måste förtjäna sin plats i stället för att förlita sig på fångenskap. Detta minskar direkt leverantörsinlåsningen över det bredare beståndet som diskuteras i Ämne 4.0 — Teknisk arkitektur, moln och äldre system.

6. Var uttryckliga om vem som betalar och vem som avgör. En gemensam plattform behöver en finansieringsmodell och en styrningsmodell överenskomna i förväg: om den är centralt finansierad, debiteras användare eller är en hybrid, och hur dess färdplan prioriteras mellan konkurrerande hyresgäster (tenants). Tvetydighet här är det som förvandlar plattformar till politiska slagfält. Publicera modellen, ge användare en verklig röst i färdplanen och se över den när plattformen växer.

7. Driv plattformsteamet med tydliga ansvar och gränser. Organisera kring ett dedikerat plattformsteam vars uppgift är att möjliggöra för strömlinjerade leveransteam genom självbetjäning, som beskrivs i mönstren i Team Topologies i Ämne 7.0 — Teamstrukturer, roller och ansvar. Håll gränssnittet mellan plattform och konsumenter uttryckligt — vad plattformen lovar, vad den inte gör och hur man får support — så att plattformen möjliggör snarare än vaktar.

8. Designa för multitenans, isolering och säkerhet från början. Om många organisationer ska dela en plattform är åtskillnad av deras data, konfiguration och felområden ett grundläggande krav, inte en senare funktion. Inom hälsa och vård är detta också ett krav på informationsstyrning och klinisk säkerhet: en hyresgästs incident får inte exponera eller utsätta en annans patienter för fara. Bygg in isolering, observerbarhet per hyresgäst och ett kliniskt säkerhetsunderlag för själva plattformen enligt DCB0129.

Frågor att diskutera med ditt team#

1. Vilken är den tunnaste plattform som genuint skulle avlasta våra team, och vad frestas vi att bygga som vi inte bör? Det är lätt att utforma en expansiv plattform på en whiteboard och svårt att leverera en som team älskar. Utgå från den verkliga, upprepade smärta era leveransteam känner i dag — den förmåga tre eller fler team var och en bygger om — och motstå att lägga till något som bara ett team behöver eller som ingen ännu har bett om. Fråga vilka förmågor som är genuint gemensamma kontra vilka som bara ser lika ut på avstånd men skiljer sig i de detaljer som spelar klinisk roll. Beakta kostnaden för att göra fel: en förhastad gemensam förmåga som team måste kringgå är värre än ingen plattform alls. Kom överens om en uttrycklig gräns mellan vad plattformen kommer att äga nu och vad den medvetet skjuter upp. Se över den gränsen enligt schema och flytta poster över bara när efterfrågan och smärta har visats. Disciplinen är att säga nej till goda idéer som ännu inte förtjänar sin plats.

2. Hur ska vi finansiera plattformen och avgöra dess färdplan när hyresgäster är oense? En plattform betjänar många team med konkurrerande prioriteringar, och i det ögonblick två viktiga hyresgäster vill ha oförenliga saker prövas er styrning. Avgör nu om plattformen är centralt finansierad, debiteras användare eller är en hybrid, och var ärliga om de incitament varje modell skapar: debitering kan dämpa införande, medan central finansiering kan koppla bort plattformen från användarbehov. Avgör vem som håller färdplanen, hur hyresgäster påverkar den och hur ni avgör mellan en stor organisations akuta behov och en liten organisations grundläggande behov. Beakta jämlikhet uttryckligen, eftersom en debiteringsmodell kan prisa ut mindre eller fattigare organisationer från gemensamma säkerhetsförmågor. Kom överens om hur ni hanterar en hyresgäst som vill finansiera en funktion de andra inte vill ha. Skriv ned modellen och publicera den, så att beslut känns som styrning snarare än gunstlingsfavorisering. Förbind er sedan att se över den när plattformen och dess användarbas växer.

3. Hur ska vi veta att plattformen är älskad snarare än bara föreskriven, och vad gör vi om den inte är det? En plattform kan vara tekniskt sund, officiellt obligatorisk och i tysthet avskydd — och en föreskriven men ogillad plattform ackumulerar kringgåenden, skuggsystem och missnöje. Avgör i förväg vilka signaler som säger sanningen: frivilligt införande där team har ett val, tid till första framgång för ett nytt team, tillgänglighet och incidenthistorik samt direkt återkoppling från de utvecklare som använder den. Tala om hur ni samlar in ärlig återkoppling när ni också har makt över era användare, eftersom människor är ovilliga att kritisera en plattform de är tvungna att använda. Kom överens om hur en sund införandekurva ser ut och vilket tröskelvärde som skulle utlösa en allvarlig omprövning. Avgör om ni någonsin skulle vara villiga att avveckla eller ersätta plattformen om evidensen krävde det. Att vara villig att höra att din plattform inte fungerar är det som håller den fungerande. Alternativet är att upptäcka sanningen först när en större tjänst går runt er.

4. Hur ska vi hålla utträdet billigt, och kunde ett team på vår plattform faktiskt lämna om de behövde? Det är lätt att påstå att man är byggd på öppna standarder och något helt annat att bevisa att ett team kunde gå därifrån utan en oöverkomlig omskrivning. Tala ärligt om var inlåsning smyger in — ett proprietärt gränssnitt, ett odokumenterat dataformat, ett nationellt beroende utan alternativ — och om kostnaden för att lämna i tysthet stiger över tid. Avgör vem som ansvarar för att dokumentera och periodvis testa en utträdesväg, i stället för att anta att en finns. Beakta att inlåsningsrisken inom hälsa och vård förstärks: en nationell plattform byggd på fångenskap kan fånga ett helt system i en generation, och de team som minst klarar byteskostnader är vanligen de minsta vårdgivarna. Ett ärligt svar namnger de specifika beroenden ni skulle ha svårt att nysta upp, beskriver ett konkret utträde för åtminstone en verklig hyresgäst och behandlar portabilitet som en funktion ni underhåller snarare än en slogan ni upprepar. Kom ihåg att att göra det lätt att lämna ofta är det som gör att team känner sig trygga med att komma.

5. Bär plattformen sitt eget kliniska säkerhetsunderlag, och hur hindrar vi en hyresgästs fel från att skada en annans patienter? När många organisationer delar en plattform bär dess rörmokeri klinisk risk å alla tjänsters vägnar som bygger på den, så en defekt i patientmatchning eller ett läckage mellan hyresgäster är inte ett teams problem utan allas. Avgör om plattformen har ett eget DCB0129-säkerhetsunderlag som konsumerande team genuint kan förlita sig på, eller om varje tjänst i tysthet omvärderar samma delade risk. Diskutera hur ni isolerar hyresgästers data, konfiguration och felområden, och hur ni skulle veta om den isoleringen bröts — observerbarhet per hyresgäst är skillnaden mellan att begränsa en incident och att upptäcka den sent. Beakta även konsekvenserna för informationsstyrning: en utredning av en hyresgäst får inte kräva att en annans journaler exponeras. Ett ärligt svar kan peka på ett underhållet säkerhetsunderlag, en testad isoleringsgräns och en tydlig redogörelse för vad plattformen lovar om säkerhet kontra vad som förblir varje tjänsts ansvar. Att behandla säkerhet och isolering som grundläggande, inte som senare funktioner, är vad som låter team ärva kvalitetssäkring snarare än chansa på den.

6. Var går gränsen mellan plattformsteamet och de team det betjänar, och hur hindrar vi plattformen från att bli en flaskhals? En gemensam plattform kan accelerera varje team eller sakta ned alla till takten i en enda central kö, och skillnaden ligger i hur skarpt ni har dragit gränssnittet mellan plattform och konsumenter. Avgör vad plattformen äger och lovar, vad den uttryckligen inte gör och hur ett team får support utan att vänta på en ärendehantering för rutinarbete. Tala om självbetjäning som standard: om introduktion, tillhandahållande eller en vanlig ändring alla kräver att plattformsteamet agerar för hand har ni byggt en grind snarare än en asfalterad väg. Beakta den bytesaffär om kognitiv belastning som ligger i hjärtat av en god plattform — den ska minska vad ett leveransteam måste hålla i huvudet så att det kan koncentrera sig på det kliniska problemet, inte lägga till ett nytt lager att förhandla med. Ett ärligt svar namnger de uppgifter som fortfarande går genom plattformsteamet som en flaskhals, anger en riktning för att göra dem till självbetjäning och är uppriktigt om var plattformen möjliggör kontra var den vaktar.

I praktiken: ett exempel från hälsa och vård#

Ett integrerat vårdsystem (ICS) som täcker flera NHS-sjukhus, närsjukvårdsutförare och en kommuns socialtjänst för vuxna stöter hela tiden på samma vägg. Varje ny digital tjänst — en virtuell vårdavdelning, ett självremissformulär för sjukgymnastik i närsjukvården, ett verktyg för tillsyn av vårdhem — ägnar sina första tre månader åt att bygga om samma grunder: styrka vem patienten är, kontrollera den professionellas roll, skicka sms-påminnelser och skriva ett granskningsspår. Den virtuella vårdavdelningens patientmatchning visar sig vara svagare än sjukgymnastikteamets, och ett tillbud inträffar när en påminnelse skickas till fel person. ICS digitala ledning känner igen mönstret: de betalar många gånger om för förmågor som borde finnas en gång, och variationen är en säkerhetsrisk.

I stället för att beställa en storslagen ICS-plattform börjar de tunt. De sätter upp en enda gemensam tjänst som gör en sak väl: den omsluter NHS login och den nationella Personal Demographics Service bakom ett rent, dokumenterat API med en sandlåda, så att vilket team som helst kan verifiera en medborgares identitet och hämta en bekräftad demografisk post genom en enda stödd väg. Ett litet plattformsteam på fem behandlar det som en produkt. De publicerar en guide för den asfalterade vägen, erbjuder självbetjäning vid introduktion och sätter ett mål att ett nytt team ska göra sitt första lyckade anrop inom en dag. Avgörande är att de inte föreskriver det. De gör det till det enklaste alternativet och låter den virtuella vårdavdelningens team vara den första villiga användaren.

Finansieringsmodellen överenskoms öppet: ICS finansierar centralt plattformens kärna under de två första åren så att införande inte dämpas av debitering, med en översyn efter arton månader. En grupp över vårdgivare, inklusive kommunen, håller färdplanen och träffas varje månad. När sjukgymnastikteamet nästa gång ber om en meddelandeförmåga lägger plattformsteamet till ett tunt omslag runt NHS Notify i stället för att bygga meddelandehantering från grunden — bygg en gång, använd många. Inom ett år har sex team frivilligt antagit identitetstjänsten, introduktionen har minskat från månader till dagar och plattformsteamet publicerar öppet sina tillgänglighets- och införandetal. När ett sjukhus egenutvecklade system går runt plattformen behandlar teamet det som forskning snarare än trots, lär sig den friktion som drev beslutet och åtgärdar den. Plattformen växer eftersom team väljer den, och ICS ärver ett enda, väl testat, tillgängligt sätt att göra de riskfyllda, vanliga sakerna.

Sektorperspektiv#

Startup-företag#

Ett hälsotekniskt startup-företag bygger sällan plattformar för andra; det bygger på dem. Er hävstång kommer av att konsumera nationella plattformar och molnplattformar — NHS login, nationella API:er, en molnleverantörs förvaltade tjänster — så att ert lilla team ägnar sin energi åt det kliniska problemet, inte åt att uppfinna identitet eller meddelanden på nytt. Bevaka ändå inlåsning: välj öppna standarder och håll era data portabla, eftersom den förmåga ni hyr billigt i dag kan bli det beroende som begränsar er i morgon. Internt, håll er egen ”plattform” tunn till nästan osynlighet; ett team på två behöver ingen abstraktion för en gyllene stig, det behöver leverera. Disciplinen är att veta när ni har vuxit nog för att en gemensam intern förmåga är värd att brytas ut.

Småföretag#

En etablerad liten vårdgivare — en läkarpraktik, ett närapotek, ett vårdhem eller en klinik på en enda ort — är nästan alltid en plattformskonsument med liten eller ingen egen digital förmåga, så de plattformar den är beroende av sätter i praktiken dess golv för säkerhet och jämlikhet. Er praktiska uppgift är att välja stödda gemensamma tjänster framför egenutvecklade lösningar ni inte kan bemanna eller underhålla, och föredra nationella förmågor såsom NHS login, demografisk uppslagning och NHS Notify som redan bär tillgänglighets- och klinisk säkerhetsarbete ni aldrig kunde finansiera ensamma. Insistera på genuin självbetjäning vid introduktion och tydlig dokumentation, eftersom ni inte har något plattformsteam att eskalera till och inte har råd med ett utdraget integrationsprojekt. Bevaka finansieringsmodellen noga: en plattform med debitering kan prisa ut en liten vårdgivare från just de säkerhetsförmågor den mest behöver, så driv på för rättvis tillgång och lyft det i all färdplansstyrning ni kan nå. Håll även ett öga på utträde, eftersom proprietär leverantörsinlåsning är svårast att fly när ni saknar teknisk personal internt för att migrera er. Vinsten är att en god gemensam plattform låter er ärva standarder ni inte kunde bygga, och uppfylla samma plikter som stora organisationer utan deras resurser.

Storföretag#

Ett stort sjukhus (trust) eller nationellt organ har skalan för att motivera verkliga plattformar och byråkratin för att förstöra dem. Risken är ett centralt plattformsteam som blir ett elfenbenstorn — arkitektoniskt elegant, långsamt att svara och bortkopplat från de leveransteam det förment betjänar. Motverka detta genom att finansiera plattformar som långlivade produkter med egna färdplaner och användarforskning, och genom att mäta dem på införande och utvecklarupplevelse snarare än efterlevnad av föreskrifter. Multitenans, isolering och ett kliniskt säkerhetsunderlag för själva plattformen blir nödvändiga i denna skala. Vinsten är enorm: en förmåga byggd en gång till hög standard och ärvd av dussintals tjänster, som höjer golvet för hela organisationen.

Staten#

På nationell nivå och systemnivå är ramningen digital offentlig infrastruktur och staten som plattform: bygg gemensamma komponenter — identitet, meddelanden, demografisk uppslagning, datautbyte — som hundratals organisationer sätter samman till tjänster. Insatserna för öppenhet är högst här, eftersom en nationell plattform byggd på proprietär inlåsning kan fånga ett helt hälsosystem i en generation. Styrning och finansiering måste utarbetas öppet, med verkligt inflytande för de mindre och fattigare organisationer som gemensamma plattformar delvis finns för att skydda. Frestelsen att föreskriva är starkast och farligast på denna nivå; en nationell plattform som är obligatorisk men ogillad föder skuggsystem över hela landet. Förtjäna införande genom kvalitet och support, och behandla varje kringgående som en signal att förbättra.

Vanliga felmönster#

• Flaskhalsen. Varje team måste vänta på det centrala plattformsteamet för att göra något, så plattformen saktar ned leveransen i stället för att accelerera den. Botemedlet är självbetjäning: team ska kunna introduceras och agera utan ett ärende.
• Elfenbenstornet. Plattformen utformas av människor långt från leveransen, är tekniskt beundransvärd och passar inget verkligt teams behov. Botemedlet är att driva plattformen som en produkt med kontinuerlig användarforskning.
• Föreskriven men ogillad. Plattformen krävs av policy men kringgås i praktiken, och ackumulerar skuggsystem och missnöje. Botemedlet är att förtjäna införande genom kvalitet och att lyssna när team går runt er.
• Allt-plattformen. Ett överambitiöst omfång innebär att plattformen anländer sent, gör för mycket och inget av det väl. Botemedlet är den tunnaste fungerande plattformen, växt ur evidens för efterfrågan.
• Inlåsning i smyg. Plattformen binder i tysthet team till en proprietär leverantör eller ett proprietärt gränssnitt, och kostnaden för att lämna blir oöverkomlig. Botemedlet är öppna standarder och en dokumenterad, testad utträdesväg.
• Oklar finansiering. Ingen kom överens om vem som betalar eller vem som avgör, så plattformen svälter eller blir ett politiskt slagfält. Botemedlet är en uttrycklig, publicerad finansierings- och styrningsmodell.
• Säkerhet som eftertanke. Plattformen har inget eget kliniskt säkerhetsunderlag, så varje konsumerande tjänst ärver obedömd risk. Botemedlet är att behandla plattformens DCB0129-säkerhetsunderlag som grundläggande.

Mognadsmodell#

Checklista#

• Plattformen har en namngiven produktansvarig, en färdplan och löpande (inte projekt-) finansiering.
• Ni började från den tunnaste fungerande plattformen och kan namnge vad ni medvetet sköt upp.
• Den stödda vägen är genuint snabbare och enklare än att team bygger sitt eget.
• Nya team kan introduceras genom självbetjäning, med en sandlåda och tydlig dokumentation.
• Ni mäter införande, tid till första framgång, tillgänglighet och utvecklarupplevelse.
• Finansieringsmodellen (central, debitering eller hybrid) är överenskommen och publicerad.
• Färdplansstyrningen ger hyresgäster, inklusive mindre organisationer, en verklig röst.
• Plattformen är byggd på öppna standarder och en dokumenterad utträdesväg finns.
• Multitenansisolering av data och fel är designad in, inte påklistrad.
• Plattformen har ett eget kliniskt säkerhetsunderlag (DCB0129) som konsumerande team kan förlita sig på.
• Ni behandlar team som går runt plattformen som forskning, inte trots.

Viktiga källor#

• GOV.UK Service Manual och Government Digital Services skrifter om staten som plattform och gemensamma komponenter.
• Matthew Skelton och Manuel Pais, Team Topologies — plattformsteam, tunnaste fungerande plattform och kognitiv belastning.
• NHS Englands utvecklar- och API-vägledning (NHS login, NHS Notify, nationella API:er och Spine-tjänsterna).
• DCB0129 och DCB0160, standarder för klinisk riskhantering för hälso-IT-system.
• Världsbankens och FN:s skrifter om digital offentlig infrastruktur och återanvändbara offentliga byggstenar.
• Tim O'Reilly, ”Government as a Platform”, i Open Government (O'Reilly Media).

Referenser#

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