kommunikasjon i helsesektoren – spesielt om hl7 og ihe · mtf-seminar • edgar glück,...

MTF-seminar • Edgar Glück, Gardermoen 15.02.2007

Kommunikasjon i helsesektoren –spesielt om HL7 og IHE

Edgar Glück, spesiallege, KITH AS


Edgar Glück

• Bakgrunn som lege• Erfaring fra

• IT innen sykehus• Utvikling av IT-løsninger• Journalsystem• Elektronisk samhandling

• Konsulent hos KITH• Internasjonal standardisering• Utredningsarbeid/modellering/systemanalyse

• Teknisk programleder i IHE-Norge


Agenda

• Kommunikasjonsstandarder• HL7 – Health Level Seven• CEN TC251 – Helseinformatikk • ISO TC215 – Helseinformatikk • IHE – Integrating the Healthcare Enterprise• Norge og kommunikasjonsstandarder• Om fremtiden


Forutsetninger for kommunikasjon

• Omforent kommunikasjonsløsning• X.400, SMTP, TCP/IP, HL7 (til dels i kombinasjon)• Løsning for meldingssikkerhet

• Omforent meldingssyntaks• XML, HL7 v2.x, DICOM eller EDIFACT

• Omforent meldingsinnhold og informasjonsstruktur• Omforent meldingssemantikk

• Definisjon av dataelementer• Definisjon av benyttede koder

• Omforent forretningsprosess


Standarder

• Omforente løsninger dokumenteres som et sett avstandarder

• “Et dokument, etablert gjennom konsensus oggodkjent av et anerkjent organ, som for allmen oggjentatt bruk, gir regler, retningslinjer ellerkarakteristika ved aktiviteter eller deres resultater, med det formål å oppnå maksimal grad av orden i en gitt sammenheng.” (ISO)


Standardiseringsorganisasjoner

Messaging Other Messaging OtherInter- ISO TC215/WG1 ISO/TC215national UN/CEFACT CEFACT D11

W3CEuropean CEN TC251/WG1 CEN/TC251

ISSSISSS/EBES ISSS/XML EBES/EEG9

American HL7 HL7

General Healthcare


Sentralestandardiseringsorganisasjoner

• HL7 – Health Level Seven (1987)• CEN TC251 – Helseinformatikk (1990)• ISO TC215 – Helseinformatikk (1998)• MoU HL7-CEN (2000)• Samarbeid HL7-CEN-ISO (2006)


HL7

Health Level Seven

Sept. 10 and 12, 2006©Copyright HL7, 2006 All Rights Reserved

TC 215

Other Countries / HL7 Affiliates TC 251


30+ International Affiliates

Canada

Australia

NewZealand

Finland

GermanyThe

Netherlands

Japan

United States

Great Britain

India

Taiwan

China

Czech RepublicLithuania

And more…

Mexico

France

Korea


HL7 standarder

• HL7 v2.x meldingsstandarder• HL7 v3 meldingsstandarder• RIM – Reference Information Model• CMET – Common Message Element Types• Datatyper• CDA – Clinical Document Architecture• Annet


HL7 Subject DomainsAdverse event reportingAutomated waveformsMedical transcriptionsReferralsConsultationsClinical trialsNursing care plansData Warehousing

ADTOrder entryResult reportingClinical GuidelinesClinical ObservationsSchedulingPatient careImmunizationsDischarge summaries

… And Growing …


Other Domains

SGML, (now XML)VocabularyCertificationConformanceSecurity transactionsClaims attachmentAccountability, Quality, AssuranceBlood Bank

Personnel ManagementArden SyntaxComponent Based Messaging (i.e., Java)

Visual/Context IntegrationGovernment ProjectsMaster Patient IndexSOAImage Management… And Growing …


HL7 v2.x meldingstandarder i Norge

• Pasientadministrasjon• Rekvisisjons- og svarmeldinger• Hovedsakelig intern kommunikasjon innenfor

