Meldingsversjoner

Oversikt over hvilke versjoner av meldinger som til enhver tid er tillatt brukt skal utarbeides og vedlikeholdes. Reseptformidleren spiller en nøkkelrolle i verdikjeden i e-resept og forvaltning av denne skal sees i sammenheng med forvaltning av meldingene. Standardisering skal ivareta en sentral funksjon i forhold til å etablere nye meldingsstandarder.

Hvis en avsendende part prøver å sende melding med utgått versjon så skal mottaker avvise meldingen.

Partene plikter å avstemme endringer med de andre aktørene i så god tid i forkant av endringer, at alle aktører kan gjennomføre forutgående tester, før endringer settes i produksjon. De eksakte kravene til forvaltningsregime vil avtales mellom partene som en del av det videre arbeidet. 

Protokollversjoner

Over tid vil aktuelle versjoner av standarder og protokoller for meldingsoverføring og PKI måtte forventes å endre seg. Overgang til nye standarder vil være underlagt sentral kontroll i samarbeid mellom partene.

Endringshåndtering av meldinger

Norsk Helsenett SF (NHN) ivaretar endringshåndtering i e-resept. Direktoratet for ehelse, avdeling standardisering vil spille en rolle knyttet til ajourhold og publisering av meldinger.

Endringer i meldinger faller inn som en del av en generell endringshåndtering. 

En versjon vil omfatte et sett med sammenhengende dokumentasjon av løsningen, både arkitekturmessig, funksjonelt og meldingsmessig. På den måten er det enkelt for aktørene å se helheten i en endring.

Følgende prinsipper knyttet til håndtering av nye meldingsversjoner gjelder:

Rutiner og prosedyrer:

1. Det skal vedlikeholdes en oversikt over hvilke meldingsversjoner som støttes i e-resept og sammenhengene mellom disse. Sammenhengene mellom hodemelding, meldingsversjon på en melding, tilhørende svarmelding og evt. AppRec klargjøres som en del av dette på standardisert format og publiseres i referansekatalogen av Direktoratet for e-helse. Det skal også angis krav til støtte for versjon på bilag og versjon på konvolutten.

2. Det må verifiseres/testes at aktuelle aktører håndterer meldinger med andre meldinger som vedlegg med blanding av gammel og ny M1. Testcase for å sikre håndtering av flere M1-versjoner i parallell må utvikles.

3. Det må også verifiseres/testes at rekvirent og utleverer håndterer M9.6 og M9.4 med blanding av gammel og ny M10. Testcase for å sikre håndtering av flere M10-versjoner i parallell må utvikles.

4. Det må også verifiseres/testes at rekvirent og utleverer håndterer M9.12 med blanding av gammel og ny M25. Testcase for å sikre håndtering av flere M25-versjoner i parallell må utvikles.

5. Konsekvenser av meldingsendringer for M1 og M10, må alltid sees i sammenheng med M9.4, M9.6 og M18. Konsekvenser av meldingsendringer for M25, må alltid sees i sammenheng med M9.12. Revisjon av den generelle forskrivningsmodellen må alltid sees i en større sammenheng; M30, M1, M10 og M25.

6. Konsekvenser av endringer i de andre meldinger kan sees på mer isolert, men eventuelle konsekvenser for andre meldinger og funksjoner hos aktørene må vurderes.

7. Serveren til Test- og Godkjenningsordningen må utvikles til å håndtere kombinasjoner av godkjente meldingsversjoner som vedlegg for de relevante meldinger.

Design av meldinger og funksjonalitet

1. E-resept aktørene må sikre at leverandørene etterlever og forstår de momenter som gjelder for håndtering av versjoner i parallell.

2. Meldingsversjon skal inngå som en del av alle meldinger, uansett hvordan disse er implementert. NameSpace benyttes for dette formålet.

3. For M1 må det være støtte for alle gyldige resepter uansett versjon, dvs. 3 år og 6 måneder (pluss etterslep inntil siste legekontor har byttet versjon) gammel versjon av M1 må støttes i M18, også i påfølgende meldinger, se også neste punkt.

4. En endring i M1 skal ikke nødvendigvis medføre endring i M9.4 (kan også påvirke M9.2 og M9NA2), M9.6 og M18.

5. En endring i M10 skal ikke nødvendigvis medføre endring i M9.4 og M9.6.

6. En endring i M25 skal ikke nødvendigvis medføre endring i M9.12

7. For meldinger som sendes ut til mange ulike aktører, for eksempel M21, M6, M8, kan det forutsettes at mottager støtter nyeste versjon av meldingen, slik at avsender ikke behøver å holde rede på meldingsversjon. Det vil vurderes om Adresseregisteret kan utvikles på sikt for å støtte dette.

8. For meldinger på ny versjon som sendes aktører med gammel versjon kan dette gjøres forståelig ved å oversende skjema for visning av meldingen som en del av meldingen. Dette punktet er spesielt viktig for M21, hvor det er viktig at mottaker agerer ut fra meldingen. En mekanisme for dette kan være å gjenkjenne melding mot NameSpace og dermed vite hvilken type melding, og så søke å lese med siste kjente versjon.

Innføring av endrede versjoner

1. NHN beslutter i samarbeid med aktørene hvilke meldingsversjoner som skal være gyldige

2. Ved innføring av nye meldingsversjoner må innføringen av støtte for dette starte bakerst i den delen av verdikjeden som berøres. Dersom en endring påvirker M18, må Helfo først ha støtte før utlevererne må ha støtte, deretter Reseptformidleren og til slutt rekvirent og evt. DMP.

3. Å sende meldinger basert på ny versjon følger verdikjeden, men det forutsettes at støtte er implementert i henhold til rekkefølgen som angitt i punkt 1.

Håndtering av flere meldingsversjoner i parallell

I e-resept er det forventet at meldingene over tid vil måtte endres noe. Det er to grunnleggende forhold knyttet til versjonshåndtering av meldinger i e-resept, som må tas hensyn til:

• Resepten varer lenge

  • Den grunnleggende meldingen i e-resept er resepten (M1), som også inngår som vedlegg i flere meldinger. Denne meldingen har gyldighet på opptil tre år, hvilket innebærer at endring av M1 innebærer at e-resept i lang tid må kunne håndtere både gammel og ny versjon av M1, også som vedlegg i flere andre meldinger og i alle berørte systemer.

  • Utleveringsrapporten M10 har også en levetid og gjentas som vedlegg i nye meldinger (bl.a. M9.4 og M9.6), som gir tilsvarende argumentasjon.

• Aktørene bytter ikke systemversjoner helt samtidig

  • For rekvirentene og for utlevererne vil det ikke kunne sikres fullstendig samtidig overgang til nye systemversjoner for alle aktører. For utleverere forventes at alle i løpet av en forholds vis kort periode kan bytte systemversjon. For rekvirentene vil en slik periode være lenger, både på grunn av antallet leger og antallet involverte systemer. Vi kan derfor ikke forvente at alle aktørene kan bytte systemversjon samtidig, og vil derfor ved innføring av nye meldinger, måtte håndtere overgang mellom nye og gamle meldingsversjoner i en kombinasjon mellom manuelle rutiner og systemstøtte.