RIVTA on FHIR - PoC-rapport

Version PA5

Inledning

Denna rapport beskriver utfallet av FHIR Proof-of-concept. Uppdraget beskrivs här: RIVTA on FHIR. Rapporten är tänkt att kunna utgöra basen för en svensk implementationsguide för FHIR i den nationella samverkansarkitekturen. Den beskriver motsvarigheten till RIV Tekniska Anvisningar 2.1 Basic Profile och de generella/ramverksorienterade delarna av tjänstekontrakten som sammantaget brukar kallas "journal- och läkemedelskontrakten". Dessa kontrakt syftar till återanvändning av befintlig journalinformation. I denna rapport används GetObservations som ett exempel.

Slutsatser och rekommendation

Det har varit relativt rättframt att beskriva hur FHIR-standarden kan införas som en RIV-TA-profil. Acceptanskriterierna i uppdraget är uppfyllda. Rekommendationen blir därför att gå vidare med implementation av en FHIR-förmåga i nationella arkitekturen enligt förslaget i uppdragsbeskrivningen. 

Genomförandeprojektet behöver koordineras med release av ny FHIR-version. Nuvarande version av standarden är DSTU3. Den version som är under utveckling benämns R4. Den nuvarande versionen brister i stödet för nationell användning av FHIR. Denna rapport beskriver bristerna och hur man kan kompensera för dem i DSTU3 med hjälp av olika standardiserade konfigurations- och utökningsmekanismer. Men det får konsekvenser i form av bristande kompatibilitet med FHIR-applikationer som utvecklas oberoende av den svenska tillämpningen av FHIR. Samtliga brister vi identifierat i DSTU3 är åtgärdade i R4. Därför bör en avvägning göras rörande vilken version som Inera ska satsa på i relation till tidsplanen för R4.

REST eller Messaging

FHIR skiljer mellan protokoll och innehåll. Två huvudprotokoll specas: REST och Messaging. För GetObservations handlar det om att tillgängliggöra befintligt data vilket  mappar väl mot en läsning av en FHIR-resurs med hjälp av REST. GetObservations används av såväl sessionshållande tjänstekonsumenter med behov av synkron request-response (RIV-TA Fråga-Svar) som tillståndshållande tjänstekonsumenter (RIV-TA Fråga-Svar, Informationsspridning och Uppdrag-Resultat). 

Exempel på Sessionshållande konsumenter: Journalen, NPÖ, NKRR

Exempel på tillståndshållande tjänstekonsumenter: journalsystem som hämtar observationer från SoB efter att ha blivit notifierad av Stöd- och behandlingsplattformen (SoB).

REST-ansatsen i FHIR kan - liksom RIVTA Fråga-Svar, användas när tjänstekonsumenten vill hantera interaktionen synkront (begäran och svar i samma kommunikationskanal). Messaging kan användas för alla slags behov. Messaging är dock en mer tung-administrerad ansats eftersom ett Messaging-utbyte förutsätter att ett "event" definieras för varje messaging-interaktion. En messaging-interaktion består - till skillnad mot en REST-interaktion - dessutom av två profiler: en för "sender" (RIVA-TA: initiativtagare) och en för "destination" (RIV-TA: Utförare). Profilen för "sender" beskriver begäran + kvittens för mottagen begäran. Profilen för "destination" beskriver begäran + kvittens för det resultat som "destination" skickar till "sender" som konsekvens av mottaget meddelande. For en REST-interaktion behövs bara en profil - antingen för inmeddelande eller utmeddelande - beroende på om det är en frågande eller uppdaterande interaktion. 

Oavsett om REST eller Messaging används, kan all metadata beskrivas i ett "CapabilityStatement" med underliggande "StructureDefinition". 

Till skillnad mot RIV-TA stödjer Messaging i FHIR både synkrona och asynkrona meddelandeutbyten oavsett vilken interaktionstyp som används, med undantag av Informationsspridning eftersom det då saknas svar. Följande tabell sammanfattar relation mellan RIV-TA protokoll-arkitektur och FHIR Messaging:

Rekommendationen blir att använda FHIR-REST när det är tillämpbart och att använda messaging när det är nödvändigt, alternativt när det finns en definierad event-typ för messaging i FHIR-standarden som motsvarar användningsfallet. Men i det generella fallet bör strävan vara att följa internationellt etablerade profiler, oavsett om de är baserade på messaging eller REST.

Det innebär att GetObservations ska ersättas av en REST-baserad FHIR-användning. Det rimmar också väl med den grundläggande intentionen för FHIR Messaging. Den som sammanfattas så här av HL7:

