Tjänstegränssnitt för domänen kvalitetsregister. PM om tjänstegränssnitt för de nationella kvalitetsregistren på den Nationella Tjänsteplattformen

Storlek: px
Starta visningen från sidan:

Download "Tjänstegränssnitt för domänen kvalitetsregister. PM om tjänstegränssnitt för de nationella kvalitetsregistren på den Nationella Tjänsteplattformen"

Transkript

1 Tjänstegränssnitt för domänen kvalitetsregister PM om tjänstegränssnitt för de nationella kvalitetsregistren på den Nationella Tjänsteplattformen

2 Innehållsförteckning Introduktion... 2 Versionsinformation... 2 Licens... 2 Bakgrund... 2 Problemställning... 3 Lösningsförslag... 4 Interaktionsmönster... 4 Tillståndshantering och ID... 5 Sökningar... 5 Processer... 5 Kontrakt... 6 Metadata... 7 Registering Utformning av kliniskt innehåll Responderobjektet ErrorInformationType Felhantering Vidare information

3 Introduktion Detta dokument är en PM gällande arbetet med att utforma generella tjänstegränssnitt för interaktioner med nationella kvalitetsregister. Arbetet genomförs av Uppsala Kliniska Forsknings Centrum med stöd av SKL genom Nationella Programmet för Data insamling NPDi. Målet med projektet är att utforma interaktionsmönster och konkreta enhetliga tjänster vilka exponeras i den Nationella TjänstePlattformen, NTjP. Tjänsterna ska kunna användas av samtliga vårdproducenter vilka har relevanta avtal med Inera samt uppfyller de tekniska kraven. För Nationella Kvalitetsregister ska tjänstedomänen kunna användas för att exponera grundläggande funktioner för rapportering. Projektet rapporterar till NPDi genom Arkitekturgruppen för kvalitetsregister, vilket är en grupp av arkitekter som representerar landets registercentra samt leverantörer av kvalitetsregistersystem. Pilottester för en första tjänst genomförs sannolikt snarast efter sommaren 2013 och givet ett gott utfall kommer förankringsarbete med Arkitekturledningen, CeHIS att bedrivas under hösten Versionsinformation Version Datum Författare Kommentar 1.0 Tomas Snäckerström, UCR Initial version Licens Denna PM publiceras under Creative Commons enligt Erkännande-DelaLika 2.5 vilket gör det fritt att kopiera och använda innehållet på villkor att ursprung deklareras och licens bibehålls 1. Bakgrund I Sverige finns på nationellt plan ett hundratal så kallade Nationella kvalitetsregister. Det är en verksamhet som byggts upp sedan ett trettiotal år men där utvecklingen och användningen av webbtekniker fått registren att både växa och etablera sig som självklara verktyg för uppföljning av flertalet sjukvårdsområden. Registren täcker normalt någon specifik process eller behandlingen av utvalda diagnoser och är innehållsligt förvaltade av expertgrupper för respektive vårdområde organiserade som sk. Registerhållare. Medel kan tilldelas registren centralt genom Beslutsgruppen för Kvalitetsregister, vid SKL såväl som genom deltagaravgifter från anslutna vårdgivare. Gemensamt för alla kvalitetsregister är att de ur legal bemärkelse har en Centralt Personuppgiftsansvarig, som i regel är en juridisk person vid ett landsting eller annan sjukvårdsmyndighet. Denne har det praktiska ansvaret för att registret drivs och förvaltas i enlighet 1 2

4 med gällande lagar, framförallt då PDL och PUL. Normalt finns en grupp med klinisk expertkunskap formerade som en styrgrupp, vilken beslutar om registrets utformning, funktioner, budget m.m. De svenska kvalitetsregistrens historia har varit något av en framgångssaga. Från de enkla initiativ som startades av drivna läkare som utrustats med persondatorer på 80-talet, till nationellt, och även internationellt spännande register, vilka utgör världsunika instrument för säkring och utveckling av vårdens kvalitet, är en utveckling som måste beskrivas som häpnadsväckande. Denna framgång har dock inte kommit utan invändningar. Insamlingen av uppgifter för kvalitetsändamål är i allt väsentligt fråga om en tilläggsdokumentation som måste göras utöver den dokumentation som redan görs i journal. Målet att integrera dokumentationen för journal och kvalitetsanvändning genom tekniska system har därför under så lång tid varit så eftersträvat att det närmast är iögonfallande att resultatet utfallit så magert som det har. Det finns enskilda integrationer mellan vissa register och enskilda system, men dessa har inte kunnat generaliseras och de samordnade initiativ som tagits har funnit hinder i konflikten mellan kvalitetsregistren krav på struktur och journalens behov av generalitet samt snårigheten i vårdens informatiska terräng. Problemställning Utöver Beslutsgruppens inflytande vid tilldelning av medel finns i praktiken ingen central förvaltning för registrens innehåll eller funktion. Det är en styrka i så måtto att det ger registerhållaren, som har den kliniska kompetensen att utveckla registret, stor frihet då de arbetar med att utforma innehållet. Baksidan av det myntet är givetvis att det innebär att man bygger upp en helt ortogonal organisation som har styrande inverkan på dokumentationsrutiner i vårdens verksamhet. Detta inflytande har man, utan att på något sätt, vara del av den organisation som upphandlar och kravställer de dokumentationsverktyg som används i vården. Resultatet, är att befintliga dokumentationssystem i allt väsentligt saknar arbetsverktyg för att stödja personales arbete med rapportering till registren. Häri ligger den stora svårighet som medfört att integrationer mellan journalsystem visat sig svåra att utveckla, annat än med högst specifika mål och mellan enskillda system. Kvalitetsregistren har mycket precisa krav på inrapporterad data emedan den primärt ska användas kvantitativt. Dessa data ska samlas in från system som huvudsakligen byggts för dokumentation människor emellan och som därtill vårdar en och samma patient. Omvänt har utvecklare av journalsystem rimligen inte möjliget att utveckla sina system utifrån mer än en kravorganisation. Man kan inte samtidigt svara mot en köpare och ett, numera ganska stort, antal andra intressenter som har konkreta krav på hur just deras dokumentationsrutin ska utformas. Än svårare ter sig frågan om man även betänker in den förvaltningssituation som uppstår i och med att registren normalt uppdaterar sitt innehåll ungefär årsvis. 3

5 Lösningsförslag Strukturerade och utifrån definitionen korrekt data är ett ofrånkomligt krav från kvalitetsregistren. En lösning som inte garanterar att man får in korrekta uppgifter utifrån vad man försöker mäta, är en lösning som omintetgör kvalitetsregistrets uppgift. En lösning måste därför fortsatt medge att registret förfogar över möjligheten att kravställa innehållet i inrapporterade uppgifter (och i förlängningen till del vilken information användaren möter när denne rapporterar till registret) Däremot finns inget som motsätter att man utvecklar en gemensam infrastruktur, ett gemensamt API, för den tekniska interaktionen med registret. Om man kan utforma en arkitektur sådan att samtliga kvalitetsregister uppträder enligt samma mönster så kan systemleverantörer för dokumentationsverktygen utveckla en lösning för att kommunicera med samtliga register. Uppnår man detta finns möjlighet att lägga energin på att utforma lösningen för att fånga rätt kliniskt innehåll. En förutsättning är att lösningen ska följa avsikter och intentioner i Nationell Arkitektur i form av RIVmodellen och främst då följa dess tekniska anvisningar 2. Målet är att tjänsterna ska finnas tillgängliga på Nationell TjänstePlattform och då är detta givetvis ett ofrånkomligt krav. Givet att projektet stödjs av NPDi är det även därför ett självklart beslut. RIV-TA innehåller i första hand anvisningar om hur tjänster ska utformas dels utifrån syftet att samordna mönster och principer samt dels att tillämpa best-practice i syfte att garantera interoperabilitet mellan olika plattformar. Att lösningen sedan ska följa lagar och förordningar är givetvis en självklarhet. Givet dessa ramar har vi möjlighet att utforma lösningar som passar för att uppnå de prioriterade mål vi observerat. Målet formuleras som att genom tjänster skapa en infrastruktur för att transportera ett strukturerat innehåll vars utformning förvaltas av berörda kliniska expertgrupper. Interaktionsmönster Kvalitetsregister är först och främst register. De används för kvalitetsuppföljning, men i fråga om funktionssätt är termen register den relevanta egenskapen. Register är i tekniska termer en form av ett datalager, eller en databas om man så vill. Den mest etablerade synen på interaktionen med ett datalager formulerades redan 1983 av James Martin och brukar beskrivas med akronymet CRUD 3. CRUD står för Create, Retrive, Update och Delete och är de basala operationer man använder mot ett register. Det finns alternativ där man abstraherar bort skillnaden mellan Create, Update och Delete, men för transaktionssäkra system med flera samtidiga klienter är CRUD en vedertagen princip. Intressant nog finns stora likheter med hur PatientdataLagen beskriver interaktionen i de delar där man medges direktåtkomst till egna uppgifter, alltså uppgifter man själv skapat

