Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

version PA1Version PA2

Innehållsförteckning

Inledning

...

Till skillnad mot RIV-TA stödjer Messaging i FHIR både synkrona och synkrona 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:

...

Det innebär att GetObservations ska ersättas av en REST-baserad FHIR-användasanvä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ädningsfall 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:

Tjänstedomän/TjänstekontraktHändelse i initiativtagande system ("sender")Utförande system ("destination")Typ
EI:UpdateNy information enligt "category"-kodverk har uppstått i det vårdsystem som ska uppdatera EI.EI, som tar emot Update-begäran och utför den bearbetning som beskrivs för men EI:Update-tjänsteproducent.Notification
Skicka en remiss (1.x)Remiss skapad i remittentens journalsystemRemissmottagarens systemNotification

Skicka en biverkningsrapport

Biverkningsrapportering initierad i Journalsystem - direkt eller indirekt via SEBRA-applikationenLäkemedelsverkets mottagningstjänstNotification

Skicka en bilaga till en utomlänsfaktura (ersättningsunderlag)

Ersättningsunderlag för en utomlänspatient har skapats i utomlänets ersättningssystem.Folkbokföringslänets ersättningssystemNotification
Rapportera utomlänslistning till folkbokföringsladnstingetListningssystemet hos utomlänslandstinget har registrerat en ny-listning av en utomlänspatientListningssystemet hos folkbokföringslandstingetNotification

...

KravHantering enligt RIVTA Basic Profile 2.1 TjänsteschemaMappning FHIR
Huvud-version (major)  är en del av profilens identitetAttributet targetNamespace på schema-elementet skall ha ett värde som definieras av följande regel: urn:riv:${tjänsteDomän}:${m}, där "m" är huvudversion.Varje profils StructureDefinition.url ska ha en kanonisk URL där versionssiffran för huvudversion ingår.
Profilen ska dokumentera vilken under-version (minor) den stödjerSchema-attributet version bör sättas till "m.n"

StructureDefinition.version ska ange aktuell version med huvudversion och underversion.

Kunna uttrycka om profiler alltid sam-versioneras eller versioneras individuellt.Tjänstedomäner grupperar tjänstekontrakt som samversioneras. Men domänerna har dubbla roller: de anger BÅDE informatiskt/funktionell gruppering och release-gruppering. 

Förslag (som också kan tillämpas för tjänstekontraktsdomäner): att versionssiffrar (major) anges FÖRE profilnamnet i den kanoniska URL:en för profilens StructureDefnition om den sam-releasas med andra profiler, annars EFTER profilnamnet (tveksamt om det kommer att finnas sådana fall). Profiler som sär-releasas är i regel bas-profiler som är tänkta att återanvändas som byggblock snarare än att tillämpas "as is". Om vi har en helt generisk basprofil for Observation skulle det kunna vara ett exempel. Men även i det fallet kommer en bas-observation att behöva referera till ex. basprofil för Device. 

Exempel på sam-releasad profil:er RIVTA Core Vital Signs: http://rivta.se/fhir/StructureDefinition/se-core-vitalsigns-v1/Observation

http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyWeight

http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyHeight

http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/HeadCircum

Kommentar: Troligen blir det relevant att ha en Implementation Guide per domän.


Huvudversion av en profil ska anges i varje informationsutbyteGenom att WS-I Basic Profile följs i RIV TA Basic Profile garanteras att meddelandets tjänsteschemats namnrymd är meddelandets namnrymd. Huvudversion ingår i namnrymden. Som en konsekvens blir meddelanden med olika huvudversioner inkompatibla mellan kommunicerande agenter.

FHIR styr meddelandets namnrymd till ett fast värde som anges av standarden. Inkompatibilitet kan därför inte automatiskt upptäckas av agenternas XML-tolkar (parsers) via namnrymdskonflikter. Därför behöver programmatiska regler tillföras baserat på att huvudversion anges på annat sätt som del av payload. 

  1. I ett svarsmeddelande ska Resource.meta.profile lista alla profiler som resursen följer. Responsen SKA bara innehåller resurser som stödjer den profil som efterfrågats i begäran.
  2. I en uppdaterande begäran (transaktion) ska Resource.meta.profile ange den profil som måste accepteras av Utföraren/mottagaren (Responder).
  3. En uppdaterande begäran ska enbart accepteras av utföraren/mottagaren om Resource.meta.profile är angiven och innehåller en och endast en profil som mottagaren deklarerar stöd för genom ett CapabilityStatement.
  4. I en frågande begäran SKA konsumenten ange kanonisk URL för den profil man accepterar. Det anges i parametern "_profile". 

