VGR-SE Reimbursement Implementation Guide
0.8.0 - qa Sweden flag

This page is part of the VGR Reimbursement Implementation Guide (v0.8.0: QA Preview) based on FHIR (HL7® FHIR® Standard) R4. No current official version has been published yet. For a full list of available versions, see the Directory of published versions

Designval

Betalningsförbindelse

Ett centralt koncept i användningsfallet Identifiera betalare är Betalningsförbindelse. En Betalningsförbindelse är i detta sammanhang en juridisk överenskommelse där en aktör (Utfärdare av betalningsförbindelse) förbinder sig att ersätta kostnader för utförd vård.

För att följa informationsstrukturen i FHIR för ekonomisk ersättning i samband med en vårdkontakt modelleras detta i IG:n på följande sätt:

  • Encounter innehåller en referens till Account ("Tracks balance, charges, for patient or cost center")
  • Account har som enda syfte att i sin tur referera till Coverage ("Insurance or medical plan or a payment agreement")
  • Coverage speglar en Betalningsförbindelse

Exempel på en vårdkontakt med betalningsförbindelse utfärdad av ett försäkringsbolag.

Coverage.type

För att särskilja en Betalningsförbindelse från andra typer av ekonomisk överenskommelse används Coverage.type med det tillämpningsspecifika kodverket TypeOfCoverage, som endast innehåller en (1) kod som anger Betalningsförbindelse.

Coverage.payor

Eftersom scenariot inte kan förutsätta att den utfärdande aktören är unikt identifierbar, används en statisk platshållare (VGRPayorOrganizationPlaceholder) för det obligatoriska elementet Coverage.payor. Se vidare nedan om hur Utfärdare av betalningsförbindelse anges med det tillämpningsspecifika kodverket UtfardareAvBetalningsforbindelse.

Inbäddade resurser

Account+Coverage+VGRPayorOrganizationPlaceholder skall i denna tillämpning representeras som inbäddade resurser i Encounter.

Utfärdare av betalningsförbindelse

Information om vem som utfärdat betalningsförbindelsen har efterfrågats av verksamheten. Samma information behövs också för att hålla isär olika betalningsförbindelser som av en slump fått samma ID hos olika utfärdare.

Informationen representeras idag genom ett kodverk som består av blandade typer; två organisationer, en typ av organisation och en lista över län. IG:n har utvecklats för att kunna använda det kodverk som tillhandahållits, på sikt vore det bra att istället använda en lista av identifierade organisationer.

Olika alternativ för hur kodverket med utfärdare av betalningsförbindelse ska hanteras i profilen har utvärderats. Det antas att IDt på betalningsförbindelsen (.identifier.value) utfärdats av samma organisation som utfärdat betalningsförbindelsen.

alternativ 1

Coverage.payor har datayp Reference:Organization. Den ersätts i R5 av paymentBy.party som också har datatyp Reference:Organization. Här vore det möjligt att peka direkt på en enskild organisation om den informationen fanns. Det är dock inte självklart att samma organisaton som utfärdat betalningsförbindelsen också ska betala.

alternativ 2

Coverage.identifier håller betalningsförbindelsens ID. Elementet är en komplex datatyp och innehåller .value som bär själva värdet samt ytterligare element med information om värdet.
En fördel med att hålla utfärdare inom elementet Coverage.identifier är att det då går att skilja två numeriskt identiska IDn från olika betalningsutfärdare från varandra.

alternativ 2a

Coverage.identifier.system med datatyp uri pekar på den som utfärdat IDt via den namnrymd varifrån IDt kommer. Detta är rätt informationsmängd men fel format.

alternativ 2b

Coverage.identifier.assigner med datatyp Reference:Organization pekar på den som utfärdat IDt. Reference-datatypen innehåller utöver referens till elementet den hänvisar till (i detta fall Organization) även .display.

alternativ 2c

Coverage.identifier.assigner med datatyp Reference:Organization pekar på den som utfärdat IDt. Reference-datatypen innehåller utöver referens till elementet den hänvisar till (i detta fall Organization) även .assigner. Men enligt FHIRs regelverk ska en assigner peka på något som representeras av en instans av aktuell resurs, alltså en Organization, varför det inte går att ha ett kodverk här.

alternativ 3

Ett alternativ är att göra en extension för "utfärdare av betalningsförbindelse". En extension kräver ytterligare utveckling av de inblandade systemen. Extension ger en krispare beskrivning av informationen, men detta går delvis förlorat med nuvarande kodverk.

valt alternativ

Alternativ 2b, Coverage.identifier.assigner.display, har valts.
Information ligger på .identifier.assigner.display trots att .display inte är avsett för maskinell tolkning.

Mål-lösningen är att använda alternativ 1 eller alternativ 3, det senare om det behövs hållas isär information om utfärdare och betalare.

Verksamhetsområde