6 Vi föreslår en arkitektur där CRUD är interaktionsprincipen och där objektet för operationerna är en registrering i registret. I praktiken kan man jämföra en registrering med vad som finns i ett formulär, oavsett om man nu tänker på papper eller webbformulär, och det är normalt så man interagerar med registret, när man trycker på formulärets spara -knapp (eller sänder in papperet). Tillståndshantering och ID Det är i den tekniska interaktionen ordnat så att registret kvitterar transaktionen genom att returnera en identifierare för själva instansen vid ett (lyckat)create-anrop. Denna identifierare förväntas vara universellt unik för registret och ska sedan kunna användas som referens vid de övriga operationerna. Det finns ingen begränsning i hur mycket en registrering hämtas eller uppdateras men en registrering för vilket man genomfört ett delete-anrop ska det normalt inte gå att anropa vare sig update, get eller delete igen. Explicit utformade felkoder kommer att användas för att meddela såväl lyckade som misslyckade operationer. Detta för att underlätta tillståndshanteringen mellan konsumenter och producenter av tjänsten. Sökningar CRUD brukar i allmänhet även utökas med ett sökgränssnitt (vilket då kallas SCRUD). I nuläget finns inte någon tydlig kravbild för hur en sådan söktjänst skulle byggas upp. En söktjänst förutsätter en relativt etablerad modell för sökbegreppen och därtill ett formulerat sätt att hantera nödvändig predikatlogik över sökbegreppen. Ett system, eller en syntax för logiska relationer är legio att formulera, men registren är alltför diversifierade för att i nuläget peka ut användbara sökbegrepp. Detta i kombination med att ingen egentligen undersökt hur sökningar skulle användas av klientsystem, som exempelvis journaler, gör att en implementation av sökningar skjuts till en senare version. Processer CRUD beskriver operationerna för ett formulär, men ett register kan givetvis dela upp sitt kliniska innehåll i flertalet registreringar vilka riktas mot olika delar av den totala vårdprocessen. Oftast finns en tidsfaktor inblandad. Man vill normalt samla in data så snart den är redo att rapporteras, vilket gör det opraktiskt att vänta tills man vet allt om innehåll och utfall av vårdprocesser som kan sträcka sig över lång tid. En insats kan pågå över tid eller följas upp flera år efter att en den genomförts i syfte att undersöka långtidseffekter av insatsen. Typiskt har ett register två eller tre registreringsformulär som ingångsparametrar (inskrivningsuppgifter och liknande), uppgifter om den utföra insatsen (vård eller insatsregistrering) samt en eller flera uppföljningar som görs efter en tid för att se utfallet av vården. Väsentligt mycket mer komplexa scenarier finns där multipla problem ska hanteras i ett flöde med flera aktörer men de utgör en klar minoritet. 5

7 Det finns i dagsläget ingen enhetligt definierad modell för hur processer modelleras och uttrycks i kvalitetsregister. Vanligast är att man ser de insatser som kopplas till ett visst hälsoärende för en patient som en process och det blir normalt utifrån patienten och eventuell tidsfaktor som man identifierar vad som tillhör en process. I dagens register med utvecklade användargränssnitt finns normalt ett visst stöd för att följa och arbeta med vårdproceser för en viss patient men förutsättningarna ändras dramatiskt om man tänker sig ett scenario där alla uppgifter samlas in ifrån journalen. Därtill stoppar Patientdatalagen effektivt alla möjligheter att bygga explorativa tjänstegränssnitt där man kan söka efter tidigare kända insatser för en patient annat än inom den egna vårdgivarens egna uppgifter. Utifrån givna förutsättningar finns därför inga meta-tjänster föreslagna i nuvarande skede. Det kommer säkerligen att utvecklas intressen och möjligheter för ytterligare tjänster gentemot kvalitetsregister, men sub-domänen reporting inskränks åtminstone i sin första version till de basala CRUD-operationerna. Det medför att tillståndsinformation i relation till processen hanteras genom information som bifogas registreringsoperationerna. I registrets tjänstebeskrivning förväntas dokumentation förklara hur processen uttrycks i termer av registreringar och hur dessa relaterar till varandra. Specifika meddelanden som returneras i kommunikationen kan indikera såväl allmän information såsom specifik felinformation. Exempel på processrelaterad felinformation kan ske då någon exempelvis försöker registrera någon typ av uppföljningsregistrering för en patient som inte har någon registrad vårdprocess, är avliden, eller där tidsserier är omöjliga. Specifika felkoder uttrycker klassen av fel och detaljerad information ska ges av registrets tjänst i returmeddelandet (mer om detta nedan under ErrorInformationType) Kontrakt Lösningsförslaget innebär att man skiljer ut det kliniska innehåll, som registerhållaren ska förfoga kontroll över, från det strukturerade innehåll som behövs för att säkert transportera rätt uppgifter till rätt system. Samtidigt läggs en odefinierad datamängd i meddelandet vilket innehåller kvalitetsregistrets efterfrågade uppgifter. Lite tillspetsat kan man se det som att tjänsteplattformen med dess tjänsteorienterade överbyggnad används som ett transportlager för ett datainnehåll det inte behöver veta något om. Likväl är poängen med tjänsteorienterad arkitektur och kontraktsbaserade tjänster att man ska strukturera kommunikationen så hårt att man kan skapa typsäkerhet redan utifrån gränssnittets definitioner. Det är alltså ett krav på arkitekturen från RIV, att tjänster ska exponeras kontraktsbaserat. Att binda tjänstegränssnitten till förvaltade kontrakt enligt RIV-TA och som definierar dataelement ner till lägsta nivå skulle även medföra en orimligt stor förvaltningsapparat då registren vidareutvecklar sitt kliniska innehåll. Att ett hundratal register går igenom hela processen 6

8 för att publicera nya versioner enligt RIV-TA är med nuvarande bemanning helt enkelt inte möjligt och även om den kan anpassas så är kravet på ledtider väl kort från registrens sida. Som alternativ mellanväg föreslår vi en bindning av typer i runtime som backas av ett system där registrens typer publiceras och versionshanteras vid sidan av tjänsten. Likt för övriga tjänstedomäner kommer det att finnas domänövergripande typer och kodverk som definieras på den gemensamma nivån i tjänstedomänen. Till skillnad från en vanlig tjänstedomän i RIV-TA så kommer det att finnas en uppsättning scheman som är organiserade som subdomäner för varje register men som innehåller scheman för typer som inte refereras direkt ifrån WSDL:ens responderobjekt. Respondern innehåller istället en kombination av två element där det första är av typen AnyURI och som ska innehålla en valid referens till det schema som används för att formatera meddelandet. Det andra elementet är en sträng som av tekniska skäl formateras om på talbasen 64 (base64), och som innehåller registreringen formaterad utifrån angivet schema. Det finns alltså dokumenterade och tekniskt strukturerade specifikationer för alla datatyper som ska kunna användas, skillnaden är bara att valet av datastruktur för innehållet görs i det ögonblick man anropar tjänsten. För såväl konsumenter som producenter blir det en hantering i två steg där man i ena steget hanterar data och metadata för själva överföringen och i ett annat steg paketerar det kliniska innehållet. Med denna princip blir det helt möjligt för registren att versionshantera sitt kontraktsinnehåll helt oberoende av den yttre tjänstens utformning. Att lägga till ett nytt formulär eller en ny version av ett befintligt är helt enkelt en fråga om att publicera ett xml-schema för transportstrukturen och implementera tjänsten för att hantera den nya strukturen. Detta innebär även att det i praktiken blir en tjänst med fyra gemensamma ändpunkter som kan användas för att nå samtliga register. Samma tjänst hos NTjP används för att nå samtliga kvalitetsregister rapporteringstjänster. För att understödja adresseringen i tjänsteplattformen kommer elementet logical address i soap-headern att användas för att tjänsteplattformen ska kunna adressera förfrågningar till den implementerande tjänsteproducenten. Dessa kommer att uttryckas som tjänstens HSA-id. Metadata Emedan soap-headern redan har definierats av tjänsteplattformen i RIV-TA, innebär det att det kommer att finnas en struktur i body-elementet som definierar meta-information, alltså en typisk header fast den skickas som en del av själva meddelandet. Utformningen av innehållet i metadata har baserats i utgångspunkten att den ska på första nivå innehålla allt som man behöver veta för att avgöra om det aktuellt att hantera själva registreringen. Detta för att kunna processa requests så effektivt som möjligt. I realiteten rör det sig om uppgifter för tre ändamål. För det första säkerhet och spårbarhet, det vill säga uppgifter avsändaren som används för åtkomstkontroll och loggning. För det andra uppgifter som behövs för att säkerställa att rätt schema används för den aktuella typen och versionen av 7

