Utfylling av hodemeldingen

Innledning

Meldingsutvidelsen legges til som vedlegg i hodemeldingen.. Vedlegget følger standard for vedlegg til hodemeldingen som beskrevet i  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, IKKE gjelder e-resept. Formelt og teknisk er Reseptformidleren mottaker av meldingen, og avgjør om den er akseptert eller ikke.

Det er ikke krav om videreformidling av vedlegget ved f.eks. fornying av resept i system som ikke har støtte for vedlegget.

Utfylling av hodemelding

MsgHead/Document fylles ut som følger:

FeltInnhold
DocumentConnection

V="A" DN="Andre tilleggsdokument"


ContentDescription

Satt sammen av fragment av namespace, med 3 sifret versjonsnummer

Eksempel: 

eresept/m251/2013-10-08/extension/1.0.0

Se også versjonering nedenfor.


AnnotationValgfri


Innhold i Document/RefDoc:

FeltInnhold
MsgTypeV="A" DN="Vedlegg"
MimeTypeapplication/xml
DescriptionRotnoden i meldingsutvidelsen. Eksempel: ReseptUtvidelse eller LegeMidlerIBrukUtvidelse
ContentBase64Container med base 64 kodet meldingsutvidelse


Eksempel i M25.1:

Eksempel på PLL melding med tillegsinfo


<Document>
 	<DocumentConnection DN="Andre tilleggsdokument" V="A" />
 	<ContentDescription>eresept/m251/2013-10-08/extension/1.0.0</ContentDescription>
 	<RefDoc>
 		<MsgType DN="Vedlegg" V="A" />
 		<MimeType>application/xml</MimeType>
 		<Description>LegemidlerIbrukUtvidelse</Description>
 		<Content>
 			<Base64Container xmlns="http://www.kith.no/xmlstds/base64container">PExlZ2VtaWRsZXJJYnJ1a1V0dmlkZWxzZSB2ZXJ........	</Base64Container>
 		</Content>
	</RefDoc>
</Document>


Eksempel M1

<Document>
 <DocumentConnection DN="Andre tilleggsdokument" V="A" />
 <ContentDescription>eresept/m1/2013-10-08/extension/1.0.0</ContentDescription>
 <RefDoc>
 	<MsgType DN="Vedlegg" V="A" />
 	<MimeType>application/xml</MimeType>
 	<Description>ReseptUtvidelse</Description>
 	<Content>
 		<Base64Container xmlns="http://www.kith.no/xmlstds/base64container">PFJlc2VwdFV0dmlkZWxzZSB2ZXJzaW9uPS....... </Base64Container>
 	</Content>
 </RefDoc>
</Document>


Versjonering

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

Versjoneringen er sterkt 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:

<ContentDescription>eresept/m1/2013-10-08/extension/1.0.0</ContentDescription>
<extension xmlns="http://www.kith.no/xmlstds/eresept/m1/2013-10-08/extension/1" version="1.0.0" ...>

Bakoverkompatibel nyere versjon kan se slik ut:

<ContentDescription>eresept/m1/2013-10-08/extension/1.2.0</ContentDescription>
<extension xmlns="http://www.kith.no/xmlstds/eresept/m1/2013-10-08/extension/1" version="1.2.0" ...>

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:

<ContentDescription>eresept/m1/2013-10-08/extension/2.0.0</ContentDescription>
<extension xmlns="http://www.kith.no/xmlstds/eresept/m1/2013-10-08/extension/2" version="2.0.0" ...>