Tjänstespecifik Teststrategi Utomlänsfakturering

Relevanta dokument
Tjänstespecifik teststrategi. För anslutning till tjänsteplattform för vård- och omsorgsutbud

Underlag för godkännande av tjänsteproducent

Villkor för anslutning till Nationella tjänsteplattformen

Information om Ineras certifieringstjänst

Elektronisk remiss. Beskrivning och tjänstespecifika villkor

Avtal om Kundens användning av

LAT Lathund anslutning och test

Avtal 1 om Agentens. användning av Ineras Tjänster

Användarhandbok Test. NKRR Utgåva 0.4 Sida: 1 (19) NKRR

Checklista. Konsumentinförande via Agent, Nationell Patientöversikt (NPÖ)

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

Checklista för konsumenter som ska kvalitetssäkra sina e-tjänster och konsumentadapter som nyttjar SSBT

Riktlinje för kvalificering av Ineras kunder

Beställningsstöd för anslutning till NTJP

HSA Kunskapstest för HSA-ansvariga

Läs mer om SLL:s Regionala Tjänsteplattform (RTP)

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

Version: 2.0 NBS / / AS

Version: 2.0 NBS / / AS

Personuppgiftstjänsten och övriga stödtjänster för patientens integritetsskydd Tomas Fransson, Inera

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 3.0

Konfigurationsstyrning tjänstedomäner ARK_0007. Version

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 1.0

Välkommen som Sambi-kund!

Säkerhetstjänster Spärr,Samtycke,Logg. Beskrivning och tjänstespecifika villkor

Bilaga 6 - Analys av GetMedicationHistory. Stöd till säker läkemedelsprocess

Rutinbeskrivning Mallar för test

Felsökningsunderlag. för Nationell patientöversikt, NPÖ. Dokumentationsversion 3.0 Datum

Säkerhetstjänster - verksamhetstillämpning och arkitektur

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

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

HSA Tjänsteanslutningsprocess. Kriterier och anslutningsinstruktioner för tjänster som vill nyttja informationen i HSA

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

Regelverk för digital utomlänsfakturering

Vägledning för användning av personidentifierare i nationell samverkansarkitektur för vård- och omsorg

Avtal om Kundens användning av Identifieringstjänst SITHS

LAT Lathund anslutning och test [ORT] [REGISTER]

Filleveranser till VINN och KRITA

Avtal om Kundens användning av E-identitet för offentlig sektor

Nationell patientöversikt

Checklista anslutning Serverat. Version 1.0

Implantatinf JL AB:s DATASKYDDSPOLICY

Avtal om Kundens användning av Svevac Bilaga 1 - Specifikation av tjänsten Svevac

Rådgivningsstödet webb. Beskrivning och tjänstespecifika villkor

Uppdatering av HSA-policyn. Resultat från diskussionstorg

Checklista anslutning Serverat. Version 2.0

Svevac - Beskrivning och tjänstespecifika villkor

Möjligheter och utmaningar med Personuppgiftstjänsten och dess lösning för nationell ReservID-hantering

Identifieringstjänst SITHS. - Beskrivning och tjänstespecifika villkor

Avtal om Kundens användning av Personuppgiftstjänsten Bilaga 1 - Specifikation av Personuppgiftstjänsten

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

Sammanfattning och specifikationer för POT

Skuldutdrag. Funktionell beskrivning av tjänsten med elektronisk överföring Utgåva 2.3

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

Tjänstekontraktsbeskrivning - Terminologitjänsten

Vid avrop kan krav komma att ställas som är relaterade till arbetsmiljö till exempel ljud, ljus, ergonomi, strålning m.m.

Förvaltningsplan för Tjänsteplattformen

Normativ specifikation

Nationell Patientöversikt. - Beskrivning och tjänstespecifika villkor

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

Kravspecifikation för utökat elektroniskt informationsutbyte

Anslutningsalternativ. Screeningstöd livmoderhals

Att utveckla, förvalta, och införa FGS:er Testmetodik

ÄR KVALITETSREGISTREN EN GIVEN KÄLLA? Tveksamt

