FHIR PoC Kliniska modeller Rapport

Version PA2

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 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.

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

<engelska - ur dialog  med Firely - ska översättas>Our initial use-case is to have a mixed portfolio with the focus of adding FHIR resources when we are missing an API in our portfolio, or when we need to do a new major of an existing (SOAP) API. Since we - in either case - will break/introduce new interfaces, we do it by introducing FHIR profiles. At some point in time we will add a national OAUTH Gateway for US Core (in the planning) that will map/transform existing SOAP services so that all existing SOAP back-ends can be re-used. At some point in time, when all existing SOAP API:s (those that are relevant to replace with FHIR counterparts) have had requirements for breaking changes (backwards compatibility not possible) then all API:s will - in its latest major - be FHIR-based.

For such a migration to be manageable, a strategy for referencing between resources need to be in place. To our understanding, there is only one option: Use either contained resources or identifier references (logical identifiers). </engelska>

För att FHIR-baserade kontrakt ska kunna samverka 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 URL:er. Logiska referenser ska enligt FHIR-standard byggas upp av namnet på den resurs i FHIR som motsvarar informationen följt av identiteten i det lokala systemet. Om en observation som hämtas med FHIR (användningsfallet i denna PoC) refererar till en vårdkontakt (exempelvis) ska referensen anges som "Encounter/<id i källsystemet". Om klienten ska hämta information om vårdkontakten behöver den använda tjänstekontraktet GetCareContacts med sökparametrarna sourceSystemHsaId (från Observation.source), vårdkontakt-id (från <id i källsystemet> ur referensen) och patientens identitet (ur Observation.subject). När GetCareContacts finns i form av en profil för resursen Encounter, kommer motsvarande parametrar att användas för att uttrycka en sök-URL för den eftersökta vård- och omsorgskontakten.

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, kappas 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 de s.k. Agronaut-projektet. Det är profiler och guidelines som utvecklas av ett amerikanskt industrikonsortium, i syfte att skapa en bas för grundläggande, interoperable informationsutbyte inom prioriterade områden. FHIR som standard ger många möjligheter. Troligen kommer mycket få journalsystem att någonsin stödja samtliga möjligheter som FHIR-standarden erbjuder. 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". Men med patienten som aktörDessa profiler kan inte tillämpas generellt i Sverige på grund av de inte klarar matchning mot svensk lagstiftning (via Socialstyrelsens NI). 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 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ämpa 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. Den logiska arkitekturen beskrivs principiellt i nedanstående figur. Tjänsteplattformen, regionala tjänsteplattformar  och annan infrastruktur är utelämnad.

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 olika alternativ. 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

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

REST-url:

[server]/Observation?subject=urn:oid:1.2.752.129.2.1.3.1%7C191212121212&code=http://snomed.info/sct%7C27113001&category=vital-signs&_profile=https://www.inera.se/FHIR/StructureDefintion/PoC-Observation-BodyWeight

Svarsmeddelande (JSON):

{
  "resourceType": "Bundle",
  "id": "20cdddeb-3d00-4a0c-aefa-a6417541ac0a",
  "meta": {
    "lastUpdated": "2018-06-04T14:34:01.571+02:00"
  },
  "type": "searchset",
  "total": 1,
  "link": [
    {
      "relation": "self",
      "url": "http://localhost:8080/hapi/baseDstu3/Observation?_profile=https%3A%2F%2Fwww.inera.se%2FFHIR%2FStructureDefintion%2FPoC-Observation-BodyWeight&category=vital-signs&code=http%3A%2F%2Fsnomed.info%2Fsct%7C27113001"
    }
  ],
  "entry": [
    {
      "fullUrl": "http://localhost:8080/hapi/baseDstu3/Observation/54957",
      "resource": {
        "resourceType": "Observation",
        "id": "54957",
        "meta": {
          "versionId": "1",
          "lastUpdated": "2018-06-04T14:05:37.731+02:00",
          "profile": [
            "https://www.inera.se/FHIR/StructureDefintion/PoC-Observation-BodyWeight"
          ]
        },
        "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"
          }
        },
        "effectiveDateTime": "2007",
        "performer": [
          {
            "identifier": {
              "system": "urn:oid:hsaoid",
              "value": "Performer/3211444"
            }
          }
        ],
        "valueQuantity": {
          "value": 1700,
          "unit": "g",
          "system": "http://unitsofmeasure.org",
          "code": "g"
        },
        "comment": "med kläder"
      },
      "search": {
        "mode": "match"
      }
    }
  ]
}