et sykehus/organisasjon• Egen meldingssyntaks• Proprietær kommunikasjonsprotokoll

• v2.5 godkjent som ISO-standard


HL7 Version 2.xFirst widely used version 2.1 published in 1991Used in 90%+ provider organizations in the US and widely supported by vendors.Generally requires bi-lateral negotiations between communicating parties.Backwards-fitted (imperfectly to HL7 Reference Information Model (RIM))Not well normalized.

Segments & Data Elements moved to a single location (Chapter 2) only in 2.5 in 2003.

Makes no formal attempt to define processMost implementations are a mix of versions ranging from 2.1 to 2.3 (even though current version is 2.5)


HL7 v3 – Why Version 3?

• As the first Version 2 standards were being accepted and implemented, HL7 began to seek a better way to develop standards

• V2 strategy • A quick-design approach to meet immediate

needs of health care IT• This led to an ad hoc method that is difficult to

coordinate and control• Hence, Version 3


HL7 v3

• Startet arbeidet rundt 1995• Utgangspunkt i metodikk fra CEN TC251

• Basert på modellering• Ny formalisert metode for meldingsutvikling• Bruk av en samordnet referansemodell – RIM• Bruk av XML som meldingssyntaks• Blant annet bruk av ebXML for transport • Foreløpig liten utbredelse


HL7 v3 Reference Information Model -RIM

• En felles konsistent modell for helearbeidsområdet

• Forventet å omfatte all informasjonshåndtering i helsesektoren

• Var opprinnelig meget kompleks• Er blitt meget generisk (nærmest en

metamodell) i samarbeid med CEN• Godkjent som ISO-standard

HL7 RIM 1999

HL7 v3 Reference Information Model


RIM v3 sentrale objekter (v1.21)

Participation

RoleLink

Role

ActRelationship

LivingSubject

Material

Observation

SubstanceAdministration

Procedure

PatientEncounter

Act

Place

Organization

Entity

0..* 0..*0..* 0..*

1 1 110..1

0..1

0..*

0..* 1 0..* 0..* 1

Employee

SchedulableRessource

Access

Patient


HL7 v3 Datatyper

• Stort antall• Begrenset antall basale datatyper• Mange komplekse avledede datatyper

HL7 v3 Datatyper

T : ANY

UncertainValueProbabilistic : UVPprobability : REAL

BinaryData : BIN

EncodedData : EDtype : CScharset : CScompression : CSreference : TELintegrityCheck : BINintegrityCheckAlgorithm : CSthumbnail : ED

LIST<BL>Boolean : BLnot : BL

and(BL x) : BLor(BL x) : BLeor(BL x) : BLimplies(BL x) : BL

1..*1..*

T : ANY

Sequence : LISThead : Ttail : LIST<T>length : INT

CharacterString : SThead : STtail : STlength : INT

CodedSimpleValue : CScode : STdisplayName : ST

LIST<INT>

TelecommunicationAddress : TELuse : SET<CV>validTime : SET<TS>

UniversalResourceLocator : URLscheme : CSaddress : ST

DataTypename : CE

DataValue : ANYdataType : DataTypenonNull : BLnullFlavor : CVisNull : BLother : BLnotApplicable : BLunknown : BL

equals(ANY x) : BL

11

T : ANY

Set : SETisEmpty : BLnonEmpty : BLcardinality : INT

contains(T) : BLcontains(SET<T>) : BLunion(SET<T>) : SET<T>except(T) : SET<T>except(SET<T>) : SET<T>intersection(SET<T>) : SET<T>

T : QTY

Interval : IVLlow : TlowClosed : BLhigh : ThighClosed : BLwidth : T.diffcenter : T

Integer : INT<<type>> diff : INTsuccessor : INTpredecessor : INTnegated : INTtimesTen : INT

times(INT) : INT

Real : REAL<<type>> diff : REALnegated : REALinverted : REALprecision : INTtimesTen : REALtenths : REAL