Sjunet standardregelverk för informationssäkerhet

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.0.1

Instruktioner gällande behandling av personuppgifter

Exempel på verklig projektplan

NKRR. Regelskrivning i praktiken

Kundforum för kommuner del mars 2018

Serverat och kommunal arkitektur

Medicinsk service Division IT/MT IT/MT Samordning

Teknisk testning för otekniska testare

När samverkan mellan affärssystemen är en besvärlig väg med många hinder

Säker digital kommunikation Övergripande pilotinformation

SAMARBETE MELLAN 9 LANDSTING R7E-PROJEKTETETS RESA TILL GEMENSAMT E-ARKIV 29/ Flera landsting ett gemensamt e-arkiv

Anslutningsvägledning. Nationell patientöversikt 2.0

Sjunet Anslutningsavtal Förenklat regelverk för informationssäkerhet

Checklista Integrationsförnyelsen

Avtal om Kundens användning av tjänsten Video- och distansmöte

Hur kvalitetssäkra komplexa IT-lösningar och vad är egentligen test?

Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.3

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

ehälsomyndighetens nya säkerhetskrav

Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet

Teknisk guide för brevlådeoperatörer. Annika Melin Version: 1.1

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

Testpatienter. Godkända testpatienter i NPÖ produktionsmiljö

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga B. Servicenivåer konsument, SLA. Version: 1.

Intygstjänster. - Beskrivning och tjänstespecifika villkor

Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7)

RIV TA Konfigurationsstyrning 1.0 RIV Tekniska Anvisningar

Innovationsimplementation

NPÖ införande. Inera AB

Åtkomst till patientjournal för vårdens personal - blankett, Uppdrag att journalgranska

SSBT testbänk grundläggande uppgifter om företag (SSBTGU) engagemang i företag (SSBTEN) roll i företag (SSBTRO)

Tjänsteplattformen nationell integration

Handledning. Konfigurationsstyrning tjänstedomäner. Version ARK_

Avisering av förändringar i tjänstekontrakt för Mina Meddelanden

Anslutning till Mina meddelanden

Transkript:

Tjänstespecifik Teststrategi Utomlänsfakturering Sid 1/13

Innehåll 1. Inledning... 3 Kvalitetsmål... 4 Anpassning till testmodell... 4 Ekosystem... 5 Testmiljö... 6 2. Verifiering av tjänstekonsument... 7 Utvecklingsstöd... 7 Självdeklaration... 7 Avvikelser... 8 3. Verifiering av tjänsteproducent... 9 Utvecklingsstöd... 9 Självdeklaration... 9 Avvikelser... 10 4. Etablering av samverkan... 11 Omfattning (obligatorisk del)... 11 Omfattning (Ineras rekommendation)... 11 5. Regressionstestning och ändringshantering... 12 6. Referenser... 13 Sid 2/13

1. Inledning Detta dokument beskriver den övergripande teststrategin för tjänsten Utomlänsfakturering och är en implementation av Ineras generella testmodell [1] för anslutningar till nationella tjänsteplattformen. Utomlänsfakturering möjliggör kommunikation av fakturaunderlag utanför det egna landstinget/regionen. Fakturor skickas på annat sätt, men det är fakturaunderlaget som innehåller den känsliga informationen, och det är därför den ska kommuniceras via en säker plattform. Huvudsakliga kravägare för Utomlänsfakturering är AOR (lagar och regelverk), ICC (tjänsteplattformsintegration) och tjänsteförvaltning (informationsutbytesplattformen). Inera ansvarar för informationsutbytet över tjänsteplattformen, men för att tjänsten ska kunna användas på ett smidigt sätt, så omfattar teststrategin även kartläggning av vissa omkringliggande saker (fakturamatchning, PDL-loggning, behörighetskontroll med mera). Då det rör sig om en utlämning ligger dock ansvaret för kvalitetssäkring av detta på kommunicerande parter. Testningen utförs av anslutande parter själva. Då testmodellen är byggd på tillit, med många tjänstekonsumenter som skickar information till många tjänsteproducenter, så är ansvarstagande och bra testning på alla håll en framgångsfaktor för att helheten ska bli tillräckligt bra. Figur 1 Testprocess Tjänstekonsument och tjänsteproducent verifieras utifrån anslutande parts egen testning som dokumenterats i självdeklaration. När detta godkänts kan man ansluta till tjänsteplattformens QA-miljö. Där ska anslutningen verifieras innan man får driftsätta, och en testrapport ska skickas till Inera. Inera tillhandahåller ett End-2-End-underlag med en liten obligatorisk del, samt rekommendationer och checklista för övriga tester, men omfånget på dessa tester bestäms av anslutande parter själva. Sid 3/13