9 registrering. För det tredje en del uppgifter som är nödvändiga för att implementera CRUD arkitekturen. För att exemplifiera beskrivs de översta nivåerna i responder-objekten för ett create-anrop. De övriga operationerna har motsvarande innehåll definierat i specifika respondrar fast givetvis utifrån vilken metadata de behöver. Ett create-anrop syftar till att skapa en initial instans av en registrering och det responderobjekt som definierar anropet har följande definition <xs:complextype name='createregistrationtype'> <xs:sequence> <xs:element name="careunit" type="xs:hsaidtype" minoccurs="1" maxoccurs="1"/> <xs:element name="legalauthenticator" type="xs:hsaidtype" minoccurs="1" maxoccurs="1"/> <xs:element name="subjectofcare" type="xs:hsaidtype" minoccurs="1" maxoccurs="1"/> <xs:element name="dateofcare" type="tns:datetype" minoccurs="1" maxoccurs="1"/> <xs:element name="registration" type="tns:registrationtype"/> <xs:any namespace='##other' processcontents='lax' minoccurs='0' maxoccurs='unbounded' /> </xs:sequence> </xs:complextype> Det är som synes en förhållandevis liten uppsättning metadata. Följande stycken förklarar elementens syfte lite närmare. CareUnit CareUnit är den vårdenhet som rapporterar in registreringen. Idealt ska vi kunna identifiera alla vårdenheter utifrån HSA-id, men det är ännu inte säkerställt att i dagsläget fungerar för alla kvalitetsregister. Det kan därmed vara aktuellt att under en övergångstid generalisera identifieraren så att helt arbiträra identifierare kan överenskommas mellan tjänsteproducenter och konsumenter. CareUnit används dels för att associera uppgifterna med rätt organisation (vårdgivare) och är den primära ägaren av uppgiften och tillgång till uppgiften delas för alla som har behörighet att åtkomma registret med medarbetaruppdrag för vårdenheten i fråga. CareUnit blir även löv i registrets organisationsträd och den finaste granularitet med vilken man kan gruppera uppföljningen av vården. Om ett visst register har behov av att ytterligare förfina organisationsträdet är det möjligt genom att införa registerspecifika organisatoriska begrepp såsom avdelning i själva registreringen. Detta motsäger principen som delar upp metadata från annan, men i syfte att inte komplicera det generella kontraktet hanteras attribut som inte är helt gemensamma i den mer anpassade payloaden. LegalAuthenticator LegalAuthenticator är den person hos konsumerande system som utpekas som ansvarig för registreringen såväl ifråga om beslutet att överföra uppgiften till registret som dess faktiska innehåll. Det ska inte likställas med signering emedan det har en annan specifik betydelse, men det har 8

10 effektivt en liknande effekt. Det är det användar ID här som skrivs i loggar och som kommer att följas upp vid förekommande behov eller rutin. Värt att notera i denna lösning är att integrationens säkerhetlösning bygger på ett förtroende maskiner emellan. LegalAuthenticator är inte liktydigt med användare emedan det inte är strikt sätt nödvändigt att den person som initierar överföringen av en uppgift också är en användare av registret. Historiskt var det självklart så emedan användaren var tvungen att kunna logga in i webbsystemet för att kunna registrera. Med maskin till maskin certifikat delegeras ansvaret att åtkomstreglera funktionen som konsumerar tjänsterna till det integrerande systemet. Registret kan inte annat än lita på att uppgiften stämmer och det är verksamhetsansvarigs ansvar att klientsystemen fungerar enligt tänkta principer. Det är givetvis möjligt att ett visst register förbehåller sig rätten att själv hålla en katalog för åtkomstreglering. Detta kan betingas av exempelvis krav på specifik utbildning eller liknande. Om sådana restriktioner framgår ska dessa dokumenteras i registrets egna SAD samt i annan lämplig dokumentation. SubjectOfCare SubjectOfCare är identifierare för patienten (eller subjektet) som vårdats. Typen är konstruerad för att hantera svenska personnummer, samordningsnummer, reservnummer eller arbiträra pseudonymer vilket möjliggör utformningen av helt pseudonymiserade register där endast vårdgivaren själv känner till kopplingen till person. SubjectOfCare är strikt sett ett element som möjligen skulle kunna överföras i själva registreringen men dels är det ett element som finns i stort sett överallt och dels finns i flera fall processrelaterade regler som knyts till patienten varför det kan vara en processmässig fördel att uttrycka den explicit. DateOfCare DateOfCare uttrycker datum för vårdkontakten i fråga om öppenvård alternativt inskrivningsdatum i slutenvård. Detta attribut är i första hand till för att bestämma version för registreringsinnehållet. I praktiken styr denna uppgift vilken version av registreringens xsd som är tillämplig och information om såväl versionsstyrande datum som kopplingen till specifika versioner, skall tillhandahållas av registret. Registren är i allmänhet versionshanterade utifrån vårdens tider snarare än rapporteringstidpunkt. Rapporteringen kan i vården ofta göras i efterhand men eftersom statistiska sammanställningar oftast organiseras utifrån tiden då vården utfördes, måste det vara möjligt att efterregistrera vårdhändelser utan att det innebär att man får rapportera utifrån ändrade definitioner. 9

11 Det återstår ännu att säkerställa valet av denna term då det kan tänkas vara missvisande i vissa fall. En granskning kommer att göras av samtliga begrepp och denna är förhållandevis svår. Det finns inte något bra ord för det datum som styr versioner av registeringsdefinitioner i registret och oftast rör det sig om just vårdkontakttidpunkt, men inte alltid. Registering Requestobjektet ovan innehåller även ett objekt kallat Registration av typen RegistrationType. Det är en typ som är utvecklad för att innehålla det strukturerade men i förväg inte typsatta element som innehåller själva registeringen. Typen är definierad enligt följande: <xs:complextype name="registrationtype" > <xs:annotation> <xs:documentation> / / </xs:documentation> </xs:annotation> <xs:simplecontent> <xs:extension base="xs:base64binary"> <xs:attribute name="schemalocation" type="xs:anyuri" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> Det rör sig i praktiken om en slags wrapper för en base64 kodad sträng som även försetts med ett attribut som pekar ut var man kan hitta schemat som strängen formaterats från. Tjänstekonsumenten får således utifrån dokumenterade anvisningar skapa sitt dataobjekt baserad på ett schema som registret publicerar. Resultatet av det kodas om på talbasen 64, vilket det finns stöd för i alla relevanta programmeringsramverk/miljöer, och läggs in i det objekt som genererats av det webbserviceramverk man använder för att nå tjänsten. I och med att tjänstekontraktet inte pekar ut det specifika schemat har registeringstypen ett obligatoriskt attribut som ska innehålla en aktiv referens till schemat. Man hade givetvis kunnat nöja sig med ett logiskt namn men då registern förväntas publicera sina scheman kan man lika gärna använda de skarpa referenserna. Det minskar risken för sammanblandning i och med att en URI är universellt unik. Registret får själv avgöra i vilken utsträckning det önskar validera att utpekat schema stämmer mot den tänkta versionen av den tänkta registreringen. Scheman publiceras i versionerade namnrymder precis enligt anvisningar från RIV-TA, men det blir en samvetssak att faktiskt välja det schema som registret önskar. Tjänstekontraktet kommer inte att kunna ifrågasätta valet av schema och det är rekommenderat att registret säkerställer att det följer vad som förväntas. Här lämnas öppet för en strategi för versionshantering som är väldigt öppen för registren. Det ska de kunna utnyttja, men det måste givetvis beskrivas i detalj i SAD:ar och användardokumentation. 10

12 Utformning av kliniskt innehåll I och med att det kliniska innehållet skickas som en komprimerad sträng så kan innehållet egentligen formateras efter vilken standard som helst. Det enda kravet som ställs är att det finns en schemaspecifikation publikt tillgänglig. Hur schemat byggs upp är registrets sak att avgöra och teoretiskt kan de även använda andra tekniker för representation som exempelvis YAML 4, JSON 5 eller vanliga nyckel-värde par. Vi rekommenderar dock att man tar utgångspunkt i RIV-TA och följer de tekniska anvisningar som ges för utformaning av XML-scheman i tjänster i allmänhet och att man följer den strategi för versioner som anges där. Därmed rekommenderar vi att man dels använder XML-scheman för att representera datastrukturen och dels att värdemängder och valalternativ är strikt typade. RIV-TA innehåller även anvisningar för utformning av scheman och givetvis är det rimligt att följa dessa även i utformningen av dessa scheman. Gällande värdelistor så är det något som i högsta grad är vanligt förekommande i registren och mycket av förvaltningen kommer att kretsa kring frågor om svarsalternativ för olika frågor. Konkret finns strategier för att bygga upp en förvaltning av kodverk baserat på unikt identifierade namnrymder. Den teknik som börjat tillämpas inom Nationell Arktiektur inspirearas av initiativet GrenCDA 6 som har sitt ursprung i framtagningen av protokoll för HL7. Principen är att varje schema ges en unik namnrymd som är reserverad för den specifika applikationen. Under den kan man inom domänen definiera undergrupperingar och till sist identifierare för både begrepp och kodverk. Varje unikt begrepp eller kodverk identifieras av en objektidentifierare och en definieras genom en enkel typ (xs:simpletype). Dessa komponeras sedan genom att man skapar en komplex typ, som har den simpla typens värdemängd och en fixerad referens som obligatoriska attribut. På så sätt skapas ett för XML jämförelsevis lättviktigt protokoll där minimalt med komplexa typer med element används och eftersom referenserna pekar ut värderymden och kodvärdena är resultatet lika rikt på information som en fullständig schemarepresentation. Man har bara tagit bort den strukturella overhead som xml-tekniken normalt skapar i transportens representation

