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

14 RegistrationID RegistrationID är det referenshantag till registreringen som transaktionen resulterar i. Det är ett arbiträrt ID som sätts helt enligt registrets egna önskemål. Detta ID används som referens i alla efterföljande operationer i CRUD-mönstret. Om klientsystemet av någon anledning önskar uppdatera registeringens innehåll finns referensen med i requestheadern för den operationen, likadant för get och delete. Version Version används för att hantera synkroniseringsförhållanden när multipla klienter opererar mot samma registrering. Varje update operation tickar upp versionsnumret före registreringen. I och med att exemplet kommer från Create-operationen är versionsnumret givet alltid 1. Status Status är en flagga som berättar var registreringen är i förhållande till sin livscykel. En registrering kan gå genom ett antal faser från en första inrapportering via validering till låsning eller för den delen borttagen som ett resultat av en delete-operation. Rymden för möjliga status för en registrering är ännu inte helt kartlagd och förankrad, men kommer att uttryckas som en given enumeration vid publicering i produktion. Det återstår således en del förankringsarbete innan kontraktet är klart, men det kommer att finnas en given rymd för status. Information Information är en godtycklig sträng som kan innehålla arbiträr information gällande den skapade registreringen. Den är tänkt att nå slutanvändaren som står bakom registreringen och kan användas för att uttrycka observationer. Vilka exakta krav som finns på hanteringen av denna informationsmängd är ännu ej formulerat, men det kommer att finnas behov av att bifoga information även i de fall transaktionen kunnat klaras av. 13

15 ErrorInformationType Felinformation bifogas requests som resulterat i en misslyckad transaktion. Detta kan ha multipla orsaker och det är därför möjligt att bifoga en eller flera instanser av objektet. Det definieras enligt följande: <xs:complextype name="errorinformationtype"> <xs:sequence> <xs:element name='id' type='erroridenum' /> <xs:element name='detail' type='xs:string' minoccurs='0' /> </xs:sequence> </xs:complextype> ID ID är en error-kod som I närmare detalj beskriver vilken typ av fel som uppstått. Felkoderna är precis som i http-fallet organiserade i klasser utifrån vilken typ av fel det är och var felet uppstått, och har en detaljeringsgrad som ska underlätta felsökning. Det finns även felkoder för generella fel och klassningar som indikerar om felet är temporärt eller persistent. Detaljer om felkoderna kommer att presenteras i tjänstens SAD och det finns anledning att fundera igenom dessa noggrant innan man låser sig. I nuvarande förslag finns rymder för fel i själva tjänsten, (motsvarande 5XX i http), klientrelaterade fel (motsvarande 4XX), fel relaterade till registreringens innehåll (ogiltiga alternativ, processfel et.c.). Detta kan dock komma att utvecklas innan tjänstedomänen är antagen. Detail Detail är en valfri text där tjänsteproducent har möjlighet att ytterligare specificera information om det uppkomna felet. Tanken är att medan felkoden är en statisk information som pekar ut typen av fel kan detail informationen användas för att beskriva specifika bakomliggande orsaker. Felhantering Den uppmärksamme kan reagera på att vi har en webbtjänst som returnerar ett korrekt svar som samtidigt upplyser om att operationen misslyckats. I webbtjänst-tekniken finns mekanismer för att representera det man kallar tekniska fel med ett soap-fault, vilket motsvarar ett exception i vanliga programmeringsspråk. Detta beslut bottnar i principer från befintliga tjänster i RIV-TA och blir dessutom nödvändigt i och med att vi enbart använder webbservice-tekniken för att transportera ett innehåll. Tekniken med soap-faults är mer utformad för att kommunicera problem kring själva webbservice lagret. Soap-faults kommer i princip endast att returneras då tjänsten har problem med den underliggande soap hanteringen, något som ska vara sällsynt ifall alla flöjer beprövade tekniker och verktyg. 14