Kvalitetsmål Inera ansvarar för att informationsutbytet över nationella tjänsteplattformen fungerar utan driftstörningar. Ansvaret för uppfyllnad av verksamhetens krav samt lagar och förordningar ligger på anslutande parter. Nedanstående övergripande kvalitetsmål identifierades på workshop med Ineras projekt för utomlänsfakturering den 16 februari 2017, och de flesta är ett delat ansvar mellan Inera och anslutande parter: Korrekt informationsutbyte Medborgarnas behov av integritet möts (ej Ineras ansvar) Personuppgiftsägarnas information hanteras enligt de lagar som gäller (ej Ineras ansvar) Tjänstekomponenter uppfyller tjänstekontrakten [2] Prestanda som klarar förväntad belastning med rimliga svarstider Bra möjligheter att upptäcka och felsöka eventuella problem i drift Dokumentation av legala krav, felsökningsprocesser, och avvikelser Anpassning till testmodell Testmodellens [1] grundkomponenter används, med de anpassningar som behövs i den aktuella tjänsten. Informationsavlämnande tjänstekonsumenter ska genomgå verifiering av tjänstekonsument. Informationsmottagande tjänsteproducenter ska genomgå verifiering av tjänsteproducent. Certifiering tillämpas inte för utomlänsfakturering eftersom patientinformationen utlämnas mellan vårdgivare. Innan driftsättning ska anslutning till QA-miljön göras. Samverkande parter avgör vilken ytterligare testning som behövs och man godkänner varandra. Inera har tagit fram ett End-2-End-underlag inom ramen för Etablering av samverkan, som underlättar kvalitetssäkring av att informationsutbytet uppfyller verksamhetens krav ur ett helhetsperspektiv. Detta innehåller en obligatorisk del, samt en checklista med rekommendationer, som är frivilliga att använda och fylla i. Sid 4/13

Ekosystem Ekosystemet för tjänsten Utomlänsfakturering visas översiktligt i Figur 1. Figur 2 Ekosystem Utomlänsfakturering är en integrationstjänst för fakturaunderlag mellan vårdgivare (gröna i figuren). Fakturor (lila) hanteras separat, och ska matchas med fakturaunderlag av konsument och producent. Fakturaunderlaget går via nationell tjänsteplattform, men kan bara skickas vidare om TAKning gjorts vid Etablering av samverkan. Adressering är baserad på organisationsnummer. Både tjänsteproducent och tjänstekonsument ska kontrollera att tjänstekontraktet uppfylls, anslutande part ska säkerställa att egna vårdgivares riktlinjer kring spårbarhet enligt PDL följs, samt se till att information om sekretessmarkerade identiteter inte skickas (förslagsvis med hjälp av Personuppgiftstjänsten [3]). Infrastruktur och stödtjänster har inget eget steg i testprocessen, men testas implicit av övriga testaktiviteter, samt av respektive systemägare. Tjänstekontraktet, dess schema och Schematron-validering ska granskas och testas av Inera. Sid 5/13

Testmiljö Anslutande parter behöver ha en rättvisande testmiljö där det finns testdata som inte har någon möjlig spårbarhet till skarpa personer (enbart ändring av namn och personnummer räcker vanligtvis inte). Verifiering av tjänstekonsument görs med SoapUI och i SIT-miljön. Kopplad till SIT finns en referensproducent som Nordic Medtest tillhandahåller, som man kan använda för att ladda hem filer som visuellt visar informationen som skickats. Verifiering av tjänsteproducent kan till största delen göras med SoapUI utan att använda nationella testmiljöer. Testning mellan landsting kan med fördel göras i SIT-miljön redan i verifieringsskedet. QA-miljön ska användas innan driftsättning. Sid 6/13