13 Responderobjektet Som svar på ett request returneras ett responseobjekt. Responderobjetet innehåller en datastruktur som ger information om transaktionens utfall samt antingen data och metadata från CRUD operationen eller ett felinformationsobjekt som innehåller en lista av uppkomna fel. Objektet definieras enligt nedan: <xs:complextype name='createregistrationresponsetype'> <xs:sequence> <xs:element name='resultcode' type='reporting:resultcodeenum' /> <xs:choice minoccurs="1" maxoccurs="1"> <xs:element name="createdresourceinformation" type="tns:createdregistrationinformationtype" maxoccurs="1"/> <xs:element name="errorinformation" type="reporting:errorinformationtype" maxoccurs="unbounded" /> </xs:choice> <xs:any namespace='##other' processcontents='lax' minoccurs='0' maxoccurs='unbounded' /> </xs:sequence> </xs:complextype> Det svar som returneras innehåller en information kallad ResultCode. Denna kommer från ramverken kring RIV-TA och är identisk med övriga tjänster på NTjP så när som på att vi valt att inte använda statuskoden INFO emedan den har tveksamt värde ur ett transaktivt perspektiv. Det primära intresset för svaret är att signalera hur tillståndet har förändrats och CRUD arkitekturen förutsätter att en operation antingen är lyckad (resultatkod OK ) eller misslyckad (resultatkod ERROR ). ResultCode är alltså ur ett transaktionsperspektiv en flagga som indikerar operationens resultat. Beroende på resultatkodens utfall finns antingen en CreatedRegistrationInformation eller en ErrorInformation. Dessa är i sin tur komplexa typer som anpassats för att returnera relevant information. CreatedRegistrationInformationType är bifogad där resultatet av anropet är avklarat alltså där resultcode är OK och är definierad enligt följande: <xs:complextype name="createdregistrationinformationtype"> <xs:sequence> <xs:element name="registrationid" type="xs:string" minoccurs="1" maxoccurs="1" /> <xs:element name="version" fixed="1" minoccurs="1" maxoccurs="1"/> <xs:element name="status" type="reporting:registrationstatetype" minoccurs="1" maxoccurs="1"/> <xs:element name="information" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> <xs:any namespace='##other' processcontents='lax' minoccurs='0' maxoccurs='unbounded' /> </xs:sequence> </xs:complextype> 12

RIV TA Domänschema 2.1

RIV TA Domänschema 2.1 1 (9) Center för ehälsa i samverkan Hornsgatan 20, 118 82 Stockholm Vxl: 08-452 70 00 ARK_0006 CeHis AR www.cehis.se info@cehis.se RIV TA Domänschema 2.1 Utgåva C 2013-06-19 Center för ehälsa i samverkan

Läs mer

Sammanfattning och specifikationer för POT

Sammanfattning och specifikationer för POT 0.2 Sammanfattning och specifikationer för POT Kornhamnstorg 61 SE-111 27 Stockholm Sweden 00 00 Telefon: +46 (0)8 791 92 Telefax: +46 (0)8 791 95 www.certezza.net Innehållsförteckning 1 SAMMANFATTNING...

Läs mer

Staffan Winter. NATIONELLA PROGRAMMET FÖR DATAINSAMLING, NPDi

Staffan Winter. NATIONELLA PROGRAMMET FÖR DATAINSAMLING, NPDi Staffan Winter NATIONELLA PROGRAMMET FÖR DATAINSAMLING, NPDi PROGRAMMETS MÅL Att få bort dubbelregisteringen i vården i samband med datainsamling till kvalitetsregister. FUNDAMENT Strategi med huvudfokus

Läs mer

Hantering av tillitsnivåer

Hantering av tillitsnivåer Hantering av tillitsnivåer Version 1.2 Innehåll Hantering av tillitsnivåer för Skolfederation... 1 1 Inledning... 2 2 Tillitsnivåer... 2 3 Profiler och referenser... 2 3.1 Förtydligande gällande deploymentprofil...

Läs mer

Fi2xml-meddelande Arkitektur

Fi2xml-meddelande Arkitektur Innehåll 4 Inledning 2 4.1 Process certifiering 2 4.1.1 Projektdefinition 3 4.1.2 Konstruktion 3 4.1.3 Godkännande och certifiering 4 4.1.4 Publicering 4 4.2 Scenarier 4 4.2.1 Behov av integrationer mellan

Läs mer

Sammanhållen vaccinationsinformation. Vitalis 10 april 2014 Lars Midbøe, projektledare SKL Marcus Claus, delprojektledare, Mawell

Sammanhållen vaccinationsinformation. Vitalis 10 april 2014 Lars Midbøe, projektledare SKL Marcus Claus, delprojektledare, Mawell Sammanhållen vaccinationsinformation Vitalis 10 april 2014 Lars Midbøe, projektledare SKL Marcus Claus, delprojektledare, Mawell Projektet Sammanhållen Vaccinationsinformation Uppdrag från Sveriges Kommuner

Läs mer

Arkitekturella beslut Infektionsverktyget. Beslut som påverkar arkitekturens utformning

Arkitekturella beslut Infektionsverktyget. Beslut som påverkar arkitekturens utformning Arkitekturella beslut Beslut som påverkar arkitekturens utformning Arkitekturella beslut Innehåll 1. Inledning... 3 1.1 Syfte... 3 1.2 Definitioner, Akronymer och Förkortningar... 3 1.3 Referenser... 3

Läs mer

Nationell Tjänsteplattform och säkerhetsarkitektur. Per Brantberg, område arkitektur/infrastruktur

Nationell Tjänsteplattform och säkerhetsarkitektur. Per Brantberg, område arkitektur/infrastruktur Nationell Tjänsteplattform och säkerhetsarkitektur Per Brantberg, område arkitektur/infrastruktur Nationell e-hälsa är vårt uppdrag Uppgiften är att skapa en väl fungerande informationsförsörjning inom

Läs mer

Innehåll. Nationell IT-strategi och målbild Nationell infrastruktur Nationell Patient Översikt - NPÖ

Innehåll. Nationell IT-strategi och målbild Nationell infrastruktur Nationell Patient Översikt - NPÖ Innehåll Nationell IT-strategi och målbild Nationell infrastruktur Nationell Patient Översikt - NPÖ Information som ska användas i NPÖ Produktval NPÖ Tidplaner och aktiviteter för NPÖ Jan Edquist IT-arkitekt

Läs mer

Apotekens Service. federationsmodell

Apotekens Service. federationsmodell Apotekens Service Federationsmodell Detta dokument beskriver hur Apotekens Service samverkar inom identitetsfederationer Datum: 2011-12-12 Version: Författare: Stefan Larsson Senast ändrad: Dokumentnamn:

Läs mer

Agenda arkitektur - vägvalsfrågor

Agenda arkitektur - vägvalsfrågor Agenda arkitektur - vägvalsfrågor Tjänstekontrakt förutsättningar för återanvändning Gemensam kravhantering Generella versus diagnos-specifika kontrakt nuläge, utmaning och målbild? För vilka syften kan

Läs mer

GATEWAY TJÄNSTEBESKRIVNING. Webbservice. WSDL-fil. Skicka meddelanden. SMS och FastnätsSMS

GATEWAY TJÄNSTEBESKRIVNING. Webbservice. WSDL-fil. Skicka meddelanden. SMS och FastnätsSMS GATEWAY TJÄNSTEBESKRIVNING Tjänsten Messit Gateway består av ett gränssnitt som enkelt kan implementeras i en egen applikation. Det enda som krävs för att använda Messit Gateway är att applikationen som

Läs mer

Beslutsunderlag. Rekommendation för beslut om lösning för hantering av invånarens tidbokning gällande mottagningar som använder flera tidböcker