16 Vidare information Denna PM kommer att uppdateras i takt med projektets utveckling och tillgängliggörs genom SKL:s projekt NPDi och UCR. För ytterligare information om projektet eller tjänstekontrakten kan författaren kontaktas på epost: alternativt mobiltelefon

RIV TA Domänschema 2.1

RIV TA Domänschema 2.1 RIV TA Domänschema 2.1 RIV Tekniska Anvisningar CeHis Arkitekturledning Sida: 1 (8) RIV TA Domänschema 2.1 RIV Tekniska Anvisningar 2012-01-03 RIV TA Domänschema 2.1 RIV Tekniska Anvisningar CeHis Arkitekturledning

Läs mer

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

ÄR KVALITETSREGISTREN EN GIVEN KÄLLA? Tveksamt

ÄR KVALITETSREGISTREN EN GIVEN KÄLLA? Tveksamt VÅRDEN I SIFFROR ÄR KVALITETSREGISTREN EN GIVEN KÄLLA? Tveksamt Öppen dataplattform Nationell tjänsteplattform Innovatörer 1177 Vårdguiden Vården i siffror VÅRDEN I SIFFROR Vardenisiffror.se Enklare tillgång

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

Tjänsteavtal för ehälsotjänst

Tjänsteavtal för ehälsotjänst Tjänsteavtal för ehälsotjänst Bilaga 1. Specifikation av Tjänsten INNEHÅLLSFÖRTECKNING 1. Inledning... 3 2. Bakgrund... 3 2.1. Referenser... 4 3. Tjänstebeskrivning... 4 3.1. Syftet med Tjänsten... 4 3.2.

Läs mer

Uppgiftskravstjänsten Teknisk anslutning för att hämta uppgiftskrav som öppna data. Version 1.0

Uppgiftskravstjänsten Teknisk anslutning för att hämta uppgiftskrav som öppna data. Version 1.0 Uppgiftskravstjänsten Teknisk anslutning för att hämta uppgiftskrav som öppna data Version 1.0 1 Innehållsförteckning 1 Inledning... 3 2 Anslutning... 3 2.1 Scenario 1: Hämtning av uppgiftskrav som öppna

Läs mer

Struktur i journal och kvalitetsregister tar bort dubbelregistrering

Struktur i journal och kvalitetsregister tar bort dubbelregistrering Struktur i journal och kvalitetsregister tar bort dubbelregistrering Nationella Kvalitetsregister, Nationella programmet för datainsamling, NPDi, Staffan Winter, programansvarig Nationellt program för

Läs mer

Integration mot SPOR. Svenskt PeriOperativt Register 3.0

Integration mot SPOR. Svenskt PeriOperativt Register 3.0 Innehållsförteckning Innehållsförteckning... 1 1. Inledning... 2 2. Förberedelser... 2 3. Sätt att integrera... 2 3.1. Webbtjänst... 2 Autentisering... 2 Beställning av certifikat... 2 Adresser... 3 3.2.

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

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

Lä s mer om SLL:s Regionälä Tjä nsteplättform (RTP)

Lä s mer om SLL:s Regionälä Tjä nsteplättform (RTP) 1 (7) Lä s mer om SLL:s Regionälä Tjä nsteplättform (RTP) Stockholms läns landstings Regionala Tjänsteplattform (RTP) är en teknisk plattform som förenklar, säkrar och effektiviserar informationsutbytet

Läs mer

Arkitektur och Regelverk Definition av kodverk och klassifikation. Version 1.0

Arkitektur och Regelverk Definition av kodverk och klassifikation. Version 1.0 Arkitektur och Regelverk Definition av kodverk och klassifikation Version 1.0 Innehållsförteckning 1. Inledning... 3 2. Definitioner... 3 Referenser och underlag... 5 Revisionshistorik Version, datum Författare

Läs mer

Teknisk beskrivning PDL i HSA

Teknisk beskrivning PDL i HSA Teknisk beskrivning PDL i HSA Beskrivning av vårdgivare, vårdenhet och medarbetaruppdrag i HSA för implementation i administratörsgränssnitt samt registrering via LDAP-verktyg Version 1.01 Innehållsförteckning

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