2. Verifiering av tjänstekonsument Syftet med denna verifiering är att Inera, i rollen som ansvarigt för regelverket för informationsutbyte och för nationella tjänsteplattformen, ska säkerställa att kraven i tjänstekontrakten uppfylls. Detta ger mottagande part en grund för att kunna lita på att etablering av samverkan kan ske. Den informationsavlämnande tjänstekonsumenten ska säkerställa att man på ett korrekt sätt kan leverera de varianter av fakturaunderlag som kommer att förekomma i drift. Anslutande part genomför testerna på egen hand, och dokumenterar i anvisad självdeklaration [4]. Denna granskas och godkänns av Inera, men ingen testning utförs av Inera, såvida anslutande part inte avropat detta som stödtjänst. Utvecklingsstöd Stöd för utveckling och egentester i samband med anslutning tillhandahålls genom en SoapUIvalideringsmock med tillhörande testanvisningar. SoapUI-valideringsmock: I releasepaketen för tjänstekontraktet finns det ett SoapUI-projekt med en ProcessClaimSpecification MockService. Denna mock kan köras lokalt, och tjänstekonsumenten kan skicka anrop till denna, och då kommer schema och Schematron att valideras. Schematron-reglerna (beskrivna i constraints.xml) innehåller de tillåtna värden som klassificerats, samt ytterligare regler kring element som sinsemellan är beroende med mera, enligt de krav som uttrycks i tjänstekontraktsbeskrivningen. Tjänstekonsumenten ska skapa testdata som åtminstone täcker de olika sorters fakturaunderlag som de avser att skicka. Man väljer själv om man designar sin testdata på egen hand, men man kan också efterlikna de varianter som finns i testfallen i SoapUI-testerna för ProcessClaimSpecification 1.0. Man ska också testa hanteringen av krediteringar, genom att sända sådana. Man ska använda testpersonnummer som är godkända av Inera eller Skatteverket. Självdeklaration I självdeklaration för tjänstekonsumenter, så ska man fylla i resultaten för nedanstående områden. Detta kartlägger tjänstekonsumentens uppfyllnadsgrad av tjänstekontraktet. Man måste inte stödja alla varianter av fakturaunderlag. Tjänstekontrakts-funktionalitet Alla meddelanden uppfyller schemaregler. Övriga fältregler uttryckta textuellt eller i schematron efterlevs. Storlek på anrop får vara max 5 MB. Tjänstekontrakts-innehåll Deklaration av vilket innehåll som ej stödjs, inklusive samordningsnummer, reservnummer, asylsökande med mera. Infrastrukturkrav Hantering av olika typer av felsvar. Omsändningsrutiner. Samtidiga anrop utan sammanblandning av information. Kommunikation med nationell tjänsteplattform. Anropsfrekvens Sid 7/13

En beräkning av ungefärlig mängd fakturaunderlag som kommer att skickas, och under hur lång tid (batch-körning månadsvis antas). Tjänstekonsumentens validering Tjänstekonsumenten ska själv genomföra kontroll av schema och Schematron för att säkerställa att endast korrekta fakturaunderlag skickas. Dataintegritet Informationsmängden mappar på ett korrekt sätt mot tjänstekontraktet. Ingen förlust eller förvanskning av avlämnad information. Hantering av specialtecken, kända problem, minimalt och maximalt innehåll från verksamhetsperspektiv. Säker kommunikation Säkerställande att RIVTA:s regler kring säker kommunikation uppfylls. Koppling till nationell tjänsteplattform Tester med kommunikation över nationell tjänsteplattform ska göras. Övrigt Om man använder sig av frivilliga element som är viktiga, t.ex. unspecified, så bör dessa anges. Avvikelser Graden av uppfyllnad gentemot tjänstekontrakt analyseras, och man kan bli godkänd med avvikelser, vilka dokumenteras i avvikelsehanteringssystemet, se beskrivningen av testmodellen [1]. Avvikelser kan sedan bedömas som Godkända av den part man etablerar samverkan med. Exempel: Tjänstekonsumenten använder fakturanummer i verksamheten och i fakturor, men levererar inte detta i tjänstekontraktet. Frivilliga element i tjänstekontraktet som inte används inom verksamheten betraktas inte som avvikelser. Avvikelser gentemot tjänstekontraktets schema och Schematron kan inte godkännas. Problem med själva tjänstekontraktet kan rapporteras i tjänstens bitbucket-repository [7] Sid 8/13