{
  "resourceType": "Bundle",
  "id": "9ac3dfaa-20ac-40d6-ad52-30a4c68ecf81",
  "meta": {
    "lastUpdated": "2018-06-04T14:38:16.351+02:00"
  },
  "type": "searchset",
  "total": 1,
  "link": [
    {
      "relation": "self",
      "url": "http://localhost:8080/hapi/baseDstu3/Observation?_profile=https%3A%2F%2Fwww.inera.se%2FFHIR%2FStructureDefintion%2FPoC-Observation-headCircum&category=vital-signs&code=http%3A%2F%2Fsnomed.info%2Fsct%7C363812007"
    }
  ],
  "entry": [
    {
      "fullUrl": "http://localhost:8080/hapi/baseDstu3/Observation/54956",
      "resource": {
        "resourceType": "Observation",
        "id": "54956",
        "meta": {
          "versionId": "1",
          "lastUpdated": "2018-06-04T14:05:19.920+02:00",
          "profile": [
            "https://www.inera.se/FHIR/StructureDefintion/PoC-Observation-headCircum"
          ]
        },
        "status": "final",
        "category": [
          {
            "coding": [
              {
                "system": "http://hl7.org/fhir/observation-category",
                "code": "vital-signs"
              }
            ]
          }
        ],
        "code": {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "363812007"
            }
          ]
        },
        "subject": {
          "identifier": {
            "system": "urn:oid:1.2.752.129.2.1.3.1",
            "value": "191212121212"
          }
        },
        "effectiveDateTime": "2007",
        "performer": [
          {
            "identifier": {
              "system": "urn:oid:hsaoid",
              "value": "Organization/3211444"
            }
          },
          {
            "identifier": {
              "system": "urn:oid:hsaoid",
              "value": "Practitioner/9999989"
            }
          }
        ],
        "valueQuantity": {
          "value": 173,
          "unit": "cm",
          "system": "http://unitsofmeasure.org",
          "code": "cm"
        },
        "comment": "med kläder"
      },
      "search": {
        "mode": "match"
      }
    }
  ]
}
1

{


  "resourceType": "Bundle",
  "id": "375a0665-abc7-46ea-bad6-66cbec764bbc",
  "meta": {
    "lastUpdated": "2018-06-04T14:39:11.083+02:00"
  },
  "type": "searchset",
  "total": 2,
  "link": [
    {
      "relation": "self",
      "url": "http://localhost:8080/hapi/baseDstu3/Observation?_profile=https%3A%2F%2Fwww.inera.se%2FFHIR%2FStructureDefintion%2FPoC-Observation-BodyHeight&category=vital-signs&code=http%3A%2F%2Fsnomed.info%2Fsct%7C248334005"
    }
  ],
  "entry": [
    {
      "fullUrl": "http://localhost:8080/hapi/baseDstu3/Observation/54955",
      "resource": {
        "resourceType": "Observation",
        "id": "54955",
        "meta": {
          "versionId": "1",
          "lastUpdated": "2018-06-04T13:52:38.688+02:00",
          "profile": [
            "https://www.inera.se/FHIR/StructureDefintion/PoC-Observation-BodyHeight"
          ]
        },
        "status": "final",
        "category": [
          {
            "coding": [
              {
                "system": "http://hl7.org/fhir/observation-category",
                "code": "vital-signs"
              }
            ]
          }
        ],
        "code": {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "248334005"
            }
          ]
        },
        "subject": {
          "identifier": {
            "system": "urn:oid:1.2.752.129.2.1.3.1",
            "value": "191212121212"
          }
        },
        "effectiveDateTime": "2007",
        "performer": [
          {
            "identifier": {
              "system": "urn:oid:hsaoid",
              "value": "Performer/3211444"
            }
          }
        ],
        "valueQuantity": {
          "value": 1700,
          "unit": "g",
          "system": "http://unitsofmeasure.org",
          "code": "g"
        },
        "comment": "med kläder"
      },
      "search": {
        "mode": "match"
      }
    },
    {
      "fullUrl": "http://localhost:8080/hapi/baseDstu3/Observation/54958",
      "resource": {
        "resourceType": "Observation",
        "id": "54958",
        "meta": {
          "versionId": "1",
          "lastUpdated": "2018-06-04T14:05:41.429+02:00",
          "profile": [
            "https://www.inera.se/FHIR/StructureDefintion/PoC-Observation-BodyHeight"
          ]
        },
        "status": "final",
        "category": [
          {
            "coding": [
              {
                "system": "http://hl7.org/fhir/observation-category",
                "code": "vital-signs"
              }
            ]
          }
        ],
        "code": {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "248334005"
            }
          ]
        },
        "subject": {
          "identifier": {
            "system": "urn:oid:1.2.752.129.2.1.3.1",
            "value": "191212121212"
          }
        },
        "effectiveDateTime": "2007",
        "performer": [
          {
            "identifier": {
              "system": "urn:oid:hsaoid",
              "value": "Organization/3211444"
            }
          },
          {
            "identifier": {
              "system": "urn:oid:hsaoid",
              "value": "Practitioner/9999989"
            }
          }
        ],
        "valueQuantity": {
          "value": 173,
          "unit": "cm",
          "system": "http://unitsofmeasure.org",
          "code": "cm"
        },
        "comment": "med kläder"
      },
      "search": {
        "mode": "match"
      }
    }
  ]
}