Underlag för godkännande av tjänsteproducent

Underlag för godkännande av tjänsteproducent Underlag för godkännande av tjänsteproducent Sid 1/16 Innehåll 1. Versionshantering... 3 2. Inledning... 4 2.1. Instruktioner för ifyllande... 4 2.2. Hantering vid förändring av tjänsteproducent... 5 2.3.

Läs mer

Synkronisering av riktlinjer, dokumentation, kvalitetsregister och informationsstruktur.

Synkronisering av riktlinjer, dokumentation, kvalitetsregister och informationsstruktur. Synkronisering av riktlinjer, dokumentation, kvalitetsregister och informationsstruktur. Mattias Agestam, Stockholms läns sjukvårdsområde Staffan Winter, Nationella Programmet för Datainsamling IT-kommitténs

Läs mer

Anvä ndärhändledning test

Anvä ndärhändledning test Anvä ndärhändledning test Revisionshistorik Version Författare Kommentar 0.1 Eva Biberg Första version 0.2 Oscar Möller Ändringar efter genomläsning 0.3 Oscar Möller Flyttar översiktsbilder från LAT-hund

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

Funktioner kring nationella kvalitetsregister Registerhållare Nationella och regionala stödteam

Funktioner kring nationella kvalitetsregister Registerhållare Nationella och regionala stödteam Funktioner kring nationella kvalitetsregister Registerhållare Nationella och regionala stödteam Registerstyrgrupp Leds av registerhållaren som är den som driver arbetet, är sammankallande och ytterst ansvarig

Läs mer

Intressent- och behovskarta

Intressent- och behovskarta Dokument nr: Version: Status: Sida: 1 Utgåva (0)6 Dokumenttyp: Projekt: Projektnummer: Leveransrapport ehälsa/mobilitet 1403 Dokumentbeskrivning: Intressent- och behovskarta Utfärdat av: Utf datum: Godkänt

Läs mer

LAT Lathund anslutning och test [ORT] [REGISTER]

LAT Lathund anslutning och test [ORT] [REGISTER] LAT Lathund anslutning och test Sida: 1 (6) Revisionshistorik Version Författare Kommentar 0.1 Oscar Möller Första version 0.2 Oscar Möller Lagt till revisionshistorik Lagt till formulärdatum för respektive

Läs mer

Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1.

Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1. Schenker har interna system som handhar information som är av intresse för våra kunder/partners. Idag finns ett flertal av dem tillgängliga via Internet, sk Online-tjänster. Dessa erbjuder inte bara hämtning

Läs mer

NATIONELLA PROGRAMMET FÖR DATAINSAMLING, NPDI. Datainsamling till kvalitetsregister genom praktisk tillämpning av de nationella verktygen

NATIONELLA PROGRAMMET FÖR DATAINSAMLING, NPDI. Datainsamling till kvalitetsregister genom praktisk tillämpning av de nationella verktygen NATIONELLA PROGRAMMET FÖR DATAINSAMLING, NPDI Datainsamling till kvalitetsregister genom praktisk tillämpning av de nationella verktygen NPDI Mål: Strategi: Ta fram en nationell lösning för datainsamling

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

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

Vägledning för innovativ applikations- och tjänsteutveckling

Vägledning för innovativ applikations- och tjänsteutveckling Vägledning för innovativ applikations- och tjänsteutveckling Version 2.0 2014-04-15 ARK_0022 Innehåll Inledning... 2 Syfte... 2 Målgrupper... 3 Avgränsning... 3 Vägledningens mallar... 3 Informationsspecifikation...

Läs mer

Sverige behöver en öppen teknisk lösning för kunskaps- och beslutsstöd inom hälso- och sjukvård!

Sverige behöver en öppen teknisk lösning för kunskaps- och beslutsstöd inom hälso- och sjukvård! Sverige behöver en öppen teknisk lösning för kunskaps- och beslutsstöd inom hälso- och sjukvård! Det behövs en nationell satsning på en gemensam plattform som möjliggör att kunskaps- och beslutsstöd på

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