"In FHIR messaging, a "request message" is sent from a source application to a destination application when an event happens. Events mostly correspond to things that happen in the real world. The request message consists of a Bundle identified by the type "message", with the first resource in the bundle being a MessageHeader resource. The MessageHeader resource has a code - the message event - that identifies the nature of the request message, and it also carries additional request metadata. The other resources in the bundle depend on the type of the request." (http://www.hl7.org/implement/standards/fhir/messaging.html).

Vi gör därför tolkningen att messaging inte är avsett för vårt användningsfall (att sammanställa tillväxtinformation baserat på GetObservations-anrop). Nedan illustreras några andra användningsfall där vi bedömer att messaging kan vara mer ändamålsenligt än REST:

Versionshantering

Det finns många perspektiv på versionshantering. I detta sammanhang avgränsas frågan till framåt- och bakåtkompatibilitet mellan två systemagenter som utbyter information enligt en överenskommen FHIR-profil, men där den ena systemagenter är anpassad för en senare version av profilen än den andra. Syftet med regelverket är att framåt- och bakåtkompatibilitet mellan två agenter alltid ska vara förutsägbar. RIVTA beskriver den grundläggande strategin för framåt- och bakåtkompatibilitet i RIV Tekniska Anvisningar Översikt. Nictiz har dokumenterat en snarlik versionsstrategi för nederländerna: https://informatiestandaarden.nictiz.nl/wiki/FHIR_Profiling_Guidelines#Canonical_URL.

Det finns också en generell rekommendation i FHIR-standarden om att profilers kanoniska namn ska innehåll profilens huvud-version.

Följande tabell sammanfattar regler i RIV TA Basic Profile 2.1 och hur vi valt att mappa dem till FHIR.

Mapping till nationell samverkansarkitektur

Tabellen nedan sammanfattar en mappning av protokoll–påverkande koncept i den nationella samverkansarkitekturen.

Användning av referenser till relaterade resurser

För att FHIR-baserade kontrakt ska kunna samexistera med kontrakt som ligger kvar på Basic Profile 2.1 (SOAP), behöver referenser från en informationsresurs till en annan uttryckas på logiskt nivå, istället för genom direkta eller relativa URL:er. URL-referenser skulle förutsätta att refererad informationsmängd är åtkomlig som FHIR-resurs. Det skulle därmed motverka målet med en stegvis övergång till FHIR.

Genom att istället använda s.k. logiska referenser (id-referenser) kan andra informationsmängder refereras på ett protokoll-oberoende sätt. Logiska referenser ska enligt FHIR-standard byggas upp på samma sätt som en Identifier-typ. Det innebär att man anger identifieringssystemets URI och värdet på identifieraren. Det motsvarar hur referenser hanteras i våra nuvarande tjänstekontrakt, i form av de-facto-datatypen IIType. Det innebär att våra nuvarande regler för värden på IIType kan tillämpas även vid en övergång till FHIR. 

Exempel - patient-referens i GetObservations respektive FHIR Observation

<personPatientId>
   <root>1.2.752.129.2.1.3.1</root>
   <extension>191212121212</extension>
</personPatientId>

<subject>
    <identifier>
       <system value="urn:oid:1.2.752.129.2.1.3.1"/>
       <value value="191212121212"/>
    </identifier>
</subject>

Exempel - vårdkontakt-referens i GetObservations respektive FHIR Observation

I dagsläget avviker GetObservations och GetActivities från övriga nationella tjänstekontrakt för uttag av data ur journalsystem i det att de är modellerade efter NI istället för standardmetoden Green CDA. Därför saknas den för övriga tjänstekontrakt standardiserade möjligheten att söka efter journaluppgifter baserat på en vård- och omsorgskontakt. Exemplet nedan är därför hämtat från tjänstekontraktet GetDiagnosis 2.0, men skulle lika gärna kunnat vara hämtat från GetCareDocumentation, GetMedicationHistory eller något av övriga Green CDA-baserade tjänstekontrakt.

  <sourceSystemHSAId>SE162321000065-B08</sourceSystemHSAId>
  <careContactId>1111444</careContactId>

 <context>
    <identifier>
       <type>
          <coding>
             <system value="http://hl7.org/fhir/resource-types"/>
             <code value="Encounter"/>
          </coding>
       </type>
       <system value="SE162321000065-B08"/>
       <value value="1111444"/>
    </identifier>
</context>

Exempel - Vårdenhetsreferens i GetObservations respektive FHIR Observation

<careUnitId>
    <root>1.2.752.129.2.1.4.1</root>
    <extension>4444</extension>
</careUnitId>

<performer>
    <identifier>
        <type>
           <coding>
              <system value="http://hl7.org/fhir/v2/0203"/>
              <code value="XX"/>
              <display value="Vårdenhet"/>
           </coding>
        </type>
        <system value="urn:oid:1.2.752.129.2.1.4.1"/>
        <value value="4444"/>
    </identifier
</performer>

Att söka baserat på referenser

Den version av FHIR som var aktuell under projektet benämns DSTU3. I den versionen kan referenser anges med hjälp av logiska identifierare (beskrivs ingående i förgående avsnitt), men det finns inget inbyggt stöd för att söka efter resurser baserat på sådana referenser. Behovet att söka på identifierare är grundläggande. Det kan t.ex. gälla att hitta alla resurser som är kopplade till en patient. Sådan sökning är grunden för samtliga nationella tjänstekontrakt som handlar om att ge tillgång till befintlig journalinformation - t.ex. GetObservations. Bristen åtgärdas i kommande version av FHIR - R4.

FHIR erbjuder en utökningsmekanism som kan användas för att införa sådant stöd redan i nuvarande version. Syntaxen för en sökning blir dock annorlunda mot när stödet är infört i standarden. Effekten blir att applikationer som byggs för DSTU3 kan behöva ändras för att vara interoperabel med en server som använder R4.  

Utökningarna som görs för DSTU3, kan även tillämpas i R4 för att upprätthålla kompatibilitet med klienter som ligger kvar på DSTU3 efter att en server uppgraderats till R4.

Ett senare avsnitt i rapporten beskriver hur utökningsmöjligheten används av referensapplikationen för att möjliggöra sökning efter observationer baserat på patientens identitet, en vårdenhet och en vård- och omsorgskontakt.

Mapping till JoL-kontraktet Get Observations

GetObservations 2.0 mappas till en tänkt svensk bas-profil för Observationsresursen. Eftersom förstudien är avgränsad till att hämta observationer med FHIR, mappas inte refererade resurser, så som Person (patient). De enda resurser som nappas är det som behövs för att motsvara information som hanteras inom GetObservations. Den tänkta konsumenten kommer med andra ord att behöva använda observationsresursen i kombination med befintliga RIVTA-kontrakt (t.ex. GetPerson) för att kunna visualisera en tillväxtkurva.

<TODO: inled med en grafisk modell - ex Gliffy -  som visar vilka resurser (profiler) som används av observationsprofilen och hur de relaterar till varandra. 

Mappningsdokumentet finner du här. Detta är informationsspecifikationen för kontraktet där man ser hur vi mappat från till FHIR per klass och attribut.

Strategi för Argonaut VitalSigns (Apple etc)

Vi har diskuterat hur man kan förhålla sig till det s.k. Agronaut-projektet. Projektet drivs av ett amerikanskt industrikonsortium. Det utvecklar FHIR-profiler och implementationsriktlinjer i syfte att skapa en bas för grundläggande, interoperable informationsutbyte inom prioriterade områden. Man kan tycka att FHIR är en standard och att det borde räcka. Men FHIR lämnar utrymme för val av kodverk. Interoperabilitet uppnås först när kommunicerande parter är överens om vilka kodverk som ska tillämpas. Genom FHIR-profiler blir sådana överenskommelser formaliserade och tekniskt validerbara för system som utbyter information. FHIR erbjuder också stor funktionell flexibilitet. Det gäller t.ex. hur sökningar kan utföras, händelser kan monitoreras och hur refererade resurser kan sampaketeras. V

ariationerna är så stora att det knappast är möjligt att förlita sig på att alla kommunicerande parter stödjer alla variationer som erbjuds av standarden. Många av dessa tekniska variationer kan preciseras/begränsas genom användningen av FHIR-profiler. Men i vissa fall behöver maskintolkbara begränsningar i form av FHIR-profiler kompletteras med riktlinjer i form av ostrukturerad text som utvecklare behöver följa. Sådana riktlinjer benämns "Implementation Guidelines" i FHIR-sammanhang. Argonaut-projektet publicerar därför både riktlinjer och profiler. Genom att samarbeta kring en minsta gemensamma nämnare, skapar Argonaut-medlemmarna förutsättningar för en gemensam avgränsad del med brett stöd i industrin. Arbetet har uppbackning av de stora systemleverantörerna i USA samt av Apple. Vissa delar av arbetet förvaltas av HL7 som en del av standarden och benämns "US Core".

Apple har just lanserat en ny version av sitt telefon-burna datalager för personlig hälso-information. Den nya versionen kan även lagra information enligt informationsstrukturen i FHIR. Den delen av datalagret ("Health Records")är tänkt att lagra data som envägs-synkroniseras från journalsystem till telefonen.  Uppgifterna hämtas från journalsystem genom att göra anrop från telefonen enligt FHIRs informatik och REST-protokoll samt enligt säkerhetsmodeller som beskrivs av ett annat industri-samarbete: SMART on FHIR. Apples stöd för "Health records" är så länge geografiskt avgränsat till USA. 

Argonaut och Apple använder idag DSTU2-baserade profiler (en tidigare FHIR-version). Innan det blir aktuellt för Apple att ansluta europeisk vårddata tror vi att Apple kommer att ha uppgraderat till DSTU3 eller senare. Fr.o.m. DSTU3 ingår de profiler Apple använder sig av i FHIR-standarden och benämns där "US Core". Dessa profiler kan inte tillämpas generellt i Sverige på grund av de inte klarar matchning mot svensk lagstiftning (via Socialstyrelsens NI) och inte hanterar referenser baserat på identifierare. Vi har bedömt att profilerna troligen kan användas för att lämna ut information till individen/patienten. Det kan därför vara av strategiskt intresse att inrätta en nationell anpassningstjänst som möjliggör anslutning av SMART on FHIR-applikationer (så som Apple Health Records) till journalsystem som stödjer svenska basprofiler för FHIR. Men också att genom nationella transformeringstjänster möjliggöra anpassning av befintliga producenter till Journalen,  att uppträda som FHIR-producenter. Det skulle t.ex. möjliggöra anslutning av befintliga tjänsteproducenter för tjänstekontrakten GetDiagnosis, GetLaboratoryOrderOutcome och GetMedicationHistory till patient/individ-centrerade SMART on FHIR-applikationer i allmänhet och Apple Health Records i synnerhet.

Det finns olika vägar att gå för att nå dessa mål:

1. De svenska profilerna är sub-profiler till US Core-profiler
2. Svenska profiler mappas till US Core
3. Sverige standardiserar på att både de svenska och US Core ska stödjas paralelllt av prodcuenter 

Det finns några faktorer som kan påverka valet av strategi:

• US Core kan bara användas för patientåtkomst i Sverige. Det saknas informatik/säkerhetsramverk för att kunna tillämpas för Sammanhållen Journalföring. 
• US Core använder LOINC-kodverket för kliniska kodning. I Sverige används SNOMED.
• US Core saknar stöd för förutsägbar framåt/bakåtkompatibilitet vilket är krav i flera nationella sammanhang - t.ex. i Sverige och i Nederländerna.
• US Core är ett protokoll som främst är avsett för en applikations kontakt med sin direkta server. De svenska profilerna ska stödja uttag av grunddata från system som befinner sig "bakom" ett specifikt klient-skydd (exempelvis en fasad för patient-applikationer)
• Svenska profiler har krav på strukturerad data för t.ex. organisationsidentitet medan US Core tillåter data utan att ange extern identitet
• FHIR stödjer ännu inte s.k. Mix-ins (eller "Aspects"). Konsekvensen är att allt som vi i Sverige behöver ha gemensamt för ex. Observationer - måste - om vi ärver av US Core - dupliceras på varje svensk subclass till varje US Core-subklas av observation - ex. BodyWeight, BodyHeight etc. 

Sammantaget leder dessa faktorer oss att gå på alternativ 2 - mappning. De informativa sambanden beskrivs i figuren nedan.

En upphandlad FHIR-Server (journalsystem eller extern anpassningstjänst) ska stödja de svenska profilerna (SNOMED). Om journalsystemet är en produkt som redan har stöd för US Core och upphandlas med stöd för svenska profiler, innebär det att systemet i sig har stöd för båda. I vart fall semantiskt. Säkerhetshantering för patient-tjänster kan komma att kravställas utgående från 1177/IDP etc, medan professionsanvändare troligen autentiseras i regional infrastruktur. Om ett system är upphandlat med krav på svenska profiler (SNOMED), kan transformation ske i en nationell eller regional nod (mellanliggande FHIR-server) som tillämpar mappningsreglerna (SE→US Core mapping).

Följande skiss illustrerar hur transformationstjänster kan användas för att tillgängliggöra information från system med stöd för svenska profiler och tjänstekontrakt till en US Core-klient . Arkitekturen beskrivs principiellt. Tjänsteplattformen, regionala tjänsteplattformar och annan infrastruktur är utelämnad. Arkitekturen föreskriver inte något specifikt alternativ, utan ska stödja olika uppsättningar och kombinationer av dem. 

Tillämpning

I detta avsnitt illustreras hur framtagna FHIR-profiler kan användas för att sammanställa tillväxtinformation baserat på kroppsvikt, kroppslängd och huvudomfång. Exemplen är framställda genom att använda den referensapplikation som växt fram under arbetet. 

Hämta tillväxtinformation baserat på patient-identitet

Att hämta information om en patient för en viss klinisk vitalparameter (kroppslängd)

REST-url:

[server]/Observation?subject-identifier=urn:oid:1.2.752.129.2.1.3.1|191212121212&code=http://snomed.info/sct|27113001&category=vital-signs&_profile=http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyWeight

Svarsmeddelande (JSON):

{
  "resourceType": "Bundle",
  "id": "830bdf24-59a7-4752-ba56-1e3f2f30b5ec",
  "meta": {
    "lastUpdated": "2018-07-06T18:00:39.257+02:00"
  },
  "type": "searchset",
  "total": 1,
  "link": [
    {
      "relation": "self",
      "url": "http://localhost:8080/hapi/baseDstu3/Observation?_profile=http%3A%2F%2Frivta.se%2Ffhir%2FStructureDefinition%2Fcore%2Fse-core-vitalsigns-v1%2FBodyHeight&category=vital-signs&subject-identifier=urn%3Aoid%3A1.2.752.129.2.1.3.1%7C191212121212"
    }
  ],
  "entry": [
    {
      "fullUrl": "http://localhost:8080/hapi/baseDstu3/Observation/3",
      "resource": {
        "resourceType": "Observation",
        "id": "3",
        "meta": {
          "versionId": "1",
          "lastUpdated": "2018-07-06T17:53:29.465+02:00",
          "profile": [
            "http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyHeight"
          ],
          "security": [
            {
              "system": "http://hl7.org/fhir/v3/ActReason",
              "code": "PATRQT",
              "display": "ApprovedForPatient"
            }
          ]
        },
        "extension": [
          {
            "url": "http://rivta.se/fhir/StructureDefinition/core/se-core-extentions/Source-v1",
            "valueString": "SE162321000065-B08"
          }
        ],
        "status": "final",
        "category": [
          {
            "coding": [
              {
                "system": "http://hl7.org/fhir/observation-category",
                "code": "vital-signs"
              }
            ]
          }
        ],
        "code": {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "27113001"
            }
          ]
        },
        "subject": {
          "identifier": {
            "system": "urn:oid:1.2.752.129.2.1.3.1",
            "value": "191212121212"
          }
        },
        "context": {
          "identifier": {
            "type": {
              "coding": [
                {
                  "system": "http://hl7.org/fhir/resource-types",
                  "code": "Encounter",
                  "display": "Vård- och omsorgskontakt - lokalt id"
                }
              ]
            },
            "system": "SE162321000065-B08",
            "value": "1111444"
          }
        },
        "effectiveDateTime": "2007",
        "performer": [
          {
            "identifier": {
              "type": {
                "coding": [
                  {
                    "system": "http://hl7.org/fhir/v2/0203",
                    "code": "PRN",
                    "display": "organisationsenhet"
                  }
                ]
              },
              "system": "urn:oid:1.2.752.129.2.1.4.1",
              "value": "3211444"
            }
          },
          {
            "identifier": {
              "type": {
                "coding": [
                  {
                    "system": "http://hl7.org/fhir/v2/0203",
                    "code": "EN",
                    "display": "Vårdgivare"
                  }
                ]
              },
              "system": "urn:oid:1.2.752.129.2.1.4.1",
              "value": "2222"
            }
          },
          {
            "identifier": {
              "type": {
                "coding": [
                  {
                    "system": "http://hl7.org/fhir/v2/0203",
                    "code": "XX",
                    "display": "Vårdenhet"
                  }
                ]
              },
              "system": "urn:oid:1.2.752.129.2.1.4.1",
              "value": "4444"
            }
          },
          {
            "identifier": {
              "type": {
                "coding": [
                  {
                    "system": "http://hl7.org/fhir/v2/0203",
                    "code": "PN",
                    "display": "Personnummer"
                  }
                ]
              },
              "system": "urn:oid:1.2.752.129.2.1.4.1",
              "value": "1912121212"
            }
          }
        ],
        "valueQuantity": {
          "value": 173,
          "unit": "cm",
          "system": "http://unitsofmeasure.org",
          "code": "cm"
        }
      },
      "search": {
        "mode": "match"
      }
    }
  ]
}