plus(REAL) : REALminus(REAL) : REALtimes(REAL) : REALpower(REAL) : REAL

PhysicalQuantity : PQ<<type>> diff : PQvalue : REALunit : CVcanonical : PQnegated : PQinverted : PQ

compares(PQ) : BLplus(PQ) : PQminus(PQ) : PQtimes(PQ) : PQtimes(REAL) : PQpower(INT) : PQ

PostalAndResidentialAddress : ADpurpose : CVisBad : BLformatted : ST

PersonNameType : PNformattted : ST

LIST<ADXP>

AddressPart : ADXProle : CS

1..*1..*LIST<PNXP>

PersonNamePart : PNXPtype : CSclassifiers : SET<CS>

1..*1..*

OrganizationName : ONvalue : STtype : CV

MonetaryAmount : MOvalue : REALcurrency : CVnegated : MO

plus(MO) : MOminus(MO) : MOtimes(REAL) : MO

T : ANY

Bag : BAGisEmpty : BL

contains(T) : INTplus(BAG<T>) : BAG<T>minus(BAG<T>) : BAG<T>

T : TS

PeriodicIntervalOfTime : PIVLperiod : T.diffphase : IVL<T>alignment : CS

contains(TS) : BL

T : TS

EventRelatedPIVL : EIVLevent : CVoffset : IVL<T.diff>

occurrenceAt(TS) : IVL<TS>contains(IVL<TS>) : BL

GeneralTimingSpecification : GTSouterBound : IVL<TS>

nextAfter(TS) : IVL<TS>

Rationumerator : QTYdenominator : QTY

Quantity : QTY<<type>> diff : QTYisZero : BL

lessOrEqual(QTY) : BLlessThan(QTY) : BLgreaterOrEqual(QTY) : BLgreaterThan(QTY) : BLcompares(QTY) : BLminus(QTY) : diffplus(diff) : QTY

1111

TT : ANY

NonParametricProbabilityDistribution : NPPD

mostLikely(INT) : SET<UDP<T>>

T

T : QTY

ParametricProbabilityDistribution : PPDstandardDeviation : T.difftype : CV

confidenceInterval(REAL) : IVL<T>probability(IVL<T>) : REALtimes(REAL) : PPD<T>

T : QTY

T

T : ANY

History : HISTearliest : HXIT<T>later : HIST<T>latest : HXIT<T>earlier : HIST<T>

T : ANY

Annotated : ANTnote : CD

T

T : ANY

UncertainValueNarrative : UVNconfidence : CD = note

SET<TS>

PointInTime : TS<<type>> diff : PQ ~ 1soffset : diffcalendar : CSprecision : INT

equals(TS) : BLplus(diff) : TSminus(TS) : diff

0..*0..*

T : ANY

SET<UVP<T>>0..*0..*

type = text/plain<<restriction>>

T : ANY

SET<HXIT<T>>

T : ANY

HistoryItem : HXITvalidTime : IVL<TS>

1..*1..*

InstanceIdentifier : IIextension : STroot : OIDrootPrintName : STtype : CVvalidTime : IVL<TS>

ObjectIdentifier : OIDvalue : INTnamespace : OID

11

ConceptDescriptor : CDcode : STdisplayName : STcodeSystem : OIDcodeSystemName : STcode SystemVersion : SToriginalText : EDmodifier : LIST<CR>translation : SET<CD><<restriction>>

0..*0..*

ConceptRole : CRname : CVvalue : CD

11

0..*0..*

CodedWithEquivalents : CEcode : STdisplayName : STcodeSystem : OIDcodeSystemPrintName : STcodeSystemVersion : SToriginalText : EDtranslation : SET<CV>

<<restriction>>

CodedValue : CVcode : STdisplayName : STcodeSystem : OIDcodeSystemPrintName : STcode SystemVersion : SToriginalText : ST

<<restriction>>

11

0..*0..*