Avtal om Kundens användning av Journal via nätet Bilaga 1 - Specifikation av tjänsten Journal via nätet (Enskilds direktåtkomst)

Avtal om Kundens användning av Journal via nätet Bilaga 1 - Specifikation av tjänsten Journal via nätet (Enskilds direktåtkomst) Avtal om Kundens användning av Journal via nätet Bilaga 1 - Specifikation av tjänsten Journal via nätet (Enskilds direktåtkomst) Mellan Inera och Kund Innehåll 1. Inledning... 2 2. Bakgrund... 2 2.1 Referenser...

Läs mer

HSA Hantering av organisationsförändringar i vårdgivarstrukturen. Version 1.0

HSA Hantering av organisationsförändringar i vårdgivarstrukturen. Version 1.0 HSA Hantering av organisationsförändringar i vårdgivarstrukturen Version 1.0 Innehållsförteckning Innehållsförteckning... 2 1 Inledning... 3 2 Generellt kring organisationsförändringar... 3 2.1 Arkivering

Läs mer

InTime Message Center SMS gränssnittsspecifikation V2.3

InTime Message Center SMS gränssnittsspecifikation V2.3 Ansvarig utgivare: Datum: Version Status: Lars Nordström 2009-05-29 2.3.1 Fastställd InTime Message Center SMS gränssnittsspecifikation V2.3 Innehållsförteckning Innehållsförteckning... 1 Inledning...

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

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

TJÄNSTEBESKRIVNING FASAD Tjänstebaserad direktåtkomst Byggnad 2015-11-27

TJÄNSTEBESKRIVNING FASAD Tjänstebaserad direktåtkomst Byggnad 2015-11-27 TJÄNSTEBESKRIVNING FASAD Tjänstebaserad direktåtkomst Byggnad 2015-11-27 Extern dokumentation - fasadsystemet Dokumentation Tjänstebaserad uppdatering: Startsida Informationsutbytesmodeller (IUM): http://www.lantmateriet.se/global/qualiware/specifikation-gdl/index.htm

Läs mer

Kravspecifikation för utökat elektroniskt informationsutbyte

Kravspecifikation för utökat elektroniskt informationsutbyte Kravspecifikation för utökat elektroniskt informationsutbyte Innhållsförteckning Innhållsförteckning... 2 Revisionshistorik... 3 1. Inledning... 4 1.1 1.2 1.3 Syfte med dokumentet... 4 Målgrupp för dokumentet...

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

HSA Schemauppdateringsprocess. Version 1.2.1

HSA Schemauppdateringsprocess. Version 1.2.1 HSA Schemauppdateringsprocess Version 1.2.1 Innehåll Revisionshistorik... 2 1. Översikt schemauppdateringsprocess... 3 2. Planeringsfas... 3 2.1.1 Behovsanalys... 3 2.1.2 Interaktion med kravställare...

Läs mer

Anvisning och mall för namnsättning av tjänstedomän för tjänstekontrakt

Anvisning och mall för namnsättning av tjänstedomän för tjänstekontrakt Anvisning och mall för namnsättning av för Sid 1/11 Innehållsförteckning Utgåvehistorik för dokumentet... 3 Framtagning processen av namnstruktur... 4 Domännamnsättning - anvisning... 5 Kategori nivå 1...

Läs mer

Överenskommelse om samverkan mellan Sveriges Kommuner och Landsting och industrins företrädare rörande Nationella Kvalitetsregister

Överenskommelse om samverkan mellan Sveriges Kommuner och Landsting och industrins företrädare rörande Nationella Kvalitetsregister Överenskommelse om samverkan mellan Sveriges Kommuner och Landsting och industrins företrädare rörande Nationella Kvalitetsregister 1.1 God samverkan med industrin leder till bättre vård I Sverige förekommer

Läs mer