Beslutsunderlag. Rekommendation för beslut om lösning för hantering av invånarens tidbokning gällande mottagningar som använder flera tidböcker Beslutsunderlag Rekommendation för beslut om lösning för hantering av invånarens tidbokning gällande mottagningar som använder flera tidböcker 1. Bakgrund och problemställning... 2 2. Rekommendation...

Läs mer

Anvisning för Svensk Livfaktura

Anvisning för Svensk Livfaktura Anvisning för Svensk Livfaktura Bilaga B: Validering av PEPPOL BIS Svefaktura 5A 2.0 Version 1.0 Upphovsrätt Den här anvisningen för Livfaktura BIS 5A 2.0 är baserad på PEPPOL BIS 5A 2.0 som i sin tur

Läs mer

Kvalitetsregister & Integritetsskydd. Patrik Sundström, jurist SKL

Kvalitetsregister & Integritetsskydd. Patrik Sundström, jurist SKL Kvalitetsregister & Integritetsskydd Patrik Sundström, jurist SKL Varför finns det ett regelverk för nationella kvalitetsregister? - Många känsliga uppgifter - Om många människors hälsa - Samlade på ett

Läs mer

Instruktion för att kunna använda Säkerhetstjänsternas administrationsgränssnitt

Instruktion för att kunna använda Säkerhetstjänsternas administrationsgränssnitt Instruktion för att kunna använda Säkerhetstjänsternas administrationsgränssnitt Innehållsförteckning 1. Inledning... 3 2. SITHS kort... 4 3. Förutsättningar för åtkomst till Säkerhetstjänsten... 4 4.

Läs mer

Gör er redo för NPÖ 2.0 och Journalen på Nätet! - med Tietos anslutningstjänst

Gör er redo för NPÖ 2.0 och Journalen på Nätet! - med Tietos anslutningstjänst Gör er redo för NPÖ 2.0 och Journalen på Nätet! - med Tietos anslutningstjänst VÄLKOMNA - Ola Bergkvist - Jon Durefelt 2015-04-28 Agenda 1. Det här är anslutningstjänsten 2. NPÖ 1.0 => NPÖ 2.0 Anpassning

Läs mer

Kvalitetsregisterdag 2009-04-22

Kvalitetsregisterdag 2009-04-22 Kvalitetsregisterdag 2009-04-22 Patientdatalagen och kvalitetsregister Camilla Ziegler Enheten för juridik Region Skåne 1 Nationella och regionala kvalitetsregister Syfte Inrättats för ändamålet att systematiskt

Läs mer

Tekniskt ramverk för Svensk e- legitimation

Tekniskt ramverk för Svensk e- legitimation Tekniskt ramverk för Svensk e- legitimation ELN-0600-v1.4 Version: 1.4 2015-08-14 1 (10) 1 INTRODUKTION 3 1.1 IDENTITETSFEDERATIONER FÖR SVENSK E- LEGITIMATION 3 1.2 TILLITSRAMVERK OCH SÄKERHETSNIVÅER

Läs mer

Guide för Innehållsleverantörer

Guide för Innehållsleverantörer Library of Labs Content Provider s Guide Guide för Innehållsleverantörer Inom LiLa ramverket är innehållsleverantörer ansvariga för att skapa experiment som "LiLa Learning Objects", att ladda upp dessa

Läs mer

Preliminär projektdefinition Bygglovsleveranser 2010-04-09/bj

Preliminär projektdefinition Bygglovsleveranser 2010-04-09/bj INNEHÅLLSFÖRTECKNING 1. BAKGRUND... 2 2. SYFTE... 2 3. MÅL... 3 4. OMFATTNING OCH RESULTAT... 4 5. KOPPLINGAR TILL OCH BEROENDEN AV ANDRA PROJEKT... 5 6. PLAN FÖR GENOMFÖRANDE... 6 Sida 1 1. BAKGRUND Denna

Läs mer

RIV TA Basic Profile 2.1 RIV Tekniska Anvisningar

RIV TA Basic Profile 2.1 RIV Tekniska Anvisningar RIV 2.1 Anvisningar Bilaga 5.1 CeHis Arkitekturledning Sida: 1 (11) RIV TA Basic Profile 2.1 Utgåva B 2012-01-03 RIV 2.1 Anvisningar Bilaga 5.1 CeHis Arkitekturledning Sida: 2 (11) Utgåva PA1 Utgåvehistorik

Läs mer

Tillämpningsanvisningar för tillgång till och utlämnande av patientinformation

Tillämpningsanvisningar för tillgång till och utlämnande av patientinformation Sid 1(5) Tillämpningsanvisningar för tillgång till och utlämnande av patientinformation Inledning Hantering av patientinformation inom Region Skåne ska ske utifrån patientdatalagen (SFS 2008:355), Socialstyrelsens

Läs mer

Teknisk guide för brevlådeoperatörer. Annika Melin 2015-03-10 Version: 1.1

Teknisk guide för brevlådeoperatörer. Annika Melin 2015-03-10 Version: 1.1 Teknisk guide för brevlådeoperatörer Annika Melin 2015-03-10 Sida 1 av 21 Innehållsförteckning Inledning... 2 1 Dokumentinformation... 3 Syfte... 3 1.2 Avgränsningar... 3 1.3 Målgrupp... 3 1.4 Begrepp

Läs mer

Frågor och svar om nationella vaccinationsregistret

Frågor och svar om nationella vaccinationsregistret Frågor och svar om nationella vaccinationsregistret Allmänt Vad är vaccinationsregistret? Vaccinationsregistret är ett hälsodataregister för nationella vaccinationsprogram. Folkhälsomyndigheten är ansvarig

Läs mer

LEFI Online, system till system (Leverera Förmånsinformation) WEBBSERVICE/SHS/SSEK

LEFI Online, system till system (Leverera Förmånsinformation) WEBBSERVICE/SHS/SSEK LEFI Online, system till system (Leverera Förmånsinformation) WEBBSERVICE/SHS/SSEK Gränssnittsspecifikation Försäkringskassan IT 1 (11) Ändringsförteckning Nedanstående tabell redovisar ändringshistoriken

Läs mer

RIV TA Konfigurationsstyrning 1.0 RIV Tekniska Anvisningar

RIV TA Konfigurationsstyrning 1.0 RIV Tekniska Anvisningar Konfigurationsstyrning CeHis Arkitekturledning Sida: 1 (16) RIV TA Konfigurationsstyrning RIV Tekniska Anvisningar 2012-01-03 Konfigurationsstyrning CeHis Arkitekturledning Sida: 2 (16) Utgåva Utgåvehistorik

Läs mer

Uppgiftskravstjänsten Beskrivning av XML-schema för uppgiftskrav som öppna data. Version 2.0

Uppgiftskravstjänsten Beskrivning av XML-schema för uppgiftskrav som öppna data. Version 2.0 Uppgiftskravstjänsten Beskrivning av XML-schema för uppgiftskrav som öppna data Version 2.0 1 Innehållsförteckning 1 Inledning... 3 2 XML-schema... 3 2.1 Element för paketering av uppgiftskrav... 3 2.1.1

Läs mer

Informationsförsörjning för värdebaserade uppföljnings- och ersättningssystem

Informationsförsörjning för värdebaserade uppföljnings- och ersättningssystem Informationsförsörjning för värdebaserade uppföljnings- och ersättningssystem Värdebaserad vård är en strategi för sjukvårdens styrning och arbetssätt som syftar till att åstadkomma så friska patienter

Läs mer

Hur skyddas patientens integritet? Vad säger lagar och författningar och hur fungerar det?

Hur skyddas patientens integritet? Vad säger lagar och författningar och hur fungerar det? Hur skyddas patientens integritet? Vad säger lagar och författningar och hur fungerar det? ewa.jerilgard@cehis.se Dagens nyheter vintern 2012 Drygt 200 vårdenheter allt från sjukhus till vårdcentraler

Läs mer

Bilaga 2. Säkerhetslösning för Mina intyg

Bilaga 2. Säkerhetslösning för Mina intyg Bilaga 2. Säkerhetslösning för Mina intyg Sid 1/17 Innehåll 1. Sammanfattning... 2 2. Inledning... 3 3. Introduktion... 4 4. Säkerhetslösning för Mina intyg... 5 5. Krav på andra lösningar och aktörer...

Läs mer

Förvaltningsplan för Elektronisk remiss 2014

Förvaltningsplan för Elektronisk remiss 2014 Förvaltningsplan för Elektronisk remiss 2014 FÖRVALTNINGSPLAN Förvaltningsobjekt Elektronisk remiss Utförare Inera AB Tjänsteansvarig Uppdragstagare Bilagor Erica Määttä Lindblad Johan Assarsson Sid 1/8

Läs mer

Rutin för loggning av HSL-journaler samt NPÖ