CMET –Common Message Element Type

• Gjenbrukbar komponent• Slipper å definere komponenten på nytt hver

gang den benyttes• Definerer vanlig brukte sett av objekter

• alle objektene og tilhørende attributter tatt fraHL7 v3 RIM

• Kan inkluderes i en vilkårlig melding


CDA – Clinical Document Architecture

• XML-skjema standard• For struktur av kliniske dokumenter• Alternativ til vanlige meldinger


CEN TC251

Helseinformatikk


CEN TC251 for helseinformatikk

• Opprettet 1990• Samordning av europeiske interesser• Motvekt mot eksisterende løsninger• Samler ca. 600 spesialister• Kun medisinske fagområder


Organisering av CEN TC251

• WG I: Informasjonsmodellering – EPJ ogmeldinger

• WG II: Terminologi og representasjon avkunnskap

• WG III: Sikkerhet• WG IV: Teknologi for interoperabilitet


CEN TC251 standarder

• Hovedsakelig meldingsstandarder• Definerer innhold og struktur• Implementert først i EDIFACT• senere XML

• Løsninger basert på modellering• UML• Domain Information Models (DIM)


CEN DIM - domenemodeller

0 , m

0 , m

0 , m

0 , m

0 , m

0 , m

c o p y d e s t i n a t i o n

s p e c i a l i s t s e r v i c e

p r o v i d e r

s p e c i a l i s t s e r v i c e

r e q u e s t e r

0 , m 1 1

s e r v i c e r e q u e s t s p e c i a l i s t

0 , m 1 0 , m 0 , m

s p e c i a l i s t r e l a t e d

s e r v i c e p r o v i d e r

1 0 , 1 0 , m

s e r v i c e r e p o r t s p e c i a l i s t

1 0 , m

0 , m

p a y m e n t g u a r a n t o r

0 , m

0 , m

0 , m

0 , m

p a t i e n t

0 , m 1

1 0 , m 0 , m s e r v i c e

s p e c i a l i s t s p e c i a l i s t s e r v i c e

r e q u e s t e d

1

1

s p e c i a l i s t s e r v i c e p l a n

0 , 1 c l i n i c a l i n f o r m a t i o n i t e m

s p e c i a l i s t s e r v i c e e v e n t

r e p o r t e d

0 , m

e v e n t r e l a t e d

l o c a t i o n

0 , m 0 , m

0 , m

0 , m

s p e c i a l i s t s e r v i c e e v e n t

0 , m

0 , 1

0 , m 1

0 , m 1 , m

0,m0,m

1

0,m

0,m

1

0,m

10,m

0,m

0,m

1

0,m

0,m

0,m

1

0,m 0,m

1

0,m

1

0,m

0,m

0,1

0,m

0,m

0,m

1

0,m

0,m

0,m

1 1

0,m

10,m1 0,m

0,m

0,m

0,m

0,m

0,m

0,m

0,m

0,m

0,m

0,m analysed object

copy destination

diagnostic investigation

diagnostic investigation plan

item

diagnostic investigation result

item

diagnostic service provider

diagnostic service report

diagnostic service request

diagnostic service requester

patient

payment guarantor

related diagnostic service provider

requested diagnostic

investigation

Delivery information subsystem

Subject of care subsystem Prescription set subsystem

1

0..1

1

Delivery location

See 7.11.1

Subject of care

See 7.8.1

Delivery transport

information

See 7.11.2

Payment guarantor and conditions subsystem

Patient matching

information

See 7.8.2

Animal matching

information

See 7.8.4

Animal group

matching informationSee 7.8.6

Void subject of care

See 7.8.10

Patient related party

See 7.8.8

Clinical information

See 7.8.9

Patient supple-mentary

infomationSee 7.8.3

Aimal supple-mentary

informationSee 7.8.5

Animal group supple-mentary

information

See 7.8.7

0..*1

0..11

0..11

0..11

1 0..*