Serverat och kommunal arkitektur

Serverat och kommunal arkitektur Serverat och kommunal arkitektur Leverantörsmöte 1 2016-11-10 marco.deluca@skl.se 0733 810 247 Agenda Introduktion Styrande principer (exempel) Övergripande arkitektur Stödtjänster Integrationsprofiler

Läs mer

Dokumentationsrutiner i ett kvalitetsregister

Dokumentationsrutiner i ett kvalitetsregister Denna checklista sammanfattar vad en registerhållare bör tänka på när det gäller dokumentation av ett kvalitetsregister. Rutiner för dokumentation. Riktlinjer Registerhållaren bör utarbeta rutiner för

Läs mer

Strategier för att öppna upp och göra din organisations information tillgänglig för andra

Strategier för att öppna upp och göra din organisations information tillgänglig för andra Strategier för att öppna upp och göra din organisations information tillgänglig för andra David Svärd 2014-10-21 Nuvarande projekt 1. Direktåtkomst till ett registret för legitimerad hälso- och sjukvårdspersonal

Läs mer

NPÖ 1(12) 1 Systemkrav. Vanliga felmeddelanden i NPÖ Datum 2014-09-23

NPÖ 1(12) 1 Systemkrav. Vanliga felmeddelanden i NPÖ Datum 2014-09-23 NPÖ 1(12) 1 Systemkrav 1.1 Beskrivning Dessa systemkrav är supporterade från Inera för att använda NPÖ. Andra kombinationer kan fungera. 1.2 Åtgärd Ändra till någon av ovanstående kombinationer 1.3 Eskalering

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

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

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

Teknisk guide för brevlådeoperatörer

Teknisk guide för brevlådeoperatörer Teknisk guide för brevlådeoperatörer Gäller från december 2015 Sida 1 av 21 Innehållsförteckning Sammanfattning...2 1 Dokumentinformation...3 1.1 Syfte...3 1.2 Avgränsningar...3 1.3 Målgrupp...3 1.4 Begrepp

Läs mer

Funktioner kring nationella kvalitetsregister

Funktioner kring nationella kvalitetsregister Funktioner kring nationella kvalitetsregister Registerhållare Nationella och regionala stödteam Registerstyrgrupp Leds av registerhållaren som är den som driver arbetet, är sammankallande och ytterst ansvarig

Läs mer

Kvalitetsregister & legala förutsättningar. Moa Malviker Wellermark, Jurist SKL, Landstingsjurist LiÖ

Kvalitetsregister & legala förutsättningar. Moa Malviker Wellermark, Jurist SKL, Landstingsjurist LiÖ Kvalitetsregister & legala förutsättningar Moa Malviker Wellermark, Jurist SKL, Landstingsjurist LiÖ Vad är ett kvalitetsregister i lagen? - Samling av uppgifter om individer (personuppgifter) för syftet

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

Arbetsflöden för hantering av Försäkringskassans medicinska underlag

Arbetsflöden för hantering av Försäkringskassans medicinska underlag Arbetsflöden för hantering av Försäkringskassans Intygstjänster 2014-2015 Sid 1/22 Innehållsförteckning Innehållsförteckning... 2 Revisionshistorik... 2 1. Inledning... 3 2. FK AF1 - Skapa medicinskt vid

Läs mer

Avtal om Kundens mottagande av intyg från Mina intyg Bilaga 1 - Specifikation av tjänsten mottagande av intyg från Mina Intyg

Avtal om Kundens mottagande av intyg från Mina intyg Bilaga 1 - Specifikation av tjänsten mottagande av intyg från Mina Intyg Avtal om Kundens mottagande av intyg från Mina intyg Bilaga 1 - Specifikation av tjänsten mottagande av intyg från Mina Intyg Mellan Inera och Kund Innehåll 1. Inledning... 3 2. Bakgrund... 3 3. Syfte...

Läs mer

Introduktion till integrering av Schenkers e-tjänster. Version 2.0