Ovanstående förutsätter att Huvud-version (major) är en del av profilens kanoniska URL.

...

KonceptAnvisningDagens lösningRIVTA FHIR
logisk adressRIVTA BPsoap-headerx-riv-logical-address http header
source systemJoL-kontrakt/TKBElement i JoL-header

Resource.meta.source.

Finns i R4. Fram tills dess en extention som appliceras på varje svensk basprofil som motsvarar JoL-kontrakt. PoCObservation anger att .meta.source är obligatorisk. Termen dokumenteras med samma innebörd som i nuvarande JoL-kontrakt.

Aggregerings-headerRIVTA interoperability hadersSOAP-header med svenskt schema i response från aggregerande tjänstSvensk Audit-profil som - enligt textuell regel - bundlas med responsen (del av responsens Bundle)
ApprovedForPatientJoL-kontrakt/TKBElement i JoL-header (true/false)Resource.meta.security. Förekomsten av koden https://www.hl7.org/fhir/v3/ActReason/cs.html#v3-ActReason-PATRQT mappar mot "true" och att koden inte förkommer mappar mot false. Kodverket ingår i standardkodverken för Resource.meta.security. Termen dokumenteras med samma innebörd som i nuvarande JoL-kontrakt. 
Informationsunderlag för spärrkontroll - "infomängd"JoL-kontrakt/TKBSpärrkontroll och åtkomststyrning sker enligt kodverk för infotyper (HSA-förvaltat kodverk med ursprung i NPÖ 1.0). Ingår i informationsstruktur för medarbetaruppdrag. Mappningen mellan infotyp (parameter till spärrkontroll) hanteras programmatiskt i klienten. Ex: Om data kommer från GetLaboratoryOrderOutcome används infotyp för Undersökningsresultat. Observationer och aktiviteter har en mer indirekt mappning, baserat på i vilket syfte observationer hämtas. Om de hämtas för syfte Tillväxtkurvor/Barnhälsodata används infotyp för det tillämpningsområdet vid spärrkontroll. Dessa infotyper finns ännu inte. Inera driver ett projekt för att införa sådan hantering.Inget att mappa. Programatisk regel dokumenteras i tillämpningsanvisningar, certifieringsregelverk etc som ligger utanför profilerna.
Sekretessgränser enligt patientdatalagen (VG/VE)JoL-kontrakt/TKBFör att en informationskonsument ska kunna avgränsa professionsanvändarens åtkomst till avsedd sekretess behöver information vara märkt med vårdenhet (hsa-id) och vårdgivare (hsa-id). Det sker idag med två fält i den s.k. JoL-headern. HSA-id för Vårdenhet mappas till en "identifier" i  performer-listan med type = "XX" (HL7 v2-kodverk). Vårdgivare mappas på samma sätt men med type = "EN".

...

<TODO: inled med en grafisk modell - ex Gliffy -  som visar vilka resurser (profiler) som används av observationsprofilen och hur de relaterar till varandra. Isma Mobeen (Deactivated)  ///under arbete//> 2018-05-14 



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.

...

Vi har diskuterat hur man kan förhålla sig till de s.k. Auronaut Agronaut-projektet. Det är profiler och guidelines som förvaltats 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. Apple baseras sin koppling till Apple Healthkit (möjligheten att föra över strukturerad journaldata från journalsystem till mobilens HelathKit-databas) på dessa profiler och relaterat tekniskt ramverk. Argonaut och Apple använder idag DSTU2-baserade profiler. 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 förvaltas profilerna av HL7 International inom ramen för FHIR-standarden. Dessa profiler förvaltas där under namnet "US Core". Vi har bedömt det vara av strategiskt intresse för Ineras ägare att en server som stödjer de svenska profilerna, kan anslutas till internationella API-klienter som baseras US Core. 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å måletdessa 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 

...

Sammantaget leder dessa faktorer oss att gå på alternativ 2 - mappning. Det leder till följande arkitektur: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 autenthiseras 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).

...

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

REST-url:

Svarsmeddelande:


Kodblock
languagexml
{
  "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


sökning för kropslängd
Svarsmeddelande 


Kodblock
languagexml
{


  "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"
      }
    }
  ]
}