1

0..*

0..*

0..1

Payment details

See 7.10.1

Payment guarantor

See 7.10.2

Payment authori-sation

See 7.10.4

1..*

Healthcare agent subsystem

Healthcare party

See 7.6.4

Healthcare agent in context

See 7.6.1

Healthcare agent

See 7.6.3

Halthcare agent

relationship

See 7.6.2

0..*

1

Healthcare person

See 7.6.6

Healthcare organisation

See 7.6.5

0..*

Prescription set

See 7.7.1

0..1

0..1

Payment conditions

See 7.10.3 0..*

Communicating parties subsystem

Message sender

sends a 6prescription message

receives a prescription 6message

may receive a prescripti6

1

0..1

0..*

Alternate message receiver

See 7.5.3

Designatedmessage receiver

See 7.5.2

See 7.5.1

Specific message subsystem

New prescription message

General message subsystem

Prescription message

See 7.3.1

See 7.4.1

Prescriber

See 7.3.2

Dispensing agent

See 7.3.3

1

0..1

Prescription item subsystem

Prescription item

administra-tive details

See 7.9.1

Instructions

for use

See 7.9.6

Repeat dispensing instructions

See 7.9.7

Medicinal product

See 7.9.3

Medicinal product package

See 7.9.4

Quantity of medicinal product

See 7.9.5

11

0..1

11

0..*

11

Prescribed medicinal product

See 7.9.2

1

{OR}

0..1

Original message

identification

See 7.4.8

0..* 1

0,m

0,m

0,m

0,m

1,m

1,m

1,m

0,m 1,m

0,m 1,m 1,m

1 1 0,m 0,m

1,m

1,m

1,m 1,m 0,m

0,m 0,m 0,m

0,1

1 0,1

1,m 0,1

0,m 0,m

0,m 0,m

1 0,m 0,m

1

0,m 0,1 1

0,m 0,m 0,m 1 1 payment party

subject of investigation

sample

laboratory investigation

related laboratory

service provider

laboratory service report

laboratory service order

intended recipient of report copy

copy destination

laboratory service

provider

laboratory service

requester

laboratory investigation result item

requested laboratory

investigation 0,m


Meldingsstandarder

• Rekvisisjon• Svarrapport• Henvisning• Epikrise• Resept


Andre viktige standarder

• Begrep (ContSys - System of concepts to support Continuity of care)• Begrepsmodell og tilhørende definisjoner

• Datatyper• Subsett av HL7 v3 datatyper

• Komponenter (GPIC)• EPJ (EHRCOM)

• Archetypes• Infrastruktur (HISA)


GPIC –General Purpose Information Component

• Alle dataelementer er fra HL7 v3 RIM v1.13• Følger HL7 regler for relasjoner mellom objekter• Kan lett kombineres og gjenbrukes• Tilsvarer HL7’s Common Message Element

Type – CMET• Noe forskjellige regler for konstruksjon og bruk

Construction of GPICsHealth Level 7 v3 Reference Information Model (RIM)

GPIC A

GPIC B

GPIC C

GPIC D

General Purpose Information Components


CEN 13606 – EHRCOM

• For kommunikasjon av EPJ• Både strukturerte og ustrukturerte opplysninger• Mottaker skal kunne benytte overførte opplysninger

• 5-delt standard• Referansemodell• Archetypes• Kodeverk• Sikkerhet• Modell for informasjonsutveksling


CEN EHRCOM

• EPJ som hierarkisk struktur• Med innbyrdes lenker

Logical building blocks of the EHR

Compositions A clinical care session, encounteror document e.g. test result, letter

EHR The electronic health record for one person

Folders High-level organisation of the EHRe.g. per episode, per clinical speciality

Sections Clinical headings reflecting the workflowand consultation process

Clusters Nested multi-part data structures (tables and interval time series) e.g. audiogram

Elements Leaf nodes with single data valuese.g. reason for encounter, body weight