3. Verifiering av tjänsteproducent Syftet med denna verifiering är att Inera, i rollen som ansvarigt för regelverket för informationsutbyte och för nationella tjänsteplattformen, ska säkerställa att kraven i tjänstekontrakten uppfylls. Detta ger avsändande part en grund för att kunna lita på att etablering av samverkan kan ske. Den informationsmottagande tjänsteproducenten ska säkerställa att man på ett korrekt sätt kan hantera de varianter av fakturaunderlag som kommer att förekomma i drift. Anslutande part genomför testerna på egen hand, och dokumenterar i anvisad självdeklaration [5]. Denna granskas och godkänns av Inera, men ingen testning utförs av Inera, såvida anslutande part inte avropat detta som stödtjänst. Utvecklingsstöd Stöd för utveckling och egentester i samband med anslutning tillhandahålls genom SoapUI-tester med tillhörande testanvisningar. SoapUI-tester: I releasepaketen för tjänstekontraktet finns det ett SoapUI-projekt med en ProcessClaimSpecification 1.0. Här finns ett antal testfall som ska köras mot tjänsteproducenten (kommunikationen behöver inte gå över nationell tjänsteplattform). 9 testfall (plus två krediteringar) har identifierats av landstingen gemensamt, och i tillägg till dessa finns tester för andra varianter, samt för felhantering. På sikt kan testsviten utökas med kända typiska (godkända) fakturaunderlag från olika källsystem och/eller regioner/landsting. Det finns även en framtagen referensproducent [6], som kan användas som tjänsteproducent för att visa fakturaunderlagen. Självdeklaration I självdeklarationen för tjänsteproducenter, så ska resultaten fyllas i för nedanstående områden. Detta kartlägger tjänsteproducentens uppfyllnadsgrad av tjänstekontraktet. Man måste inte stödja alla varianter av fakturaunderlag. Tjänstekontrakts-funktionalitet Svarsmeddelandet uppfyller schema och Schematron-regler. Fel skall returneras om sänt meddelande är större än 5MB. Tjänstekontrakts-innehåll Deklaration av vilket innehåll som stödjs, inklusive samordningsnummer, reservnummer, asylsökande med mera. Infrastrukturkrav Hantering av felaktiga anrop. Mottagande av samtidiga anrop utan sammanblandning av data. Kommunikation med nationell tjänsteplattform. Belastning Tjänsteproducenten behöver hantera att många fakturaunderlag anländer samtidigt. Sid 9/13

Svarstider Resultat för tester gentemot svarstidskraven som är angivna i TKB (ex. <150 ms för anrop under 1 MB) Tjänsteproducentens validering Tjänsteproducenten ska genomföra kontroll av schema och Schematron för inkommande fakturaunderlag och svara med felkod vid valideringsfel. Dataintegritet Informationslagringen i mottagande system mappar på ett korrekt sätt mot tjänstekontraktet. Ingen förlust eller förvanskning av mottagen eller avlämnad information. Hantering av specialtecken, kända problem, minimalt och maximalt innehåll från verksamhetsperspektiv. Säker kommunikation Säkerställande att RIVTA:s regler kring säker kommunikation uppfylls. SLA-krav Redogörelse för uppfyllnad av de SLA-krav för tjänsteproducenter som finns beskrivna i TKB. Koppling till nationell tjänsteplattform Tester med kommunikation över nationell tjänsteplattform ska göras. Övrigt Om man har problem med frivilliga element, t.ex. unspecified, så bör dessa anges. Avvikelser Graden av uppfyllnad gentemot tjänstekontrakt analyseras, och man kan bli godkänd med avvikelser, vilka dokumenteras i avvikelsehanteringssystemet, se beskrivningen av testmodellen [1]. Avvikelser kan sedan bedömas som Godkända av den part man etablerar samverkan med. Exempel: Tjänsteproducent kan inte ta emot fakturaunderlag för patienter med samordningsnummer. Detta spelar ingen roll för konsumenter som inte skickar fakturaunderlag med samordningsnummer, men är viktigt för konsumenter som gör detta. Avvikelser gentemot tjänstekontraktets schema och Schematron kan inte godkännas. Problem med själva tjänstekontraktet kan rapporteras i tjänstens bitbucket-repository [7] Sid 10/13

