Forslag til nasjonal standard for sending av vedlegg til nasjonale XML-meldinger

Transkript

1 Høringsnotat Til Brukere av KITH-meldinger Fra KITH v/espen Stranger Seland, Anita Lorck Bjørgen m. fl. Dato Status Til høring frist for tilbakemeldinger er Forslag til nasjonal standard for sending av vedlegg til nasjonale XML-meldinger Dette dokumentet beskriver krav til hvordan vedlegg til nasjonale XML-meldinger skal overføres. Det ønskes spesielt tilbakemelding på spørsmål som er markert med gul bakgrunnsfarge under. 1. Forslag til standard for vedlegg Tabellen under oppsummerer krav og forutsetninger til versjon 1.0. Område Spesifikasjon Dato for innføring Løsningen varsles Alle må ha implementert støtte for mottak av pdfvedlegg innen Forutsetning XML-melding som har RefDoc-struktur (se avsnitt 3.1) Metode Lovlige filtyper for vedlegg Antall vedlegg pr. melding Maks total størrelse på vedlegg Base64Continer skal benyttes i henhold til beskrivelsen i avsnitt 3. PDF: Alle må kunne motta pdf-vedlegg i RefDoc XML: Benyttes kun for utvalgte meldinger i eresept Bruk må avtales per meldingstype og område Det er maksimalt lov å sende 5 antall vedlegg til en melding. Spørsmål: Er det behov for å begrense antall vedlegg, og hvilken begrensings bør det i så fall være? Eller er det tilstrekkelig å begrense total størrelse? Samlet størrelse på vedleggene sendt i en melding skal ikke overstige 10MB Er dette en fornuftig begrensing med hensyn til størrelse med tanke på SMTP-overføring? 1

2 2. Bakgrunn Sending av vedlegg til eksisterende XML-meldinger har vært etterspurt i mange år, og det er tidligere beskrevet hvordan dette kan gjøres ved å legge binære vedlegg utenfor meldingen med referanse (vedlegg i ebxml-konvolutt). Metoden har så vidt vi er kjent med ikke blitt tatt i bruk mellom eksterne parter. I eresept-programmet har man innført en løsning for å kunne inkludere både XML og binære vedlegg direkte i Hodemeldingens vedleggsstruktur ved hjelp av base64-koding. Denne løsningen benytter Content-elementet. Etter vår vurdering vil dette være en god løsning for alle XML-meldinger som inneholder RefDoc-strukturen. Alle meldinger som benytter Hodemelding, epikrise, henvisning labsvar og rekvisisjon inneholder samme RefDoc-struktur. Ved å innføre begrensning på filformat til kun å gjelde pdf-filer vil det være enklere å stille krav til alle leverandører om å kunne motta vedlegg på dette filformatet. Dokumentet beskriver hvordan vedlegg skal sendes, basert på samme løsning som er innført og tatt i bruk i eresept-programmet. Denne metoden vil bli dokumentert i en KITH-rapport som vil erstatte rapporten Nasjonale retningslinjer Meldinger ved vedlegg, Versjon 1.0, Dato: , etter behandling av innkomne tilbakemeldinger. 3. Metode 3.1. RefDoc I både Hodemeldingen og andre KITH-meldinger skal Base64Container brukes som en utvidelse av Content i RefDoc-strukturen. Alle XML meldinger som det skal være mulig å overføre vedlegg med, må ha en RefDoc struktur kompatibel med strukturen som er beskrevet i Standard for hodemelding 2. Figur 1 RefDoc og Content KITH rapport 01/06: Standard for hodemelding Informasjonsmodell og XML meldingsbeskrivelse versjon 1.2. Status: Til utbredelse