Data values Date types for instance values e.g. coded terms, measurements with units

Entries Clinical “statements” about Observations,Evaluations, and Instructions


Archetypes

• “Mal” for informasjonselementer og struktursom trengs for å representere en gittopplysning

• Archetypes “befolker” 13606-strukturen• Kan ha regler for lovlige verdier og innbyrdes

relasjoner/avhengigheter• Defineres av eget språk

• Archetype Definition Language (ADL) • alternativt OWL


HISA - Health informatics Service Architecture (Midleware)

• Standard for kommunikasjon mellomapplikasjon (presentasjon) og• Database• Kommunikasjonsinterface

• Tjenesteorientert

geographicnetworklocal network

Patients HC data Activities ResourcesConcepts Authorisations

Integrated and consistent heritage of enterprise data

Healthcarespecific

part

Genericpart

Common services not specifically related to

the healthcare

domain

Providing services for managing

common, fundamental data

of the healthcare organisation

Bitways (technological platform)

Providing facilities for the physical connection of

heterogeneous technological environments

(e.g. Corba, TCP-IP, etc)

Wards

ImagingImaging

MaterialsMaterials

ManagementManagement

............................User Front-ends

• Providing specialised supports to the specific user activities in the various sectors

• Comprise:•presentation layer•presentation logic

Middleware of common services

“complex”,high-level service

(e.g. HCR services)

view/aggregate

“complex”,high-level service

(e.g. authorization)

“complex”,high-level service(e.g. act life cycle)

Formalisedby

HISA Task HISA Task ForceForce

from the enterprise, information

and computational viewpoints


Samarbeid CEN – HL7

• Memorandum of Understanding for utvidetsamarbeid• Modellharmonisering• Gjensidig opplæring• Felles arbeidsgrupper• Metodikk• Fremtidig strategi

• Harmoniseringen gjelder kun HL7 versjon 3


CEN – HL7 v3 Harmonisering

• Metodikk for meldingsutvikling (MDF) (ISO 17113)• Informasjonsmodell (RIM) (ISO 21731)

• Foreløpig ikke meldingsmodeller• Begreper og navnekonvensjoner

• Alle attributter er fra HL7 v3 RIM• Informasjonskomponenter

• CEN GPICs mot HL7 CMETs ( ISO)• Datatyper

• CEN subset av HL7 v3 datatyper ( ISO 21090)• Kodeverk

• HL7-koder benyttes blant annet for strukturelle elementer


Årsak til ufullstendig harmonisering

• HL7 basert på amerikanske forhold og behov• Hovedsakelig for intern kommunikasjon innenfor

en organisasjon• Europeiske behov er avvikende

• Forskjeller i organisering av helsetjenesten• Forskjeller også mellom europeiske land• Ekstern kommunikasjon mellom organisasjoner

• Begrepsapparatet/termer er forskjellig• Ressursmangel (tid og personer)


ISO TC215

Helseinformatikk


Organisering av ISO TC215

• WG1: Informasjonsstrukturer• WG2: Informasjonsutveksling• WG3: Semantisk innhold• WG4: Sikkerhet• WG5: Maskinlesbare kort• WG6: eResept og medisiner• WG7: Medisinsk utstyr• WG8: EPJ


Aktuelle områder for standardisering

• Ikke alle områder egnet for verdensomfattende standarder (ennå)• Innspill av eksisterende standarder fra HL7, CEN

og andre• Overordnede prinsipper

• HL7, CEN TC251 og ISO TC 215 enige om at harmoniseringen skal foregå i ISO TC215


ISO-standarder

• ISO 21731 – HL7 v3 RIM• HL7 v2.5• HL7 CDA R2• ISO 12052 – DICOM• Pasientidentifikator• Identifikasjon av tjenesteytere• ISO 17113 – Message Development Framework

(MDF)


Kommende ISO-standarder