Introduktion till integrering av Schenkers e-tjänster. Version 2.0 Introduktion till integrering av Schenkers e- Version 2.0 Datum: 2008-06-18 Sida 2 av 8 Revisionshistorik Lägg senaste ändringen först! Datum Version Revision 2008-06-18 2.0 Stora delar av introduktionen

Läs mer

Nationell informationsstruktur 2016:1. Bilaga 9: Terminologibindning till nationellt fackspråk

Nationell informationsstruktur 2016:1. Bilaga 9: Terminologibindning till nationellt fackspråk Nationell informationsstruktur 2016:1 Bilaga 9: Terminologibindning till nationellt fackspråk Inledning Denna bilaga listar de koder som ingår som -urval för typer av Samband och Deltagande, föreslagna

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

Geodataportalen - Metadata - Dokumentation av tjänster

Geodataportalen - Metadata - Dokumentation av tjänster PM 1(13) Geodataportalen - Metadata - Dokumentation av tjänster Organisation Postadress Besöksadress Telefon E-post Internet Lantmäteriet 801 82 Gävle Lantmäterigatan 2 0771-63 63 63 geodatasekretariatet@lm.se

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

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

Ökad patientdialog med digitala formulär

Ökad patientdialog med digitala formulär Ökad patientdialog med digitala formulär Nationell Handlingsplan 2013-2018 Målbild 2018 Ökad medverkan från individen, smartare e-hälsotjänster och samarbete över organisationsgränser Individen Kunna nå

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

Anslutningsvägledning. Nationell patientöversikt 2.0

Anslutningsvägledning. Nationell patientöversikt 2.0 Anslutningsvägledning Nationell patientöversikt 2.0 Innehåll Introduktion... 3 Anslutningsblanketter... 4 Anslutning för produktion... 5 Anslutning för test... 6 Anslutning för test med egen klient...

Läs mer

Teknisk guide för brevlådeoperatörer

Teknisk guide för brevlådeoperatörer Teknisk guide för brevlådeoperatörer Gäller från februari 2017 Sida 1 av 22 Innehållsförteckning Sammanfattning... 2 1 Dokumentinformation... 3 1.1 Syfte... 3 1.2 Avgränsningar... 3 1.3 Målgrupp... 3 1.4

Läs mer

Manual för att registrera i Svenskt Beroenderegister

Manual för att registrera i Svenskt Beroenderegister Manual för att registrera i Svenskt Beroenderegister 2014-02-28 1 Förutsättningar För att logga in behöver du: 1. Ett giltigt SITHS-kort (Tjänste-ID) 2. En dator med kortläsare 3. Vara upplagd som användare

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

Introduktion till VITS-bokens tekniska arkitektur

Introduktion till VITS-bokens tekniska arkitektur Center för ehälsa i samverkan Hornsgatan 20, 118 82 Stockholm Vxl: 08-452 70 00 www.cehis.se info@cehis.se Introduktion till VITS-bokens tekniska arkitektur Center för ehälsa i samverkan koordinerar landstingens

Läs mer

Manual för registrering i Svenskt Beroenderegister 2015-05-05

Manual för registrering i Svenskt Beroenderegister 2015-05-05 Manual för registrering i Svenskt Beroenderegister 2015-05-05 1 Inklusionskriterium I SBR registreras Alla personer som behandlas på sjukvårdsenheter för specialiserad utredning och behandling av skadligt

Läs mer

Tjänstekontraktsbeskrivning - Terminologitjänsten

Tjänstekontraktsbeskrivning - Terminologitjänsten Vårt dnr RAPPORT 10/3152 Utgåva P1.4 Tjänstekontraktsbeskrivning - Terminologitjänsten Center för ehälsa i samverkan Hornsgatan 20, 118 82 Stockholm tfn: växel 08-452 70 00, Fax: 08-452 70 50 info@cehis.se

Läs mer

Utkast/Version (8) Användarhandledning - inrapportering maskin-till-maskin

