Mer frågor Flashcards
Vad är skillnaden på institutionalization phase och adaptation phase?
Adaptation phase:
- Handlar om hur man anpassar sig till nya behov, teknologier och användarbas
- Handlar om att få tillväxt, och för att fascilitera det så ska man tillåta mycket variation hos de olika modulerna(i e-recept fallet är det enskilda journalsystemens e-recepts moduler). Dvs. den digitala infrastrukturen ska anpassa sig till de lokala tillämpningarna.
- Enl. Hanseth och Lyytinen ska det vara modulärt, simpelt och flexibelt.
- Bottom-up
- Bra i kontext i gällande utvecklingen av internet
Institutionaliazation phase:
- Både adaptation phase och instituionalization phase strävar efter tillväxt av användarbas.
- Top-down
- Ex. gällande e-recept så standardiserade man processen i form av exchange contract
- Ej självorganiserande, tvungen att gå in och styra upp det på en organisatorisk nivå
Vad är designreglerna i bootstrap phase?
- Utveckla IT-capability som är direkt användbar
- Utgå från en installerad bas, dvs. använd befintlig infrastruktur där det är möjligt av ex. plattformar, applikationer och IT-capabilities
- Rikta IT-kapaciteten mot en specifik användargrupp
- Bootstrap phase medför network effect vilket skapar momentum
Förklara DPI (Digital Practice Interface)
Digital Practice
- Möjliggör arbete över organisatoriska gränser genom en helt digital praktik.
- Sträcker sig över olika kontexter
Digital Practice Interface
- Specifikt utformat för hälso och sjukvården
- Interface mellan verksamheter
- Exchange contract som har utvecklats, beskriver hur man ska bete sig ex. mellan Föreskrivare och apotekare.
- Ex. så föreskrivaren tar mer ansvar för kvalitet av recepten för att reducera errors.
- Grundar sig i för mycket workarounds som apotekare tidigare behövde göra.
Vad är innehåller/är ett Exchange Contract
- Kan ses som en kravspec för utbyte av information mellan e-receptsmoduler.
- Är inte bara ett API och utan också ett DPI
- Dvs. Det reglerar beteenden i verksamheten
- Innehåller kravspec för föreskrivare
- Ex. Ni måste ta mer ansvar för receptkvaliten
- Inför ex. regler som ska gälla mellan föreskrivaren och apotekaren
Förklara konstitutiva och regulativa regler
Konstitutiva regler
ex.
- Hur föreskrivning ska gå till
- struktur, dataintegrity, hur ska det valideras?
- Vem är en läkare? Vem blir en sådan insitutionelt entitet
- Definierar vilka förhållanden som behövs i ett specifikt sammanhang för att identifiera, skapa, upprätthålla institutionella entiteter.
- I fallet e-recept liknar de verksamhetsregler mer tekniska regler ex. “data-integrity-rules”
Regulativa regler:
- Läkare ska föreskriva recept
- Patient ska ta emot läkemedel av en apotekare
- Instruktioner gällande dosering till patienten, användningsbeskrivning av läkemedlet till patienten.
- Reglerar vem som har rätt att göra vad inom interaktionsprocessen
- Bestämmer vilka åtgärder som krävs, samt vilka åtgärder som är förbjudna eller tillåtna och av vem.
- ex vilka åtgärder som krävs för att skriva ett e-recept.
Vad menas med IT-capability?
- Möjligheten och/eller rätten för användaren eller en användargrupp att utföra en uppsättning åtgärder på ett beräkningsobjekt eller en process.
Ett exempel på en sådan kapacitet skulle vara en textredigerare eller e-post.
Det finns två olika Path dependencies inom II.
Förklara Cumulative adoption
Kumulativ Adaption sker när en informationsinfrastrukturs utvecklare bygger upp en installerad bas innan någon annan har en liknande struktur. “först blir störst”. Denna utveckling kan på ett sätta grunden för andra utvecklare som utgår ifrån IIn i fråga. Bootstrapping för kumulativ tillväxt kan ske när timingen är rätt och användarna är mottagliga för förändringen. (tror ett exempel på detta kan vara bitcoin, all krypto efter det utgår från något sätt från bitcoin?)
Det finns två olika Path dependencies inom II.
Förklara technology traps.
Teknologifällor har och göra med tidiga blinda beslut som senare begränsar framtida tillväxt. När design för tillväxt av infrastruktur görs så utgås rent tekniskt från den installerade basen. En teknologifälla kan tex behöva vara att utgå från och behöva stödja gamla legacysystem.
- ex. i URL finns top-domän och bottom-domän, hade varit mer logiskt att ha dom inverterade men går ej att ändra nu pga för många som använder det.
- ex. Personummer, verksamhetsmässigt beslut att använda det som studentID.
I artikeln ”Pre-conditions for public sector e-infrastructure development” Eriksson and Goldkuhl
(2013) beskrivs den rättsliga förutsättningen (legal precondition) i samband med utveckling av den
digitala infrastrukturen för ekonomiskt bistånd (social allowance).
Vad innefattar legal precondition och vad har den för enablers / obstacle
De legala förutsättningarna innebär att det vid införandet av en e-infrastruktur finns legala krav eller hinder som man måste ta hänsyn till. Detta kan styra hur infrastrukturen ska designas får det önskvärda sättet.
Enabler:
Regulationer som kräver och specificerar elektroniskt informationsutbyte.
Obstacle:
Inga sanktioner om organisationen inte följer reguleringar.
Olika tolkningar på lagarna och HUR informationsutbytet ska ske tekniskt.
I artikeln ”Pre-conditions for public sector e-infrastructure development” Eriksson and Goldkuhl beskrivs den organisatoriska förutsättningarna.
Vad innefattar organizational precondition och vad har den för enablers / obstacle
Enabler:
Tydliga organisatoriska tilldelningar för nätverkande. Detta innebär att offentliga sektor-organisationer har ett tilldelat ansvar att agera som en informationskälla. Detta är en någorlunda ny tilldelning av ansvar för dessa typer av organisationer.
Obstacle:
Låg erfarenhet från interorganisational utveckling (sammarbete med andra intressenter). Självbild som en separat, självständig organisation. Formel, hierarkisk och autonom organisatorisk struktur.
Owen: Det finns ett växande behov av att alla statliga myndigheter och organisationer börjar arbeta som ett nätverk och samarbeta med varandra. Istället för att fortsätta jobba på i den befintliga hierarkiska struktur, där varje organisation fungerar som en självständig och autonom enhet.
I artikeln ”Pre-conditions for public sector e-infrastructure development” Eriksson and Goldkuhl beskrivs ekonomiska förutsättningarna.
Vad innefattar Economical precondition och vad har den för enablers / obstacle
Det finns ekonomiska motiv för att utveckla en e-infrastruktur men det finns även motiv för att inte göra det. Det kan vara svårt för myndigheterna att bedöma den totala nyttan av att samtliga myndigheter skapar en gemensam e-infrastruktur, då de ofta enbart utgår ifrån den egna verksamhetens ekonomiska förutsättningar när de undersöker hur pass lönsamt och ekonomiskt genomförbart ett sådant projekt skulle vara
Enabler:
Skifte från manuellt utbyte till elektroniskt kan vara ekonomiskt gynnsamt.
Obstacle:
Utvecklingsinitiativ måste vara inom ramarna för budget samt vara en prioritet. Ingen ekonomisk kalkyl som visar att det kommer vara lönsamt. Ingen ekonomisk vinning att som organisation agera informationskälla till andra organisationer. Inga lämpliga ekonomiska modeller för att e-infrastrukturs utveckling.
Förklara och exemplifiera vad som menas med subkategorin av e-infrastructure precondition the Technical precondition
Vad finns det för enablers/ obstacles?
Denna subkategori fokuserar på den tekniska infrastrukturen
som behövs för att möjliggöra e-infrastrukturutveckling.
Det handlar om att ha tillräcklig teknisk kapacitet såsom:
- nätverksinfrastruktur, datorer, servrar, och andra hårdvarukomponenter som behövs för att stödja systemen.
Exempel på detta kan vara tillgång till pålitliga internetanslutningar, serverkapacitet för att hantera dataöverföringar och lagring av information, samt säkerhetsprotokoll för att skydda data. Ett exempel på detta kan vara
behovet av att ha en robust och tillförlitlig serverinfrastruktur för att lagra och hantera data för ett nationellt hälso- eller skattesystem.
Enablers:
Standardiserad och etablerade transport och säkerhets kapabilities.
obstacle:
Brist av erfarenhet i användandet av direkt-access tekniker för informationsutbyte. brist av erfarenhet i att koordinera den tekniska implementationen av mjukvara.
Förklara och exemplifiera vad som menas med subkategorin av e-infrastructure precondition the Informational precondition
Vad finns det för enablers/ obstacles?
Denna subkategori handlar om tillgången till och
kvaliteten på information som behövs för att stödja e-infrastrukturutvecklingen. Det
innefattar att ha tillräckligt med data av hög kvalitet som kan användas för att utveckla och
implementera systemen. Det handlar också om att ha mekanismer för att samla in, lagra, och
distribuera information på ett effektivt sätt. Exempel på detta kan vara att ha tillgång till
uppdaterade och korrekta medicinska journaler för att stödja utvecklingen av ett elektroniskt
patientjournalsystem.
Enabler:
Standarder och vanliga identifierare.
Tillgänglig information i den installerade basens applikationer.
Obstacle:
Rörig applikationsinfrastruktur som är svår att nyttja.
Låg kvalitet av metadata.
Förklara och exemplifiera vad som menas med subkategorin av e-infrastructure precondition the Contractual precondition
Denna subkategori handlar om de juridiska och
avtalsmässiga förutsättningarna som behöver vara på plats för att möjliggöra
e-infrastrukturutveckling. Det inkluderar att etablera tydliga regler och ansvarsområden för
datahantering, integritetsskydd, och användarbehörigheter. Det handlar också om att ha avtal
och överenskommelser på plats mellan olika parter som är involverade i utvecklingen och
användningen av e-infrastrukturen. Ett exempel på detta kan vara att etablera användaravtal
och kontrakt mellan vårdgivare och patienter för att reglera tillgång till och hantering av
elektroniska patientjournaler.
Enabler:
Utökandet av framtida användbarhet av kontraktuella möjligheter man möjliggöra evolutionen av e-infrastrukturen.
Obstacle:
Etablerade IT-leverantörer vill inte öppna deras system.
Etablerade IT-leverantörer verkar vara en säker lösning.
Vad avser Hanseth och lyytinens designprinciper och vilka är det?
Design Initially for direct usefulness
- Avgränsa första användarna som drar nytta av infrastrukturen, se till så att infrastrukturen är simple by design. Komponenterna bör heller inte vara för dyra.
Build upon existing installed base
- Välj infrastruktur som redan är understödjande, dvs. Utnyttja befintlig installerad bas där det är rimligt och möjligt under utvecklandet av ny digital infrastruktur. Ex. identitetshantering i fallet e-recept. Finns ingen mening att bygga om hjulet på nytt när det redan finns befintliga lösningar som fyller kraven.
Expand installed base
- ‘Users before functionality’ – grow the user base always before adding new functionality
- Build and align incentives so that users have real motivation to use the IT capabilities within the II in new ways
- Develop support communities for feedback and learning
Make the IT capability as simple as possible
- Build capabilities that enable growth based on experience and learning Use abstraction and gateways to separate II components by making them loosely coupled
Modularize the II
- Hanseth och Lyytinen förespråkar användandet av gateways för att modularisera infrastrukturen, vilket även bör användas för att öka kompatibiliteten mellan olika standarder.