Rutin för loggning av HSL-journaler samt NPÖ Rutin för loggning av HSL-journaler samt NPÖ Enligt patientdatalagen 4 kap 3,skall vårdgivare göra systematiska och återkommande kontroller av om någon obehörigen kommer åt sådana uppgifter om patienter

Läs mer

IT-stöd för strukturerad dokumentation vid bipolär sjukdom

IT-stöd för strukturerad dokumentation vid bipolär sjukdom Norra Stockholms psykiatri, Affektivt centrum Projektansvarig Mikael Landén IT-stöd för strukturerad dokumentation vid bipolär sjukdom Rapport från satsning på psykiatri och socialtjänst för personer med

Läs mer

Verksamhetsstöd ehälsa Innovationssluss

Verksamhetsstöd ehälsa Innovationssluss 1 Mobil e-hälsa ett projekt med syftet att använda Health Innovation plattform (HIP) och Integrationsplattform för vårdgivare (IPV) med TakeCare information i Surfplatta Verksamhetsstöd ehälsa Innovationssluss

Läs mer

SIL SOAP API 4.0. beta prerelease

SIL SOAP API 4.0. beta prerelease SIL SOAP API 4.0 beta prerelease Nyheter och förändringar gentemot SIL SOAP API 3.1 Sid 1/19 Innehållsförteckning 1. Inledning... 4 2. Sammanfattning... 4 3. Tekniska förutsättningar... 5 3.1. Generellt...

Läs mer

Råd gällande beständiga länkar

Råd gällande beständiga länkar UTKAST Råd gällande beständiga länkar Nationellt ramverk för öppna data Peter Krantz AB Innehållsförteckning 1. Nationellt ramverk för öppna data... 2 1.1. Råd gällnade beständiga länkar... 2 1.2. Vem

Läs mer

Nationell patientöversikt en lösning som ökar patientsäkerheten

Nationell patientöversikt en lösning som ökar patientsäkerheten NPÖ-guiden NPÖ Nationell Patientöversikt Nationell patientöversikt en lösning som ökar patientsäkerheten Den här guiden riktar sig till vårdgivare landsting, kommuner och privata vårdgivare som ska eller

Läs mer

Testning av Sambi. Testplan. Version PA12. Fil namn: SAMBI_TP.docx Senast sparad: 2014-11- 24. Copyright (c) 2014 IIS

Testning av Sambi. Testplan. Version PA12. Fil namn: SAMBI_TP.docx Senast sparad: 2014-11- 24. Copyright (c) 2014 IIS Testning av Sambi Testplan Version PA12 Fil namn: SAMBI_TP.docx Senast sparad: 2014-11- 24 Copyright (c) 2014 IIS Dokument kontroll Dokument information och säkerhet Skapad av Faktaansvarig Dokumentansvarig

Läs mer

Nationell Handlingsplan för IT i Vård och Omsorg. Informationsförsörjning för en god patientvård? Hur knyta ihop EPJ och patientöversikten?

Nationell Handlingsplan för IT i Vård och Omsorg. Informationsförsörjning för en god patientvård? Hur knyta ihop EPJ och patientöversikten? Nationell Handlingsplan för IT i Vård och Omsorg Informationsförsörjning för en god patientvård? Hur knyta ihop EPJ och patientöversikten? Hels IT 26 september 2007 Gösta Malmer 1 Disposition Vård och

Läs mer

Tillsyn - äldreomsorg

Tillsyn - äldreomsorg Datum Diarienr 2011-12-07 876-2010 TioHundranämnden Box 801 761 28 Norrtälje Tillsyn - äldreomsorg Datainspektionens beslut Datainspektionen konstaterar att TioHundranämnden i strid med 6 lagen om behandling

Läs mer

E-tjänst över näringsidkare

E-tjänst över näringsidkare E-tjänst över näringsidkare Slutrapport Datum: 2011-01-27 Version: 1.0 Upprättad av: Monica Grahn Innehållsförteckning 1. E-tjänst över näringsidkare noden...1 1.1 Sammanfattning 1 1.2 Bakgrund 1 2. Användningsfall...1

Läs mer

Exempel på verklig kravspecifikation

Exempel på verklig kravspecifikation Exempel på verklig kravspecifikation Detta är ett exempel på en proffessionell kravspecifikation hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och

Läs mer

Checklista. För åtkomst till Svevac

Checklista. För åtkomst till Svevac Checklista För åtkomst till Svevac Innehållsförteckning 1 Inledning 2 2 Inloggning/autentisering i Svevac 2 3 Målet sammanhållen vaccinationsinformation 3 4 Säkerhetstjänsten 3 5 Detta är HSA 3 6 Detta

Läs mer

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell Informationsstruktur 2015:1 Bilaga 7: Arkitektur och metodbeskrivning Innehåll Nationell informationsstruktur arkitektur och metod... 3 Standarder inom informatik... 3 NI relaterat till ISO 42010...

Läs mer

Nya NPÖ. Möte i Göteborg 2014-10-07. Tomas Ahl Inera

Nya NPÖ. Möte i Göteborg 2014-10-07. Tomas Ahl Inera Nya NPÖ Möte i Göteborg 2014-10-07 Tomas Ahl Inera Journal- och läkemedelstjänster Historik (juni 2013-juli 2014) 1/1 1992? ÄDELREFORMEN Tomas Ahl Inera Tomas Ahl Inera Juni 2013.. Min Journal på nätet

Läs mer

Nationell patientöversikt

Nationell patientöversikt Nationell patientöversikt Översikt och Anslutning 2009 Tieto Corporation Christer Bergh Tieto, Healthcare & Welfare christer.bergh@tieto.com Agenda 1. Bakgrund 2. Användarperspektiv och nytta 3. Status

Läs mer

Delrapport DP3. FGS för paketstruktur för e-arkiv Bilaga 1 METS

Delrapport DP3. FGS för paketstruktur för e-arkiv Bilaga 1 METS Delrapport DP3 FGS för paketstruktur för e-arkiv Bilaga 1 METS Karin Bredenberg & Mats Berggren IT/SoU 010-476 71 23 2013-01-14 2.0 1(9) INNEHÅLLSFÖRTECKNING 1. BILAGA 1: METS...3 1.1 INTRODUKTION...3

Läs mer

Anslutning av Elektronisk Katalog EK/HSA, införande etjänstekort et/siths

Anslutning av Elektronisk Katalog EK/HSA, införande etjänstekort et/siths sida 1 Anslutning av Elektronisk Katalog EK/HSA, införande etjänstekort et/siths sida 2 1 Innehåll 2 Bakgrund - EK... 3 2.1 Vad är EK... 3 2.2 Tillämpningar för EK... 4 3 Bakgrund - etjänstekort... 5 3.1

Läs mer

Samtycke vid direktåtkomst till sammanhållen journalföring

Samtycke vid direktåtkomst till sammanhållen journalföring Riktlinjer Samtycke vid direktåtkomst till sammanhållen journalföring Version 3 2014-12-23 Riktlinjerna är upprättade av medicinskt ansvariga sjuksköterskor och medicinskt ansvariga för rehabilitering

Läs mer

Genomförandeplan för nationellt införande av eped

Genomförandeplan för nationellt införande av eped Genomförandeplan för nationellt införande av eped Fas 1 Uppstartsfas med planering och förberedelser 1. Bakgrund Under våren 2014 har en förstudie om Kunskapsstöd för barn vid läkemedelsordination genomförts,

Läs mer

Slutrapport. APFy.me

Slutrapport. APFy.me Slutrapport APFy.me Innehållsförteckning 1 Inledning... 3 2 Mål och syfte... 3 3 Projektbeskrivning... 3 4 Leverabler... 4 5 Resultat... 4 6 Utvärdering och analys... 4 6.1 Utvärdering av resultat... 4

Läs mer

Rutin för kontroll av åtkomst till patientuppgifter-loggranskning av NPÖ, Meddix och verksamhetssystem

Rutin för kontroll av åtkomst till patientuppgifter-loggranskning av NPÖ, Meddix och verksamhetssystem SOCIALFÖRVALTNINGEN Annika Nilsson, 0554-191 56 annika.nilsson@kil.se 2014-05-07 Rutin för kontroll av åtkomst till patientuppgifter-loggranskning av NPÖ, Meddix och verksamhetssystem INLEDNING Patientdatalagen

Läs mer

VIFO-kartan Verksamhetens Informations- och Funktionalitets-Områden för vård och omsorg med fokus på hälso- och sjukvård

VIFO-kartan Verksamhetens Informations- och Funktionalitets-Områden för vård och omsorg med fokus på hälso- och sjukvård VIFO-kartan Verksamhetens Informations- och Funktionalitets-Områden för vård och omsorg med fokus på hälso- och sjukvård Dokumentation för överlämning till Socialstyrelsen 2012-12-31 2 Syfte med VIFO-kartan

Läs mer