Information om det verksamhetsområde där ett vårdtillfälle genomfördes krävs för verksamhetsuppföljning, främst för korrekt ersättning men även för annan uppföljning. Det pågår nationella diskussioner kring både vilket kodverk och vilket element som ska användas för denna information, se (branch Organization-type)[https://build.fhir.org/ig/HL7Sweden/basprofiler-r4/branches/organization-type-v2.0.0/].

Val av kodsystem

Det finns flera kodverk som beskriver verksamhetsområden i Sverige:

  • Socialstyrelsen förvaltar kodverket Verksamhetsområden som används för rapportering av kvalitetsdata till nationella kvalitetsregister
  • Inspektionen för vård och omsorg (IVO) har ett kodsystem som beskriver vårdorganisationer och som används vid rapportering av avvikelser eller registrering av klagomål.
  • Inera tillhandahåller HSA Verksamhetskoder.

Det pågår arbete med att slå samman dessa kodsystem. De svenska basprofilerna (Swedish Base Profiles) har valt att använda Ineras HSA Verksamhetskoder.

VGR tog fram ett regionalt kodsystem i samband med konfigurationen av Millennium, inom PAS-arbetsströmmen, kallat VGRKV_MVO. Kodsystemet består av koder från Socialstyrelsens kodsystem (MVO), ett kodsystem som används inom primärvården i VGR samt vissa duplicerade MVO-koder för att hantera att Millennium inte kan hantera samma kod i två olika moduler.

Denna IG är utvecklad för att samla in data från Millennium och använder därför VGRKV_MVO. På sikt är målet att migrera till det nationellt valda kodsystemet.

Val av element

En organisation kan tillhandahålla flera typer av vård parallellt, och informationen måste därför vara kopplad till det aktuella vårdtillfället. Det finns ingen svensk basprofil för Encounter. VGR har valt att använda Encounter.servicetype. I R4 är detta ett CodeableConcept med ett exempel på kodsystem. I R5 har detta ändrats till en Codable.Reference som använder HealthCareService.

Det pågår nationella diskussioner om vilket element i profilerna Organization och HealthCareService som ska användas för att beskriva typ av vård.

In English - work in progress

Issuer of Payment Commitment (Utfärdare av betalningsförbindelse)

Information about who issued the payment commitment is required for the business case. It is also needed to distinguish between different payment commitments that, by coincidence, have received the same ID from different issuers.

This information is currently represented using a code system consisting of mixed types: two specified organizations (Sahlgrenska International Care and Tobiasregistret), one type of organization (Insurance Company), and a list of counties (=län). The IG has been developed to allow use of the provided code system; in the long term, it would be preferable to use a list of identified organizations instead.

Different options for how the code system for issuers of payment commitments could be handled in the profile have been evaluated. It is assumed that the ID of the payment commitment (.identifier.value) is issued by the same organization that issued the payment commitment.

Option 1

Coverage.payor has the data type Reference:Organization. In R5, this is replaced by paymentBy.party, which also has the data type Reference:Organization. This would make it possible to point directly to a specific organization if that information were available. However, it is not necessarily the case that the same organization issuing the payment commitment is also the one responsible for payment.

Option 2

Coverage.identifier contains the ID of the payment commitment. The element is a complex datatype and includes .value, which carries the actual value, as well as additional elements with information about the value. One advantage of keeping the issuer information within Coverage.identifier is that it allows two numerically identical IDs from different payment issuers to be distinguished from each other.

Option 2a

Coverage.identifier.system, with datatype uri, points to the issuer of the ID via the namespace from which the ID originates. This reflects the correct information content but uses the wrong format.

Option 2b

Coverage.identifier.assigner, with datatype Reference:Organization, points to the entity that issued the ID. We assume (See above) that this is also the issuer for the Payment Commitment. In addition to the reference to the Organization element, the Reference datatype also contains .display.

Option 2c

Coverage.identifier.assigner, with the data type Reference:Organization, points to the entity that issued the ID. We assume (See above) that this is also the issuer for the Payment Commitment. In addition to the reference to the element it refers to (in this case Organization), the Reference datatype also contains .assigner. However, according to FHIR rules, an assigner must point to something that is represented by an instance of the relevant resource type — in this case an Organization. Therefore, it is not possible to use a code system here.

Option 3

Another alternative is to create an extension for “issuer of payment commitment.” An extension requires additional development in the involved systems. Extensions provide a clearer description of the information, but this benefit is partly lost with the current code system.

Chosen option

Option 2b, Coverage.identifier.assigner.display, has been chosen. The information is placed in .identifier.assigner.display even though it is not intended for machine interpretation.

The target solution is to use Option 1 or Option 3, the latter if issuer and payer information needs to be kept separate.

Service area (verksamhetsområde)

Information on the serivce area (verksamhetsområde) in which an encounter was performed is required for the business case, mainly for correct reimbursement, but also for other follow-up. There are ongoing discussions at the national level regarding both which element to use and which codesystem to use for this information.

Choice of CodeSystem

There are several code systems describing service areas in Sweden. The National Board of Health and Welfare maintains a code system called Verksamhetsområden used for reporting quality data to national quality registries. The Health and Social Care Inspectorate (IVO) has a code system that describes health care organisations and is used when reporting irregularities or registering complaints. Inera provide HSA Verksamhetskoder. There is ongoing work to merge these. The Swedish Base Profiles have chosen to use Ineras HSA Verksamhetskoder.

VGR has made a regional code system during the configuration of Millennium, by the PAS workstream, called VGRKV_MVO. The code system consists of codes from the National Board of Health and Welfare’s CodeSystem (MVO), a code system used in primary care within VGR, and some duplicates of MVO codes to account for the fact that Millennium cannot manage the same code in two different modules.

This Implementation IG is developed to collect data from Millennium and thus uses VGRKV_MVO. In the future, the aim is to migrate towards the chosen national code system.

Choice of element

An organisation can provide several types of care in parallel; thus, the information must be linked to the encounter in question. There is no Swedish Base Profile for Encounter. VGR has chosen to use Encounter.servicetype. In R4, this is a CodeableConcept with an example CodeSystem. In R5, this is changed to a Codable.Reference using HealthCareService. Discussions are ongoing at the national level about which element of the Organization and HealthCareService profiles to use for the type of care.