• ISO 21090 – Datatyper• ISO/CEN 13606 EHRCOM – EPJ-arkitektur• Informasjonskomponenter (CMET/GPIC)


IHE

Integrating the Healthcare Enterprise


IHE – Bakgrunn

• Initiativtakere fra USA• RSNA – the Radiological Society of North America• HIMMS – the Healthcare Information and

Management System Society• Formål

• Økt integrasjon mellom helserelaterteinformasjonssystem

• I første omgang mellom system innenfor radiologi


IHE – ikke en standard

• Det kan være flere standarder å velge mellomfor et gitt formål

• Standarder har ofte valgfrie muligheter• Samhandling krever at standardene benyttes

på en ensartet måte• IHE definerer

• hvilke standarder som skal benyttes for et gittformål

• hvordan den enkelte standard skal benyttes


Deltakende land i IHE-Europa

• Frankrike• Tyskland• Italia• England• Norge

• Nederland• Danmark• Sverige• Spania


IHE’s løsning

• Definerer “profiler” av eksisterende standarder• Begrenser valgmulighetene i standardene• Dokumenterer disse i et Teknisk rammeverk

• Kan benyttes for anbudsforespørsler

• Verifiserer interoperabilitet• Tester ut kommunikasjon mellom systemer/utstyr

• Connectathon (årlig i USA og Europa)


Arbeidsområder for IHE

• Radiologi• IT infrastruktur• Laboratoriemedisin• Kardiologi• Pasientbehandling (Patient Care)• ?


IHE – Teknisk rammeverk

• Omfatter et sett av integrasjonsprofiler• De fleste definerer informasjonsutveksling

• Noen definerer andre forhold


IHE integrasjonsprofil

• Sett av transaksjoner• Informasjonsutveksling mellom 2 aktører• Hver aktør utfører én bestemt oppgave

• I innbyrdes definert rekkefølge• Noen må håndteres – andre er frivillige


Aktører

Part som utfører en bestemt oppgaveF.eks.

• Rekvirent• Tjenesteyter• Dokumentkilde• Dokumentarkiv• Dokumentbruker


IHE-profiler – IT infrastruktur


IHE og bruk av standarder

• Benytter eksisterende standarder• HL7 v2.x (meldingsinnhold og struktur)• DICOM (bilder)• HL7 CDA (kliniske dokumenter)• CEN 13606 – EHRCOM (EPJ) • For meldingssyntaks HL7 v2.x og DICOM• For kommunikasjon HL7 v2• For kodeverk delvis HL7 v2.x• + mange andre (ebXML, SQL, ….)


IHE og bruk av standarder

• Kun en standard valgt ut for hvert formål• Problemer som kan oppstå pga. valg av

standarder• Støtter ikke nasjonale krav• I konflikt med nasjonale strategier• I konflikt med nasjonal lovgivning• Økonomiske konsekvenser

• Behov for nasjonale tilpassinger


IHE – Dokumenterte nasjonale utvidelser

• Frankrike• Tyskland• Italia• UK• USA• Norge?


IHE – Organisering

• Forholdet mellom leverandører og brukere• IHE i USA sterkt styrt av leverandører• IHE-Europa på vei mot å bli leverandørstyrt• IHE i mange europeiske land mer brukerstyrt

• Finansiering av IHE-arbeidet• USA har mange store leverandører

• Tradisjon for sponsing av slike aktiviteter• Europeiske leverandører mindre

• Fragmentert marked pga. mange land og språk• Liten tradisjon for sponsing


Norge ogkommunikasjonsstandarder


Informasjonsutveksling i Norge

• Fra ca. 1990• Vellykket innføring av laboratoriesvar• Langsommere aksept for andre meldinger• IHE-Norge etablert i 2003• IHE hovedsakelig fokusert på radiologi• Nasjonalt helsenett fra 2006


Meldingsutveksling i Norge

• Informasjonsutveksling mellom organisasjoner• Laboratorier allmennleger/spesialister• Sykehus allmennleger/spesialister• Allmennleger/spesialister sentrale myndigheter og