Vi hjälper allt från små företag till stora koncerner att ta hand om och effektivisera de ekonomiska processerna från beställning till betalning.

Vi hjälper allt från små företag till stora koncerner att ta hand om och effektivisera de ekonomiska processerna från beställning till betalning. Vi hjälper allt från små företag till stora koncerner att ta hand om och effektivisera de ekonomiska processerna från beställning till betalning. Med marknadens vassaste system och ett brett spektrum av

Läs mer

Process anslutning kvalitetsregister till Mina Vårdkontakter. Dokumentansvarig: Gösta Hiller Datum: 2015-05- 28 Version: 1.0

Process anslutning kvalitetsregister till Mina Vårdkontakter. Dokumentansvarig: Gösta Hiller Datum: 2015-05- 28 Version: 1.0 Process anslutning kvalitetsregister till Mina Vårdkontakter Dokumentansvarig: Gösta Hiller Datum: 2015-05- 28 Version: 1.0 Anslutning kvalitetsregister till Mina Vårdkontakter 2 (13) Innehåll Inledning...

Läs mer

Vårdgivares anslutning till NPÖ Introduktion för Verksamhetschefer och Införandeansvariga 2014-04-16

Vårdgivares anslutning till NPÖ Introduktion för Verksamhetschefer och Införandeansvariga 2014-04-16 Vårdgivares anslutning till NPÖ Introduktion för Verksamhetschefer och Införandeansvariga 2014-04-16 Innehåll Inledning Introduktion till NPÖ Vad ser jag i NPÖ? Vad krävs för att använda NPÖ? Hur startar

Läs mer

Gör er redo för NPÖ 2.0 och Journalen på Nätet! - med Tietos anslutningstjänst

Gör er redo för NPÖ 2.0 och Journalen på Nätet! - med Tietos anslutningstjänst Gör er redo för NPÖ 2.0 och Journalen på Nätet! - med Tietos anslutningstjänst VÄLKOMNA - Ola Bergkvist - Jon Durefelt 2015-04-23 Agenda 1. Det här är anslutningstjänsten 1. NPÖ 1.0 => NPÖ 2.0 Anpassning

Läs mer

Systemförvaltnings Modell Ystads Kommun(v.0.8)

Systemförvaltnings Modell Ystads Kommun(v.0.8) IT avdelningen Piparegränd 3 271 42 Ystad Systemförvaltnings Modell Ystads Kommun(v.0.8) S.M.Y.K Beskrivningar och hänvisningar till rutiner och riktlinjer som ligger till grund för ett tryggt förvaltande

Läs mer

Administrativa uppdrag. Beskrivning av modell för administrativa behörigheter version 1.1

Administrativa uppdrag. Beskrivning av modell för administrativa behörigheter version 1.1 Administrativa uppdrag Beskrivning av modell för administrativa behörigheter version 1.1 Innehållsförteckning 1. Om detta dokument och vidare behandling... 2 2. Definitioner... 3 3. Bakgrund... 4 4. Utgångspunkter

Läs mer

Förslag Regionalt program ehälsa 2014-2018. Margareta Hansson, Regionförbundet Örebro Ulrika Landström, Örebro läns landsting

Förslag Regionalt program ehälsa 2014-2018. Margareta Hansson, Regionförbundet Örebro Ulrika Landström, Örebro läns landsting Förslag Regionalt program ehälsa 2014-2018 Margareta Hansson, Regionförbundet Örebro Ulrika Landström, Örebro läns landsting 1 Bakgrund Regionalt program för ehälsa 2010 Baserade sig på: Den nationella

Läs mer

Insamling av hälsodata i hemmet

Insamling av hälsodata i hemmet Insamling av hälsodata i hemmet Bakgrund/problemområde Idag i sker ett antal olika initiativ kring vård på distans, omvårdnad på distans, digitaliseringen av trygghetslarmen och olika typer av hälsosatsningar.

Läs mer

Karlstads Universitet, Datavetenskap 1

Karlstads Universitet, Datavetenskap 1 2003-01-20 DAV B04 - Databasteknik 2003-01-20 KaU - Datavetenskap - DAV B04 - MGö 26 Relationsmodellen En formell teori som baserar sig på (främst) mängdlära predikatlogik Föreslogs av E.F Codd 1970 i

Läs mer

Kom med du också ditt bidrag hjälper till att göra vården bättre!

Kom med du också ditt bidrag hjälper till att göra vården bättre! Nationellt kvalitetsregister samt stöd i den individuella vården för patienter med primär immunbrist och/eller ökad infektionskänslighet Kom med du också ditt bidrag hjälper till att göra vården bättre!

Läs mer

FHIR OCH INTEROPERABILITET I SJUKVÅRDEN OSKAR THUNMAN

FHIR OCH INTEROPERABILITET I SJUKVÅRDEN OSKAR THUNMAN FHIR OCH INTEROPERABILITET I SJUKVÅRDEN OSKAR THUNMAN 2015-01-29 CALLISTAENTERPRISE.SE FHIR OCH INTEROPERABILITET I SJUKVÅRDEN Semantisk interoperabilitet Bakgrund Dagens standarder FHIR och framtidens

Läs mer

Tjänsteavtal för ehälsotjänst

Tjänsteavtal för ehälsotjänst Tjänsteavtal för ehälsotjänst Bilaga 2. Specifikation av Tilläggstjänster INNEHÅLLSFÖRTECKNING 1. Inledning... 3 2. Kompletterande tjänster och funktioner... 3 2.1. Konsultstöd... 3 2.2. Meddelandetjänsten...

Läs mer

Elektronisk tullräkning Sid 1(9) Samverkansspecifikation. Version: 1.0 SAMVERKANSSPECIFIKATION. för. e-tullräkning

Elektronisk tullräkning Sid 1(9) Samverkansspecifikation. Version: 1.0 SAMVERKANSSPECIFIKATION. för. e-tullräkning Elektronisk tullräkning Sid 1(9) SAMVERKANSSPECIFIKATION för e-tullräkning Elektronisk tullräkning Sid 2(9) Innehållsförteckning 1 Inledning...3 1.1 Introduktion...3 2 Identifikation av parterna...4 2.1

Läs mer

Integration av Gynop-registret i elektronisk patientjournal

Integration av Gynop-registret i elektronisk patientjournal Integration av Gynop-registret i elektronisk patientjournal eller Att koppla ihop en liten släpvagn med en stor bil All information om patienten skall finns att läsa i patientjournalen! Men behöver allt

Läs mer

Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet

Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet Innehållsförteckning 1. Generell informationssäkerhet... 4 1.1. Styrande dokumentation... 4 1.2. Organisation... 4 Incidenthantering...

Läs mer

Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation.

Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation. Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation. Datum: 2011-02-28 Version: Författare: Christina Danielsson Senast ändrad: Dokumentnamn:

Läs mer

Bilaga 3: RIV-SHS förstudie, Mina intyg

Bilaga 3: RIV-SHS förstudie, Mina intyg Bilaga 3 RIV-SHS förstudie, Mina intyg Innehållsförteckning 1. Inledning... 2 2. Bakgrund... 2 3. Historik... 2 4. Problembeskrivning... 2 5. Nulägesbeskrivning... 3 6. Börlägesbeskrivning... 3 6.1. Effektmål...

Läs mer

Introduktion. Klasser. TDP004 Objektorienterad Programmering Fö 2 Objektorientering grunder

Introduktion. Klasser. TDP004 Objektorienterad Programmering Fö 2 Objektorientering grunder Introduktion TDP004 Objektorienterad Programmering Fö 2 Objektorientering grunder OO är den mest använda programmeringsparadigmen idag, viktigt steg att lära sig och använda OO. Klasser är byggstenen i

Läs mer

Evidensbaserad socialtjänst

Evidensbaserad socialtjänst Evidensbaserad socialtjänst - till nytta för individen Känner du till att du har ett regeringsuppdrag att följa gällande ett evidensbaserat arbete? ill: ida brogren Den verkliga upptäcksresan består inte

Läs mer

Workshop om Internetbaserad stöd och behandling 26-27 augusti

Workshop om Internetbaserad stöd och behandling 26-27 augusti Workshop om Internetbaserad stöd och behandling 26-27 augusti Gruppdiskussioner från dag 1 och fm dag 2 Fråga 1 Vad är tydligare? Tidsplanen Frågan om när vi verkligen kan ansluta oss är dock fortfarande

Läs mer

Beslut efter tillsyn enligt personuppgiftslagen (1998:204) PuL

Beslut efter tillsyn enligt personuppgiftslagen (1998:204) PuL Datum Diarienr 2010-05-21 1319-2009 Styrelsen för Sahlgrenska Universitetssjukhuset Torggatan 1 431 35 Mölndal Beslut efter tillsyn enligt personuppgiftslagen (1998:204) PuL Datainspektionens beslut Datainspektionen