3 <element name="refdoc"> <complextype> <sequence> <element name="issuedate" type="mh:ts" minoccurs="0"/> <element name="msgtype" type="mh:cs"/> <element name="id" type="string" minoccurs="0"/> <element name="mimetype" type="string" minoccurs="0"/> <element name="description" type="string" minoccurs="0"/> <element name="filereference" type="anyuri" minoccurs="0"/> <element name="compression" type="string" minoccurs="0"/> <element name="content" minoccurs="0"> <complextype> <complexcontent> <extension base="anytype"/> </complexcontent> </complextype> </element> </sequence> </complextype> </element> 3.2. Base64Container Content-elementet er beregnet på XML som er strict, noe som betyr at innholdet må valideres korrekt mot en oppgitt XSD. For å løse dette er det laget en XSD som i prinsippet er en konteiner for base64-kodet innhold. <?xml version="1.0" encoding="utf-8"?> <!-- Base64Container v KITH Skjema for å benytte base64-kodet innhold i Document/Content-elementet i Hodemeldingen. --> <xs:schema xmlns=" xmlns:xs=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="base64container"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:base64binary"/> </xs:simplecontent> </xs:complextype> </xs:element> </xs:schema> 3

4 3.3. Pdf-fil som vedlegg Følgende krav til bruken av RefDoc strukturen gjelder for overføring av Pdf-filer: XML meldinger skal referere hvert enkelt vedlegg i en egen RefDoc og RefDoc/MsgType skal alltid indikere at referansen gjelder et vedlegg. RefDoc/IssueDate: Dato for opprettelsen av vedlegget RefDoc/MsgType: Skal alltid ha kodeverdi V med tilhørende kodetekst Vedlegg. Fra kodeverket Type dokumentreferanse (OID=8114). RefDoc/MimeType: Skal ha verdien application/pdf. Inneholder spesifikasjon av mime type for det binære vedlegget Bruk av andre verdier må være dokumentert i meldingsdokumentasjonen. RefDoc/Description: Kort beskrivelse av innholdet, eksempelvis Bilde av sår, Innskannet resept, Rekvisisjon-No13g Eksempel: <RefDoc> <IssueDate V=" T09:30:12"/> <MimeType>application/pdf</MimeType> <Description> Rekvisisjon-No13g </Description> <Content> <Base64Container xsi:schemalocation=" kithbase64.xsd" xmlns=" xmlns:xsi=" (...) dhrwoi8vd3d3lmtpdggubm8veg1sc3rkcy9tc2dozwfklziwmdytmdutmjqiihhtbg5zomrzpsjo c2thbcb25njlig1lzcatlt4ncjwvtxnnsgvhzd4ncg==</base64container> </Content> </RefDoc> 3.4. XML-melding som vedlegg Bruk av denne metoden må dokumenteres per meldingstype. Metoden er foreløpig kun tatt i bruk for noen eresept-meldinger. Følgende krav til bruken av RefDoc strukturen gjelder for overføring av Pdf-filer: XML meldinger skal referere hvert enkelt vedlegg i en egen RefDoc og RefDoc/MsgType skal alltid indikere at referansen gjelder et vedlegg. RefDoc/IssueDate: Dato for opprettelsen av vedlegget RefDoc/MsgType: Skal alltid ha kodeverdi V med tilhørende kodetekst Vedlegg. Fr kodeverket Type dokumentreferanse (OID=8114). RefDoc/Id: Meldingens ID (UUID) RefDoc/MimeType: Skal ha verdien text/xml. RefDoc/Description: Kort beskrivelse av innholdet, eksempelvis Tidligere forskrivninger. 4

5 Eksempel: <RefDoc> <IssueDate V=" T09:30:12"/> <Id>36ee5c30-6d47-11de-8a c9a66</Id> <MimeType>text/xml</MimeType> <Description>Tidligere forskrivninger</description> <Content> <Base64Container xsi:schemalocation=" kithbase64.xsd" xmlns=" xmlns:xsi=" dhrwoi8vd3d3lmtpdggubm8veg1sc3rkcy9tc2dozwfklziwmdytmdutmjqiihhtbg5zomrzpsjo ( ) dw1lbnq+dqojpcetlsa8zhm6u2lnbmf0dxjlpiblcib1dgvsyxr0igkgzwtzzw1wbgv0lcbtzw4g c2thbcb25njlig1lzcatlt4ncjwvtxnnsgvhzd4ncg==</base64container> </Content> </RefDoc> Merk! XML som brukes som en fast del av en melding skal ALDRI base64-kodes, men legges på vanlig måte som direkte lesbar XML i Content som XML-instans. Base64-koding gjelder altså KUN når det er snakk om vedlegg til en ordinær melding. 5