Direktoratet for e-helse
Pb. 6737 St. Olavs plass
0130 OSLO
Deres ref.: 16/295-1
Vår ref.: 16/2116
Dato: 23.05.2016
Legeforeningen takker for forespørselen om å avgi høringsuttalelse til utkastet for en norsk profil for IHE XDS metadata.
Legeforeningen mener:
- Legeforeningen støtter etableringen av en norsk profil for IHE XDS metadata
- Legeforeningen kan bistå Direktoratet for e-helse i finne klinisk kompetanse for å lage en versjon som er leselig for helsepersonell, ved å benytte meta-data i utkastet i mange og komplekse bruksscenarier.
- Dette kan være både mer nyttig og mindre kostnadskrevende enn en pilotering.
Samarbeidet om pasientene som Samhandlingsreformen legger opp til forutsetter en helt annen samarbeidsform og en helt annen informasjonsdeling enn det vi har i dag - og målbildet for "én innbygger - én journal" er 2040. IHE XDS er i seg selv en interessant modell, og vil kanskje kunne dekke noen av våre behov for dokumentdeling i påvente av en felles journal. Legeforeningen ønsker derfor spesifikasjonene velkommen.
IHE XDS er etter det Legeforeningen kjenner til den rådende standarden for innsyn i dokumenter på tvers av journalsystemer fra forskjellige leverandører, og en norsk profil vil både gjøre Norge mer interessant som marked for utenlandske leverandører i tillegg til at norske leverandører kan bli mer relevante internasjonalt. Det behøves mekanismer og spesifikasjoner for dokumentdeling på andre måter enn 1-til-1 meldingsutveksling hvis man skal få bedre informasjonsdeling i helsetjenesten, og bruk av IHE XDS er et riktig steg på veien.
Direktoratet ba om uttalelser fra helsepersonell om diverse metadata var relevante og hadde nytteverdi i klinikken. Dessverre er utkastet skrevet i en meget teknisk form, uten bruksscenarier legene kan bruke for å visualisere nytten. Eksemplene er uttrykt som XML-kode, ikke i helsefaglig forståelig tekst. Utkastet er ikke tilrettelagt for å få kommentarer fra helsepersonell. Det gjør også at det er vanskelig å identifisere feil, mangler og svakheter. Legeforeningen synes derfor det er vanskelig å gi presise tilbakemeldinger på de forskjellige attributtene. Det vil være påkrevet at Direktoratet inviterer Legeforeningen til å oppnevne leger som kan jobbe sammen med Direktoratet om å utarbeide bruksscenarier som kan brukes for å verifisere hvilke attributter man har behov for. Det er å forvente at det er både mer nyttig og mindre kostnadskrevende enn en pilotering.
Legeforeningen savner også diskusjon om hvordan adgangskontroll skal håndteres med de foreslåtte attributter.
Det bør være fleksibelt hvilket kodeverk som kan brukes, sålenge kodeverket er kodet med en unik kode. Det kommer jo til nye kodeverk hele tiden, og det kan bli aktuelt å utvide reportoaret pga. innkjøp av utenlandske systemer f.eks.
Utkastet angir attributter til elektroniske dokumenter som sier noe om det elektroniske dokumentet, i prinsippet ikke noe om innholdet. Derfor kaller man det "meta-data" - data om data - som når dokumentet er opprettet, hvem som opprettet det og hvor det er tilgjengelig. Dette er imidlertid ikke gjennomført konsekvent - på noen områder går man bort fra "meta" og fokuserer direkte på innholdet i det elektroniske dokumentet - uten at det er angitt hvorfor man gjør det på ett område, og ikke på et annet.
Man har for eksempel en "eventCodeList" som beskriver kliniske tiltak/prosedyrer som er utført - iht. Standard prosedyrekodeverk - og som formodentlig er beskrevet i dokumentet. Hva man gjør om dokumentet omtaler flere prosedyrer eller benytter flere kodeverk står ikke omtalt. Det vil kunne være veldig aktuelt for radiologi. Det ville vel egentlig vært mer naturlig at prosedyrekode og kodeverk var en del av det elektroniske dokuments data - ikke "meta-data".
Man har også attributter for "serviceStart" og "serviceStop" som er tidspunktene for når en "klinisk tjeneste/ kontakt" starter og stopper - uten at man har presentert noen modell for hva man mener med klinisk tjeneste/kontakt eller hvordan man linker dokumenter som tilhører samme tjeneste/kontakt - det er det nemlig ingen kode for.
Den eneste muligheten er å lage "SubmissionSet" og "Folder", men det er ingen klare regler for hvordan disse mekanismene faktisk skal benyttes. Her ville det vært naturlig med standarder - og eksempler.
Det er ellers nyttig at man kan angi at dokumentets innhold omhandler en annen tidsperiode enn det tidspunktet dokumentet ble opprettet på. Det hadde imidlertid vært bedre om man også kunne knytte dette til kjente begreper som episode, periode, tilfelle, forløp, osv. Dette er dessverre ikke, så vidt vi vet, en del av den internasjonale standarden, og dermed heller ikke tilgjengelig i en norsk profil.
"confidentilalityCode" er det eneste attributt som refererer til sikkerhet / tilgangskontroll - og her skriver man at det er obligatorisk, men alltid skal settes til "Normal". Dette er ikke begrunnet. I det hele er ikke tilgangskontroll omtalt i dette dokumentet, og dermed heller ikke de attributter som man kunne tenke seg å benytte i så måte. Dersom man samarbeider om et forløp på tvers av organisasjoner bør kanskje tilgangen være annerledes enn om man kun har sporadisk med pasienten å gjøre? Hva gjør man hvis en bruker ("Document Consumer") skal ha tilgang til deler av informasjonen i en "Folder" eller et "SubmissionSet"? Har man i det hele tatt de "meta-data" attributter som er nødvendige og tilstrekkelige til å håndtere en tilgangskontroll som tilfredsstiller lover, forskrifter og regler? Det bør dokumenteres, og bør være den første testen av utkastet.
Man benytter ikke koden "intendedRecipient" i denne profilen - uten at det er begrunnet. Vi ville anta at det var av betydning hvem dokumentet faktisk var laget for. Man uttrykker seg forskjellig om man skriver til pasienten, til fastlegen eller til en sub-spesialist.
Spesielt dokumenter som er utarbeidet spesifikt for samarbeidende helsepersonell for ett bestemt forløp burde det være av interesse å få dokumentert. Jeg vil tro at de fleste leger vil skru av alle dokumenter ment for annet enn leger, og det vil vel gjelde for mange av de andre yrkesgruppene også. Det er ikke tilstrekkelig å vite hvem som har skrevet det eller hvilken informasjonskategori ("typeCode") det tilhører.
Ellers viser eksempelet for "AuthorSpeciality" til "authorRole" - vi antar det er en skrivefeil.
"SoureceId" er foreslått ikke benyttet, uten begrunnelse. Samtidig angir, så vidt vi kan se, den engelske teksten begrunnelsen for hvorfor det trengs - nemlig hvis en "broker" samler dokumenter fra forskjellige kilder i ett "SubmissionSet" eller en folder. Da er det viktig å kunne skille mellom hvilken organisasjon som opprettet sammenstillingen og hvor informasjonen stammer fra. Man vil for eksempel kunne få forskjellig røntgendokument - og dokumentet vil kunne ha forskjellig struktur - avhengig av om man får det direkte fra radiologisystemet og indirekte via journalen.
Med hilsen
Den norske legeforening
Geir Riise
Generalsekretær
Bjarne Riis Strøm
Avdelingsdirektør