Utkast/Version (8) Användarhandledning - inrapportering maskin-till-maskin Utkast/Version Sida 2.0 1 (8) 2017-05-12 Användarhandledning - inrapportering maskin-till-maskin 2 (8) Innehåll 1. Rapportering till VINN eller KRITA... 3 1.1 Allmänt... 3 1.2 Terminologi... 3 2. Hämta

Läs mer

Reviderade förslag på mål för graviditetsregistret. Olof Stephansson

Reviderade förslag på mål för graviditetsregistret. Olof Stephansson Reviderade förslag på mål för graviditetsregistret Olof Stephansson Ny vision och mål för GR Visionen för graviditetsregistret är att förbättra hälsa för mödrar och barn. Övergripande mål graviditetsregistret

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

Tjänsteplattformen nationell integration

Tjänsteplattformen nationell integration Tjänsteplattformen nationell integration 2013-02-12 Lars Erik Röjerås e lars.erik.rojeras@inera.se Innehåll Bakgrund och historia Så funkar det Hur förvaltas det idag Hur ser framtiden ut 2 Resan V-boken

Läs mer

2015 års överenskommelse inom området psykisk ohälsa bedömningskriterier och anvisningar för grundkrav och prestationsmål

2015 års överenskommelse inom området psykisk ohälsa bedömningskriterier och anvisningar för grundkrav och prestationsmål PM 2015-05-12 Dnr 5.3-2380/2015 1(20) ANDRA REVIDERADE VERSIONEN 2015 års överenskommelse inom området psykisk ohälsa bedömningskriterier och anvisningar för grundkrav och prestationsmål Bakgrund Staten

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

Nationell geodatastrategi

Nationell geodatastrategi Nationell geodatastrategi Vetenskapsrådet den 17 januari Ewa Rannestig Lantmäteriet Geodataråd Regeringen har tillsatt Geodatarådet för att bereda frågor som rör Lantmäteriverkets samordnande roll. Rådet

Läs mer

Mail för attest. Skickas ett mail till den som skapade och till den som attesterade rapporten om felet, åtgärda felet för ett nytt inrapportering

Mail för attest. Skickas ett mail till den som skapade och till den som attesterade rapporten om felet, åtgärda felet för ett nytt inrapportering 1 SKL Inrapportering Innehåll Summering... 1 Krav... 2 Lägga till rättighet... 3 Kontouppgifter för inrapporteringen till Signe... 4 Tilldela licens... 4 Skapa SKL-inrapporteringsrapport... 5 Attestera

Läs mer

RIV Tekniska Anvisningar Tjänsteschema

RIV Tekniska Anvisningar Tjänsteschema RIV Tekniska Anvisningar Tjänsteschema Version 2.1.4 ARK_0005 Innehåll 1 Inledning... 4 1.1 Målgrupp... 4 1.2 Syfte... 4 1.3 Tillgänglighet... 5 1.4 Referenser... 5 2 Beskrivning av namnregler... 7 3 Detaljerade

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

TJÄNSTEBESKRIVNING FASAD Tjänstebaserad direktåtkomst Adress

TJÄNSTEBESKRIVNING FASAD Tjänstebaserad direktåtkomst Adress 2015-11-27 TJÄNSTEBESKRIVNING FASAD Tjänstebaserad direktåtkomst Adress Extern dokumentation - fasadsystemet Dokumentation Tjänstebaserad uppdatering: Startsida Informationsutbytesmodeller (IUM): http://www.lantmateriet.se/global/qualiware/specifikation-gdl/index.htm

Läs mer

AL T granskning NeR 2013-01-13. Version 1.0

AL T granskning NeR 2013-01-13. Version 1.0 AL T granskning NeR 2013-01-13 Version 1.0 Revisionshistorik Datum Version Beskrivning Författare 2013-01-13 PA1 Dokumentet skapat AL T, CeHis, Lennart Eriksson 2013-01-31 1.0 Bara gula markeringar inför

Läs mer

