Version PA5
...
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:
| Tjänstedomän/Tjänstekontrakt | Händelse i initiativtagande system ("sender") | Utförande system ("destination") | FHIR Event Category |
|---|---|---|---|
| EI:Update | Ny 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 journalsystem | Remissmottagarens system | Consequence |
Skicka en biverkningsrapport | Biverkningsrapportering initierad i Journalsystem - direkt eller indirekt via SEBRA-applikationen | Läkemedelsverkets mottagningstjänst | Consequence |
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ättningssystem | Consequence |
| Rapportera utomlänslistning till folkbokföringslandstinget | Listningssystemet hos utomlänslandstinget har registrerat en ny-listning av en utomlänspatient | Listningssystemet hos folkbokföringslandstinget | Consequence |
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.
...
| Krav | Hantering enligt RIVTA Basic Profile 2.1 Tjänsteschema | Mappning FHIR |
|---|---|---|
| Huvud-version (major) är en del av profilens identitet | Attributet 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ödjer | Schema-attributet version ska 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 informationsutbyte | Genom 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.
Ovanstående förutsätter att Huvud-version (major) är en del av profilens kanoniska URL. |
...
| Koncept | Anvisning | Dagens lösning | RIVTA FHIR |
|---|---|---|---|
| logisk adress | RIVTA BP | soap-header | x-riv-logical-address http header |
| tjänste-interaktionens identitet | RIVTA BP | Enligt OASIS WS-I Basic Profile: nyttolastens XML-namnrymd, exempelvis "urn:riv:clinicalprocess:healthcond:basic:GetObservationsResponder:2") | Värdet på request-parametern "_profile", exempelvis: "http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyHeight". Notering: Tjänsteinteraktionens identitet är basen i modellen för lös koppling: Bindningen mellan källsystem och tjänstekonsument baseras på logisk adress och Tjänsteinteraktionens identitet. Eftersom denna PoC visar att FHIR-profiler bör användas för att specificera interoperabilitetsförmåga ner på enskild klinisk modell (ex. kroppsvikt) kommer nivån för bindningen att bli allt för detaljerad. Därför föreslås att bindningsmodellen utökas med möjligheten att binda adressen till ett källsystem till mer generella delar av profilernas URI. Exempelvis skulle samtliga vital-parameter-profiler som stödja i ett källsystem kunna bindas till "http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/*". Det medför förstås en risk att stöd för just den efterfrågade vitalparametern saknas i adresserat källsystem. Det kommer att lösas i en annan pågående aktivitet som syftar till att frikoppla TAK.s roll för adressering från dess i vissa sammanhang utökade användning sm metadata-källa för integrationsförmågor. Den som har behov av metadata om integrationsförmåga på lägsta nivå (vilka kliniska modeller som stöds) kan istället förlita sig på aggregerande tjänstens undantagsrapportering och baserat på den acceptera eller inte acceptera att ett av de aggregerad källsystemen saknar stöd för just den önskade vitalparametern. |
| source system | JoL-kontrakt/TKB | Element 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-header | RIVTA interoperability haders | SOAP-header med svenskt schema i response från aggregerande tjänst | Svensk Audit-profil som - enligt textuell regel - bundlas med responsen (del av responsens Bundle) |
| ApprovedForPatient | JoL-kontrakt/TKB | Element 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/TKB | Spä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/TKB | Fö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". |
...
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.
| Lucidchart | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 inom en viss vårdkontakt
Detta är en typ av sökning som stöds av dagens nationella tjänstekontrakt för åtkomst till journalinformation i vårdgivarnas vårdinformationssystem (med undantag av GetObservations och GetActivities). Mapping av vårdlkontaktid görs till det mer generiska fältet "context" i FHIR Observation-resursen. Det är en referens som kan peka på antingen vårdkontakt eller vårdepisod. Det som i dagens green-CDA-gränssnitt blir två sökparametrar (careContactId och sourceSystemHsaId) blir i FHIR istället parametern context-identifier (som byggs upp av både kontakt-id och sourceSystem-hsa-id) och context-type (som byggs upp av referens till kodverket för resurstyper och namnet på resurstypen för vårdkontakt).
| parameter | beskrivning | värde |
|---|---|---|
| code | SNOMED-kod för eftersökt vitalparameter. Är egentligen överflödig eftersom sökning också avgränsas till den profil som styr in code mot värdet för kroppsvikt. Firely har rekommenderat att vi ska ha med båda parametrarna i sökningarna. Vi får utvärdera det längre fram. | Kod för BodyHeight: "http://snomed.info/sct|248334005". Notationen innebär att både kodsystem och kod anges. Övriga koder som används i denna referensapplikation är:
|
| category | Anger vilken typ av observationer som efterfrågas. Parametern kan troligen vara överflödig i de fall alla observationer för en viss "code" hamnar i samma kategori. | "vital-signs" |
| _profile | Kanonisk url för den profil (structure definition) som svaret ska vara kompatibelt med. | Profil för Kroppsvikt: http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyHeight |
| context-identifier | Vårdkontaktens identifierare, uppbyggd av källsystemets hsa-id (code system) och den systemlokala vårdkontaktidentiteten. Vårdkontakten är bunden till patient så patientens identitet behöver inte anges. I R4 anges här context:identifier. I DSTU behöver en SearchParameter konfigureras för att möjliggöra sökningen. Kodsystemet anges av HSA-id för källsystemet. Det är denna konstruerade sökparameter som heter "context-identifier". | "urn:oid:1.2.752.129.2.1.3.1|191212121212" |
| context-type | Anger att det är vårdkontakt som avses (inte vårdepisod). Samt att typen anges av resursnamnet för vårdkontakt (Encounter) samt URI för kodsystemet för FHIRs alla resursnamn. | "http://hl7.org/fhir/resource-types|Encounter" |
REST-url:
[server]/Observation?context-identifier=SE162321000065-B08|1111444&context-type=http://hl7.org/fhir/resource-types|Encounter&code=http://snomed.info/sct|248334005&category=vital-signs&_profile=http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyWeight
Hämta tillväxtinformation med avgränsning till en vårdgivare
Att hämta information om en patient för en viss klinisk vitalparameter (kroppslängd) inom en vårdgivare
| parameter | beskrivning | värde |
|---|---|---|
| code | SNOMED-kod för eftersökt vitalparameter. Är egentligen överflödig eftersom sökning också avgränsas till den profil som styr in code mot värdet för kroppsvikt. Firely har rekommenderat att vi ska ha med båda parametrarna i sökningarna. Vi får utvärdera det längre fram. | Kod för BodyHeight: "http://snomed.info/sct|248334005". Notationen innebär att både kodsystem och kod anges. Övriga koder som används i denna referensapplikation är:
|
| category | Anger vilken typ av observationer som efterfrågas. Parametern kan troligen vara överflödig i de fall alla observationer för en viss "code" hamnar i samma kategori. | "vital-signs" |
| _profile | Kanonisk url för den profil (structure definition) som svaret ska vara kompatibelt med. | Profil för Kroppsvikt: http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyHeight |
| subject-identifier | Se tidigare beskrivning | "urn:oid:1.2.752.129.2.1.3.1|191212121212" |
| performer-type | Konfigurerad sökparameter för att avgränsa till en viss typ av Perfomer. Här i syfte att avgränsa till en viss vårdgivare. Typen "EN" ur kodsystemet http://hl7.org/fhir/v2/0203 har tappats mot konceptet Vårgivare. | "http://hl7.org/fhir/v2/0203|EN" |
| performer-identifier | Vårdgivarens HSA-id, uppbyggt av oid för kodsystemet för HSA-identiteter följt av vårdgivarens HSA-identitet. | "urn:oid:1.2.752.129.2.1.4.1|2222" |
REST-url:
[server]/Observation?subject-identifier=urn:oid:1.2.752.129.2.1.3.1|191212121212&code=http://snomed.info/sct|248334005&category=vital-signs&_profile=http://rivta.se/fhir/StructureDefinition/core/se-core-vitalsigns-v1/BodyWeight&performer-type=http://hl7.org/fhir/v2/0203|EN&performer-identity=urn:oid:1.2.752.129.2.1.4.1|2222