Innhold

Aktører

Bakgrunn

E-resept samhandling er basert på utveksling av meldinger som er basert på XML, og definisjonene er "låst" slik at utvidelse av meldinger krever etablering av ny meldingsversjon. Reseptformidleren utgjør som navnet sier et "formidlings-nav" i kjeden, men kan i liten grad tilpasse innhold til mottakerens "versjon" fordi integritetsbeskyttelse er innebygget i meldingene. Det er mange aktører "på" e-resept, og i løpet av driftsårene har det vist seg at endringer som krever samtidighet er vanskelige å få til med dagens regime. 

Løsningens som er beskrevet her søker å løsrive seg fra samtidighetsbehovet, ved å muliggjøre stegvise endringer innenfor samme meldingsversjon. Det vil i korte trekk si det åpnes for å legge til informasjon som den mottakende part vil ignorere fram til det er utviklet støtte for det. Det er ventet at et parallelt prosjekt for å øke endringsevnen i e-resept på sikt vil ta frem løsning som etablerer enklere former for utvidelser gjennom nyere former for API med samhandlingsstøtte, men det sporet har en betydelig lenger tidshorisont.

Det er over tid etablert en liste over endringsbehov i forskjellige kategorier som ikke er innført. Da PLL ble utviklet i e-resept besluttet prosjektet å gjenbruke multidosemeldingen M25.1 fordi man anså det var raskeste vei til gevinst. Dette medførte også behov for å berike M25.1 noe. Sammenfattet er det tekniske, kvalitetsmessige, helsefaglige og myndighetspålagte endringer som tenkes løst på denne måten

Det ble vinteren 2020/21 besluttet en løsning for tilleggsinformasjon som benyttet ledige attributter i kodede verdier for å legge inn ny informasjon. Denne løsningen ble senere forkastet, og NHN fikk i oppdrag å ta frem en alternativ løsning. Standardisering og arkitektur i Direktoratet for e-helse /NHN ble involvert. Det er også avholdt et større teknisk workshop med aktører/leverandører for å komme fram til en best mulig løsning. Oppsummert har vi basert på innspill og vurderinger valgt å gå videre med en modell med et rammeverk med en definert tilleggsstruktur for hver enkelt melding, og sørge for at den er utvidbar på en bakoverkompatibel måte. 

Behov for tilleggsinformasjon gjelder meldingene Resept (M1), Tilbakekalling (M5) og Pasientens legemiddelliste (M25.1)

Vurdering og anbefaling

NHN vurderer dette som et ønsket og nødvendig tiltak for å støtte oppsamlede behov og spesielt for behov som introduseres av PLL utprøving. Løsningen sikrer endringsevne for relevante parter uten å kreve samtidighet i utvikling og utbredelse.

Dette endringsforslaget gjelder metoden og formatet for å inkludere tilleggsinformasjon i meldingene samt vedlegget for å inkludere seponeringsinformasjon i M5 tilbakekalling, og vedtaket er betinget av at introduksjon av tilleggsinformasjon i meldinger ikke får utilsiktede konsekvenser i e-resept og PLL samhandling.

Konsekvenser og avhengigheter

Prinsippet for denne “stegvis” tilnærmingen er at konsekvensene blir minimale for alle andre en de systemene / brukerne som skal ta ny funksjonalitet i bruk. Av dette følger at konsekvensene skal være “ingen” for de systemene som er uberørt av innføring av nye informasjonselementer, fram til det eventuelt foreligger vedtak om krav til å ta nye meldingselementer og funksjonalitet i bruk.

Vi har etablert testpasienter med varianter av disse meldingene i testsystemene for Reseptformidleren. Det er gjennom testing gjort verifikasjon mot alle de berørte systemer i e-resept samhandling (pågår) og det er noen få systemer som ikke takler foreslått løsning uten endringer. Eventuelle omfang av endringer og tidshorisont er under kartlegging.

Det er en forutsetning at samhandlingen ikke feiler i noen ledd, dvs. at alle systemer enten støtter eller ignorerer tilleggsinformasjon.

Konsekvenser for EPJ:

For systemer som ikke skal ta i bruk ny funksjonalitet: Ingen. Det arbeides med en leverandør for å finne omfang av en eventuell endring.

For EPJ som skal utvikle støtte ny informasjon må det utvikles støtte for både meldingsformat og ny funksjonalitet. Dette koordineres i første omgang av PLL utprøvingsprosjektet.

Konsekvenser for apotek/bandasjist:

Så langt i karlegging er det ett multidosesystem som må oppdateres for å takle og ignorere meldinger med foreslått format. Både Farmapro og Eik er uberørt av endringen.

Endringer i e-resept dokumentasjonen

[ x ] Arkitektur

[ ] Funksjonelt

[ ] Rekvirentkrav

[ x ] Meldingsdefinisjoner

[ ] Kodeverk

Forslag til ny eller endret tekst i dokumentasjonen

Eksisterende kapittel om “Bruk av Json i e-resept meldingsversjon 2.5” erstattes med følgende:

Utvidelse av meldinger uten skjema-/meldingsendring:

På samme måte som det i SFM er inkludert en kopi av HelseID-token i Resept (M1) i vedlegg legges det til et vedlegg som inneholder tilleggsinformasjon. Vedlegget følger standard for vedlegg til hodemeldingen, og det er derfor ikke behov for endring av meldingsdefinisjon. Spesifikasjonen sier at mottaker skal avvise meldinger med vedlegg som er ukjent, men i denne sammenhengen definerer vi at vedlegge ikke er ukjent, selv om det ikke er støtte for det i mottakende system. Det er ikke krav om videreformidling av vedlegget ved f.eks. fornying av resept i system som ikke har støtte for vedlegget.

Resepter som er signert med HelseID vil etter denne endringen ha to vedlegg, etter for HelseID token og ett for meldingsutvidelse. 

Vedlegget inkluderes i meldingen på standard måte som beskrevet i  HIS 1036:2011 

HIS_1036_2011-Vedlegg_til_meldinger -oppdatert.pdf (ehelse.no)

Det bemerkes at kulepunkt 3 i kap 2.2. om at meldinger skal avvises dersom de har vedlegg som mottaker ikke har støtte for, i tilfelle IKKE gjelder e-resept. Formelt og teknisk er Reseptformidleren mottaker av meldingen, og avgjør om den er akseptert eller ikke.

Formatet

For de enkelte meldingene lages det en eller flere utvidelser, og disse inngår i en utenpåliggende extension struktur. Hele strukturen Base64 kodes og legges inn som <Document> etter fagmelding og evt andre vedlegg (eksempel på vedlegg til M1):

<Description> feltet vil her tjene som et tolkbart felt sammen med <ContentDescription> som gir mer informasjon om versjon. Ut fra disse to feltene vil et system kunne avlede om utvidelsene er helt eller delvis støttet og kan parses.

Versjonering

Det er i arbeidet med å ta fram en struktur for tilleggsinfo lagt vekt på muligheten for å gjøre bakoverkompatible endringer.

Versjoneringen er inspirert av SEMVER standarden: Semantic Versioning 2.0.0 | Semantic Versioning (semver.org)

Med dette er det lagt opp til mulighet for introduksjon av bakoverkompatible endringer hvor andre ledd det treleddede versjonsnummeret opptateres. Namespace på XML-tillegget er uendret så lenge MAJOR version ikke endres.

Følgende regler gjelder:

• ContentDescriptiption inneholder en string som er komponert av fragment av namespace, men med 3 sifret versjonsnummer

• Namespace avsluttes med MAJOR versjonsnummer

• Version (attributt i extension)  inneholder versjonsnummer som korresponderer med ContentDescription

• Ny versjon innenfor samme MAJOR versjon skal validere med eldre versjoner av XSD med samme namespace.

• Dersom et endesystem mottar tilleggsinfo med kjent namespace, men nyere versjonsnummer er det kun bakoverkompatible endringer og det er trygt å tolke den delen av tillegget som er kjent. 

Første versjon vil inneholde disse:

Bakoverkompatibel nyere versjon kan se slik ut:

Mottaker kan da validere XML og parse kjent innhold

Ikke-bakoverkompatibel endring gir nytt namespace, og kan følgelig ikke parses uten oppdatering av mottakersystem:

Det utarbeides informasjon om tilleggene som publiseres på Sarepta, og som tas inn i meldingsdefinisjonene når det er naturlig å oppdatere disse:

Tillegg til M5

Dette tillegget omfatter seponeringsinformasjon ved tilbakekalling med årsak=seponering. Det er gjenbruk av Seponeringsstrukturen fra M25 meldingene. Funksjonaliteten for sluttbruker vil i dette tilfellet være uendret, fordi denne informasjonen allerede angis i EPJ. Reseptformidleren vil tilby denne informasjonen i “Reseptliste” for rekvirent (M9.6) som kommer i ny versjon.

Open

Kapitlene under er tatt med for sammenhengens skyld, men vil formelt vedtas ved en senere anledning i samråd med PLL utprøving. Det er naturlig at M1 og M25.1 behandles samtidig fordi mange av informasjonselementene finnes begge steder.

Tillegg til M1

Open

Tillegg til M25.1

Strukturert dosering er kollapset, men har samme innhold som for M1

Allergi i M25.1

XSD (meldingsdefinisjon) for tilleggene publiseres på Sarepta.

Endringer i systemer

Reseptformidleren vil få utvidet støtte for noen av de nye informasjonselementene. Særlig gjelder det seponeringsinformasjon i M1 og M5, som er planlagt støttet i nye versjoner av “Reseptliste rekvirent” M9.6.

Sentral Forskrivningsmodul og EPJ systemer som deltar i PLL utprøving vil utvikle støtte i henhold til krav fra prosjektet.

Ett EPJ system må etablere toleranse for meldinger med vedlegg. Tilsvarende for ett Multidosepakkesystem.

Krav til leveringstid

Eventuell støtte for nye felt vil kravstilles gjennom deltakelse i PLL utprøving.

Evt økonomiske og/eller administrative konsekvenser

Ingen særskilt finansiering