4. Etablering av samverkan Syftet med etablering av samverkan i Utomlänsfakturering är att säkerställa att fakturaunderlag kan skickas och tas emot i respektive målmiljö och omgivning, samt öka möjligheterna till en kontrollerad driftsättning. Sammankoppling sker av varje unik kombination av tjänstekonsument och tjänsteproducent. Verifiering i QA-miljön ska göras innan driftsättning och rapporteras till Inera. Anslutande parter bestämmer själva ytterligare omfång på kvalitetssäkring i denna fas och godkänner varandra. Ineras rekommendation är att man granskar varandras självdeklarationer, därefter genomför flödestester tillsammans som inkluderar loggning, behörighetskontroll med mera, se rekommenderad End-2-End-testning [8]. Ingen granskning eller testning utförs av Inera, såvida anslutande part inte avropat detta som stödtjänst. Omfattning (obligatorisk del) Detta ska göras för tjänstekonsument och/eller tjänsteproducent (beroende på vad som ska anslutas): Test av fakturaunderlag med annat landsting i QA-miljön. Test med fakturaunderlag i storleksordningen 5 MB. Omfattning (Ineras rekommendation) Steg ett är att läsa och godkänna respektive självdeklarationer för tjänstekonsument och tjänsteproducent. Avvikelser och unika implementationer bör analyseras, vilket kan medföra ytterligare tester, t.ex. användning av samordningsnummer som tjänstekonsumenten stödjer, men inte tjänsteproducenten. End-2-End-testning sker genom nationell testmiljö och förutsättningarna bör här vara så produktionslika som möjligt, både tekniskt och verksamhetsmässigt. Anropande part bör säkerställa att det som avsänts överensstämmer med det som mottagaren tagit emot. För att helheten ska kunna kvalitetssäkras effektivt, så innehåller End-2-End-underlaget en checklista med områden som man bör begrunda och testa vid behov. Denna checklista omfattar fakturamatchning, loggning, behörighetskontroll, spärrad information, sekretessmarkerade identiteter, felsökning och support. Sid 11/13

5. Regressionstestning och ändringshantering Ändringar ska kommuniceras till Inera i enlighet med Ineras ändringshantering, för beslut om eventuell omverifiering. För tjänsteproducenter kan SoapUI-testsviterna köras på egen hand vid små som stora förändringar. Sid 12/13

6. Referenser [1] Testmodell 2 http:///tjanster/test-och-kvalitatssakring/ [2] Tjänstedomän Utomlänsfakturering http://rivta.se/domains/financial_billing_claim.html [3] Ineras personuppgiftstjänst http:///tjanster--projekt/personuppgiftstjansten/ [4] Självdeklaration Verifiering av tjänstekonsument Utomlänsfakturering (ligger i TK-paketet) [5] Självdeklaration Verifiering av tjänsteproducent Utomlänsfakturering (ligger i TK-paketet) [6] Repository för referensproducent - https://bitbucket.org/rivta-profiles/refapp-producerprocessclaimspecification [7] Ärendehantering och versionshantering https://bitbucket.org/rivtadomains/riv.financial.billing.claim [8] Rekommenderad End-2-End-testning Utomlänsfakturering Sid 13/13