RTV• Intern kommunikasjon

• Interfacing av applikasjoner


Implementerte meldinger

• Svarrapport• Klinisk kjemi• Mikrobiologi• Patologi• Røntgen

• Rekvisisjon• Klinisk kjemi• Mikrobiologi• Patologi• Røntgen

• Henvisning• Epikrise

• Resept• Sykmelding• Økonomisk avregning

• Allmennleger/spesialister• Poliklinikker

• Vaksinasjonsovervåking• Sentral rapportering

• NPR• Kreftregisteret• Medisinsk fødselsregister


Valg av kommunikasjonsstandarder

• “Det flotte med standarder er at det er såmange å velge mellom”

• For å få effekt må de fleste velge sammestandard


Europeiske forpliktelser

• CEN medlemsland• må gjøre CEN-standarder til nasjonale

standarder• Land innenfor EU og EØS

• må bruke relevante CEN standarder vedoffentlige anskaffelser


Benyttede standarder

• 1. generasjon• Proprietære løsninger• HL7 v2.1

• 2. generasjon• X.400• CEN ENV (pre-standard) for meldingsinnhold• EDIFACT meldingssyntaks

• 3. generasjon• ebXML/SOAP• CEN ENV (pre-standard) for meldingsinnhold• XML meldingssyntaks• DICOM for bilder


Bildestandarder

• DICOM stort sett enerådende for bilder• Utstrakt bruk innenfor radiologi• Støttes av IHE


Meldingsstandarder i Norge

• HL7 v2.x sentral i IHE• HL7 v2.x benyttes i liten grad i Norge

• Hovedsakelig for interfacing av appplikasjoner• Løsningen må også håndtere ekstern

kommunikasjon• Ivaretar ikke nødvendigvis norske behov

• Hovedsakelig erstattet av CEN pre-standardersiden 1992


IHE i Norge

• Ekstern meldingsutvikling har foregåttuavhengig av IHE• Historisk begrunnet• IHEs valg av standarder• Manglende støtte for brukerkrav• Forpliktelser for bruk av CEN-standarder

• IHE mer relevant for intern meldingsutvikling(applikasjonsinterfacing)


Fremtiden


Interoperabilitet

• Organisatorisk• Definisjon av samhandling mellom parter

(forretningsprosesser)• Semantisk

• Definisjon av informasjonsinnholdet• Teknisk

• Standarder for fysisk overføring av informasjon


Hvorfor bry seg om teknisk løsning?

• “Samme hvordan det løses når det bare fungerer”

• Brukerne burde slippe å bry seg om tekniske løsninger

MEN:• Noen forhold viktigere enn andre


Interoperabilitet og bruk av standarder –1

• Standardiserte forretningsprosesser• Viktige

• Begrepsstandarder• Kritiske – fare for misforståelser dersom ikke

entydige og omforente definisjoner• Samordning gjennom bruk av HL7 v3 RIM• Videre harmonisering gjennom ebXML Core

Component metodikk• Amerikansk språk vs. engelsk


Interoperabilitet og bruk av standarder –2

• Meldingsinnhold og –struktur• Viktig – interoperabilitet neppe mulig uten

standarder• Må kunne håndtere nasjonale/regionale avvik• Konvertering mellom standarder er mulig

• XSLT osv.

• Meldingssyntaks, overføringsstandarder osv.• Ikke kritisk – konvertering mulig


Fremtidige løsninger

• Ikke bekymre seg om hvordan opplysningeneoverføres

• Kun definere datainnholdet og struktur• Definisjoner av dataelementer og benyttet

kodeverk


Interoperabilitet

• Teknisk – vektlagt til nå• Semantisk – i fokus nå• Organisatorisk og prossessmessig – stadig

viktigere

kommunikasjon i helsesektoren – spesielt om hl7 og ihe · mtf-seminar • edgar glück,...

Documents