Läs mer

Här är vi - och hit är vi på väg! Åke Rosandher, chef CeHis

Här är vi - och hit är vi på väg! Åke Rosandher, chef CeHis Här är vi - och hit är vi på väg! Åke Rosandher, chef CeHis 1 Handlingsplan 2013-2018 www.cehis.se Uppdraget Vad som ska göras gemensamt innehåll och principer Organisation och styrning Finansiering och

Läs mer

Mötesprotokoll för Inera AB styrelse

Mötesprotokoll för Inera AB styrelse Mötesprotokoll för Inera AB styrelse När: Onsdag den 9 april, 2014, kl 13.00 15.00 Var: Inera AB, lokal Magasinera Närvarande styrelsen: Närvarande övriga: Ej närvarande: Martin Andréasson (M), Västra

Läs mer

Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg

Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg Vad är Meridix Studio? Meridix Studio är ett verktyg som låter er analysera och följa upp er kommunikation via ett enkelt men kraftfullt

Läs mer

Nationella resurser för gemensam informationsstruktur och terminologi. Center för ehälsa i samverkan Socialstyrelsen

Nationella resurser för gemensam informationsstruktur och terminologi. Center för ehälsa i samverkan Socialstyrelsen Nationella resurser för gemensam informationsstruktur och terminologi Center för ehälsa i samverkan Socialstyrelsen Nationellt fackspråk Vård och omsorg Snomed CT Klassifikationer och kodverk Termbanken

Läs mer

Människa- datorinteraktion, MDI, ht 2011, anvisningar för projekt- /grupparbete

Människa- datorinteraktion, MDI, ht 2011, anvisningar för projekt- /grupparbete Människa- datorinteraktion, MDI, ht 2011 Anvisningar för projekt- /grupparbete Kursens projektuppgift består av att genomföra ett projektarbete i grupper om 3-4 personer. Uppgiften ska sedan presenteras

Läs mer

MIS Life Insurance XML

MIS Life Insurance XML MIS Life Insurance XML Kundfråga Kundfråga Livförsäkring Version: 1 Utgåva: 6.2 Referens: MIS Life Insurance XML Kundfråga version 1.6.2 Uppdaterad: 2013-05-23 Kommentarer och rättningar av detta dokument

Läs mer

BEAst rekommendation för hantering av bilagor till elektroniska fakturor 2011-05-17

BEAst rekommendation för hantering av bilagor till elektroniska fakturor 2011-05-17 BEAst rekommendation för hantering av bilagor till elektroniska fakturor 2011-05-17 1(7) Innehållsförteckning 1. INLEDNING... 3 2. BEAST:S REKOMMENDATION... 3 2.1 EDIFACT... 3 2.2 XML... 3 3. ALLMÄNT...

Läs mer

Riktlinjer för Försäkringskassans begreppskatalog

Riktlinjer för Försäkringskassans begreppskatalog Försäkringsprocesser RIKTLINJER 2010-01-15 Ändringsdatum Serienummer Version 2010:01 1.0 1 (10) + Riktlinjer för Försäkringskassans begreppskatalog Försäkringsprocesser RIKTLINJER 2010-01-15 Ändringsdatum

Läs mer

Informationssäkerhet. Varför jobbar vi med informationssäkerhet? Vad är informationssäkerhet? Presentation

Informationssäkerhet. Varför jobbar vi med informationssäkerhet? Vad är informationssäkerhet? Presentation Presentation Informationssäkerhet Kim Strandberg Informationssäkerhetsstrateg/jurist kim.strandberg@regionostergotland.se 010-103 03 385 Region Informationssäkerhet, Östergötland 2015-03-11, Kim Strandberg

Läs mer

EAs krav vid ackreditering av flexibel omfattning

EAs krav vid ackreditering av flexibel omfattning SWEDAC DOC 12:1 2012-05-10 Utgåva 1 Inofficiell översättning av EA 2/15 M:2008 EAs krav vid ackreditering av flexibel omfattning Swedac, Styrelsen för ackreditering och teknisk kontroll, Box 878, 501 15

Läs mer

10. Regelbok IT-information IT och ehälsa. Primärvårdsprogram 2015

10. Regelbok IT-information IT och ehälsa. Primärvårdsprogram 2015 Publicerad 1 (8) 10. Regelbok IT-information IT och ehälsa Primärvårdsprogram 2015 Publicerad 2 (8) 10.1 Introduktion Alla vårdgivare med vilka Landstinget Västmanland, hädanefter kallat LTV, tecknat vårdavtal

Läs mer

Anvisningar för ifyllning av Excelark för databaser (xml-filer)

Anvisningar för ifyllning av Excelark för databaser (xml-filer) 2009-10-09 (reviderad 2011-01-04, 2011-02-14, 2011-10-20, 2012-09-17) Riksarkivet IT-avdelningen Anvisningar för ifyllning av Excelark för databaser (xml-filer) 1 Anvisningar för ifyllning av Excelark

Läs mer

EyeNet Sweden stark autentisering i kvalitetsregister

EyeNet Sweden stark autentisering i kvalitetsregister EyeNet Sweden stark autentisering i kvalitetsregister Användning av e-tjänstekort (SITHS) EyeNet Sweden Kontaktinformation till RC: eyenetsweden@ltblekinge.se INNEHÅLLSFÖRTECKNING Bakgrund om SITHS 3 Instruktion

Läs mer

HSA Arkivering av stängda vårdgivare och vårdenheter. Scenariobeskrivning, version 2.0, 2014-09-30

HSA Arkivering av stängda vårdgivare och vårdenheter. Scenariobeskrivning, version 2.0, 2014-09-30 HSA Arkivering av stängda vårdgivare och vårdenheter Scenariobeskrivning, version 2.0, Innehåll Inledning... 3 Information som ska sparas vid arkivering... 3 Scenario 1: En vårdenhet stängs... 4 Scenario

Läs mer

Mina meddelanden Förmedling av elektronisk post för myndigheter i Sverige

Mina meddelanden Förmedling av elektronisk post för myndigheter i Sverige Mina meddelanden Förmedling av elektronisk post för myndigheter i Sverige Teknisk översikt för brevlådeoperatörer Version 1.2 Mina meddelanden är en myndighetsgemensam e-posttjänst förvaltad av Skatteverket

Läs mer

De t Mobil Tim gl as e t

De t Mobil Tim gl as e t Det Mobila Timglaset Det mobila timglaset Det mobila timglaset är framtaget för att öka förståelsen för hur en organisation påverkas och kan höja sin effektivitet genom att införa mobil ärendehantering.

Läs mer

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning

Läs mer

Avrop - E-förvaltningsstödjande tjänster 2010

Avrop - E-förvaltningsstödjande tjänster 2010 Datum 2013-10-08 Dnr 2.1.1-2919-2013 Version 1.0 Avdelning Informationsavdelningen Enhet Enheten för informationsutveckling Författare Johan Carlström, Lars Lundqvist Avrop - E-förvaltningsstödjande tjänster

Läs mer

Beställning D Etablera samverkan

Beställning D Etablera samverkan Beställning D Etablera samverkan Beställningen skall ske av tjänstedomänansvarig eller en person som fått denna rättighet delegerad av tjänstedomänansvarig. Via denna beställning kopplas logiska verksamhetsadresser

Läs mer

PLAN för att komma igång med Senior alert inom hemvården

PLAN för att komma igång med Senior alert inom hemvården PLAN för att komma igång med Senior alert inom hemvården Verksamhet Datum Sida 2 (18) Innehåll Plan att komma igång med Senior alert sid 3 Ett preventivt arbetssätt sid 4 Bakomliggande orsaker sid 7 Förebyggande

Läs mer

Manual HSB Webb brf 2004 03 23

Manual HSB Webb brf 2004 03 23 TERMINOLOGI I Polopoly används ett antal grundläggande begrepp för publicering och hantering av information, eller innehåll som det också benämns. Nedan följer en kort genomgång av denna grundläggande

Läs mer

NI 2015:1 Kort introduktion

NI 2015:1 Kort introduktion NI 2015:1 Kort introduktion VGR spridningskonferens Ingela Strandh Informationsstruktur och e-hälsa, avdelningen Kunskapsstöd 2015-01-29 och 2015-02-03 Uppdrag om Gemensam informationsstruktur Vidareutveckla

Läs mer

KOMMUNEN SOM VÅRDGIVARE

KOMMUNEN SOM VÅRDGIVARE KOMMUNEN SOM VÅRDGIVARE INFORMATION TILL DIG SOM ÄR HEMSJUKVÅRDSPATIENT, FÅR REHABILITERINGSINSATSER OCH/ELLER HJÄLPMEDEL Socialnämnden 2011-10-19(rev 2013-01-14) INNEHÅLLSFÖRTECKNING Kommunen som vårdgivare...

Läs mer