Landstingsstyrelsens förvaltning SLL Juridik och Upphandling. Upphandlingsavdelningen Bilaga 1. Kravspecifikation

Landstingsstyrelsens förvaltning SLL Juridik och Upphandling. Upphandlingsavdelningen Bilaga 1. Kravspecifikation Landstingsstyrelsens förvaltning LS1203-0482 SLL Juridik och Upphandling SLL1642 Upphandlingsavdelningen Bilaga 1 Kravspecifikation avseende upphandling av IT-tjänster för Nationella kvalitetsregister

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.3 Version: 1.3 2015-04-29 1 (10) 1 INTRODUKTION 3 1.1 IDENTITETSFEDERATIONER FÖR SVENSK E-LEGITIMATION 3 1.2 TILLITSRAMVERK OCH SÄKERHETSNIVÅER 4

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

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

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

Tentamen Informationsinfrastruktur

Tentamen Informationsinfrastruktur Tentamen Informationsinfrastruktur Institutionen för informatik och media, Informationssystem Datum 16/2 2012 Tid 8.00 12.00 Lärare Owen Eriksson Mattias Nordlindh Maxpoäng 55 För Godkänd krävs minst 50%

Läs mer

Informationsutbyte inom vård och omsorg Nuläge, önskat läge och hur vi kommer framåt

Informationsutbyte inom vård och omsorg Nuläge, önskat läge och hur vi kommer framåt 2014-11-23 1 (12) Informationsutbyte inom vård och omsorg Nuläge, önskat läge och hur vi kommer framåt Detta dokument har framtagits av Åke Nilsson, programansvarig för nationella programmet för datainsamling

Läs mer

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.0.1

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.0.1 Tjänsteplattform Tekniska krav ARK_0034 Version 1.0.1 Innehåll 1. Inledning... 3 1.1 Syfte... 3 1.2 Målgrupp... 3 1.3 Avgränsningar... 3 1.4 Fallstudier... 4 1.5 Referenser... 4 2. Terminologi... 5 3.

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

Gränssnitt och identiteter. - strategiska frågor inom Ladok3

Gränssnitt och identiteter. - strategiska frågor inom Ladok3 - strategiska frågor inom Ladok3 Sida 2 av 9 er Revision Datum Av Kommentar Granskare Godkännare 0.1 2011-05-26 Daniel Lind Utkast 0.2 2011-05-30 Daniel Lind Synpunkter från Catherine 0.3 2011-06-16 Daniel

Läs mer

Avtal mellan organisationerna:

Avtal mellan organisationerna: Avtal mellan organisationerna: * nedan kallat organisationen och Landstinget i *namnge på raden ovan den kommun, det landsting eller den privata vårdgivaren det gäller Jönköpings län nedan kallat registerhållare

Läs mer

Teknisk guide för myndigheter

Teknisk guide för myndigheter Teknisk guide för myndigheter Gäller från december 2015 Sida 1 av 19 Innehållsförteckning Sammanfattning...2 1 Dokumentinformation...3 1.1 Syfte...3 1.2 Avgränsningar...3 1.3 Målgrupp...3 1.4 Begrepp och

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

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

MVK SSO 2.0 Mina vårdkontakter

MVK SSO 2.0 Mina vårdkontakter Ämne Version Datum Introduktion MVK SSO 2.0 1.7 2014-02-14 Ansvarig Dokument ID Sign Martin Carlman/Peter Bäck MVK-0031 Version Datum Av Avsnitt Ändring 1.7 140214 AL MVK SSO 2.0 Mina vårdkontakter MVK

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

Tjänstekontraktsbeskrivning Infektionsverktyget - Registreringstjänster

Tjänstekontraktsbeskrivning Infektionsverktyget - Registreringstjänster Vårt dnr RAPPORT 10/3152 Utgåva P1.8 Tjänstekontraktsbeskrivning Infektionsverktyget - Registreringstjänster Center för ehälsa i samverkan Hornsgatan 20, 118 82 Stockholm tfn: växel 08-452 70 00, Fax:

Läs mer