de zorg digitaliseren met xml, hl7v3 en web services

Marc de Graauwmarc@marcdegraauw.com

De Zorg digitaliseren met XML, HL7v3 en Web Services

Marc de GraauwInformatieketens in de Zorg

XL User Group Holland / Zorg & ICT Beurs

18 maart 2009

What we’ll (try to) cover

• Standardisation:– AORTA, the Dutch Healthcare Infrastructure– HL7v3, Vocabulary, Identification, Schema’s– Web Services: SOAP, WSDL, WS-Security

• Truth, Trust and Belief:– Authentication– Digital Signatures

• Versioning

AORTAthe Dutch Healthcare

Infrastructure

BSN (“BurgerService

Nummer”)Registry

Healthcare Information

System

PatientRegistry

Messa-ging

Services

Provider Registry

ActRegistry

UZI (PKI)Registry

The Netherlands

• “AORTA” is the national backbone

• Healthcare Information Systems at institutions and GP’s will be online 24x7

• No clinical data at backbone, only an index of where clinical information resides

• Clinical data stays at the source

• Only possible with dense infrastructure

• Patient, provider registries et cetera

NICTIZ

• (Dutch EHR Standards Organization)• Timeline

– Medication File– Primary Care Summary

• 2003: start• 2006: Healthcare Information Broker delivered • 2006/7: First HIS qualifications• 2009: General availability

NICTIZ & Dutch Healthcare

• Communication between: – Healthcare Provider (GP, hospital etc.)– Healthcare Information Broker (HIB)

• HIB provides:– index of which parties have patient data– no patient data itself– messaging services– aggregation services

• Health Level Seven version 3 (HL7v3)

Ministry of Healthcare

NICTIZNational

Institute for ICT in Care

CIBGHealthcare

ProfessionalsAuthority

UZI-RegisterHealthcare

Provider Registry

SBV-ZUnique Person Id Registry Provider

Broker

Hospitals OthersPharmacistsGP’s

Healthcare System

Suppliers

HealthcareAccess

Providers

Regional Facilities

Market

Nummer”)Registry

System

PatientRegistry

Messa-ging

Services

Provider Registry

ActRegistry

UZI (PKI)Registry

Nummer”)Registry

System

PatientRegistry

Messa-ging

Services

Provider Registry

ActRegistry

UZI (PKI)Registry

• all messages go through healthcare information broker

• three basic patterns:– HIS sends message to other HIS, HIB just

routes– HIS sends message to HIB (mainly for registry

updates and queries)– HIS queries several other HISses, HIB does

registry lookups, accumulates data

Messageto HIB

System

Query(to multiple HIS)

Message to HIS

ActRegistry

Nummer”)Registry

System

PatientRegistry

Messa-ging

Services

Provider Registry

ActRegistry

UZI (PKI)Registry

UZI Registry

• provide Dutch healthcare PKI standards• provide and distribute smartcards with private

keys– to all authorized healthcare institutions– to all authorized healthcare personnel

• provide smartcard readers, and necessary software

• publish and maintain certificate revocation lists • also provides authentication forwarding software

Nummer”)Registry

System

PatientRegistry

Messa-ging

Services

Provider Registry

ActRegistry

UZI (PKI)Registry

“Burger Service Nummer”

• Unique Id for every Dutch person• Based on social security number• Law is amended to permit use in care• Maintain BSN Registry• Provide access to registry

– query for BSN based on name, address, birthdate– query for name, address, birthdate based on BSN– Web Service

• direct and through HIB / HL7v3

Nummer”)Registry

System

PatientRegistry

Messa-ging

Services

Provider Registry

ActRegistry

UZI (PKI)Registry

HIB (Healthcare Information Broker)

• Routing of messages between HIS’s• Act Registry: which HIS has information on

which patient for which kind of data– add/change/delete Act Information

• Patient Registry (partly gateway to BSN)• Provider Registry (partly gateway to UZI)• Collection of query data• Logging, access control• VPN based, TCP/IP, HTTP network

Nummer”)Registry

System

PatientRegistry

Messa-ging

Services

Provider Registry

ActRegistry

UZI (PKI)Registry

Infrastructure example

Actually, it’s not that simple...

Healthcare Information Systems

• Must qualify “Well Maintained HIS”– performance, security, maintenance, uptime

• Implement National Guidelines

• Do logging

• Do local authorizations

HL7v3, the vocabulary

Just enough HL7

• HL7 version 2 : currently used

• HL7v3:– XML based– Reference Information Model

• HL7v3 Message contains:– medical payload– Trigger Event Wrappers (Query Control etc.)– Transmission Wrapper

HTTP, SSL

SOAP / Web Services

HL7 Transmission Wrapper

HL7 Query Control Wrapper

lower protocol layers

HL7v3 Layered Model

HL7 Medical Data

StoryboardsStoryboardsStoryboardsStoryboards

Storyboard

Information ModelInformation ModelInformation ModelInformation Model

State Diagram

Class Diagram

Message DesignMessage DesignMessage DesignMessage Design

2-nd Order 1 choice of 0-n Drug 0-1 Nursing

Interaction ModelInteraction ModelInteraction ModelInteraction Model

Interaction Diagram

HL7 Development Framework

Write storyboards

Determine scope

Determine parties and processes

Restrict domains

Determine state transitions

Determine classes, attributes & associations

Determine application roles

Determine interactions

Determine conformance claims

Develop R-MIM

Specificy HMDs

Determine trigger events

TYPE MPSLOC TYPE MPSLOC CONTAINS {CONTAINS {id[id].TYPE IIDid[id].TYPE IIDnm[name].TYPE STnm[name].TYPE STad[addr].TYPE XADad[addr].TYPE XADph[phon].TYPE XTN ph[phon].TYPE XTN email_addressemail_address [emlAdr].TYPE XTN [emlAdr].TYPE XTN}}

Storyboard

Mevrouw Jansen komt langs bij apotheek ‘De Gulle Gaper’ met een handgeschreven recept van haar huisarts Dr. van Beek. Het recept is voor 2x daags 1 tablet Diazepam 250 mg, gedurende 4 weken. De apotheker van de Gulle Gaper, Dr. Poeder, pakt een een doosje met 5 strips van 10 tabletten en voegt daar een 6e strip van tabletten aan toe. Het geheel van 60 tabletten Diazepam 250 mg wordt overhandigd aan mevr. Jansen, inclusief een bijsluiter en met het gebruiksvoorschrift (van de huisarts) op de verpakking.

RIM (Reference Information Model)

1 0..*

RIM (Reference Information Model) Backbone

EntityEntity ParticipationParticipation ActAct

ActActRelationshipRelationship

0..* 0..*

ReferralTransportationSupplyProcedureCondition NodeConsentObservationMedicationAct complexFinancial act

OrganizationLiving SubjectMaterialPlaceHealth Chart

PatientGuarantorHealthcare providerInsurerPractitioner

RoleRole1

Medication D-MIM

PrescriptionclassCode*: <= SBADMmoodCode*: <= RQO

CMET: (PAT) R_Patient[universal]

(COCT_MT050000NL)

0..1 scopedRoleName

0..1 patient *

typeCode*: <= SBJsubject

CMET: (ASSIGNED) R_AssignedPerson

[identified/confirmable](COCT_MT090102)

0..1 scopedRoleName

0..1 assignedPerson *

typeCode*: <= AUTtime: TS [0..1]

author

MedicationAdministrationRequestclassCode*: <= SBADMmoodCode*: <= RQOeffectiveTime: GTS [0..1]doseQuantity: IVL<PQ> [0..1]

0..1 prescription

0..1 prescribedOrDispensedMedication

typeCode*: <= DIRdirectTarget / directTargetOf

1..1 player *

PrescribedOrDispensedMedicationclassCode*: <= _RoleClassPassive

0..* medicationAdministrationRequest *

typeCode*: <= TPAtherapeuticAgent / therapeuticAgentOf

Medication Combined Order(PORX_RM932000NL)

Voorschriftbericht

0..1 medicationDispenseProcess

typeCode*: <= PRDproduct /productOf

MedicationDispenseProcessclassCode*: <= SPLYmoodCode*: <= _ActMoodCompletionTrackquantity: PQ [0..1]expectedUseTime: IVL<TS> [0..1]

Medication Dispense Event(PORX_924000NL)

Verstrekkingsbericht

CMET: (MMAT) E_MedicationKind

[universal](COCT_MT720000)

0..1 assignedPerson

typeCode*: <= PRFperformer

1..1 representedOrganization *

AssignedPersonclassCode*: <= ASSIGNED

OrganizationclassCode*: <= ORGdeterminerCode*: <= INSTANCE

Interaction diagram

QURX_AR990110NL MedicationDispense Event Query

Placer

Fulfiller

Medication Dispense Eventvia Care Information Broker

Query (QURX_ST990012NL)

QURX_IN990011NL Medication Dispense Event Query

QURX_IN990013NL Medication Dispense Event Query Response

QURX_IN990011NL Medication Dispense Event Query

QURX_IN990013NL Medication Dispense Event Query Response

Placer

Fulfiller

ZorgInformatieMakelaar

Vragend systeem(bijv. apotheek A)

Bronsysteem(bijv. apotheek B)

Refinement through ‘Constraints’

XML fragment

Person Healthcare

Person HealthcareDe klasse Person heeft de volgende attributen:

classCodePSN (Person)Een persoon (mens)

determinerCode INSTANCEEen specifiek persoon (individu)

id Persoonsnummer

name Naam

administrativeGenderCode Geslacht

birthTime Geboortedatum (en evt. –tijd)

deceasedInd Overlijdensindicatie

deceasedTime Overlijdensdatum (en evt. –tijd)

multipleBirthInd Meerlingindicatie

multipleBirthOrderNumber Meerlingvolgnummer

maritalStatusCode Burgerlijke staat

educationLevelCode Opleidingsniveau

Person Healthcare

De klasse Person heeft de volgende associaties:

0..1Employment Beroep

0..* ContactParty Contactpers(o)n(en)

0..1 PatientOfOtherProvider Relatie met de huisarts

0..1 Birthplace Geboorteplaats

0..* CoveredParty Zorgverzekering(en)

Identification

Identification in HL7

• HL7v3 datatype Instance Identifier<patientID>

</patientID>

• roots are OID’s (Object IDentifier)

• ITU-T ASN.1

• hierarchy

• extension is local identification system – in this case, BSN (social security number)

HL7 in the OID tree

A root OID

• 2.16.840.1.113883– HL7.org

• 2.16.840.1.113883.2– HL7 international affiliates

• 2.16.840.1.113883.2.4– HL7 Netherlands

• 2.16.840.1.113883.2.4.6– external id’s

• 2.16.840.1.113883.2.4.6.6– AORTA application-id’s

• 2.16.840.1.113883.2.4.6.6.1215432– root node app in hospital X

• 2.16.840.1.113883.2.4.6.6.1215432.4– prescription number within PIS

Schema Issues

Schema's serve multiple masters

• Schema’s serve more than one purpose– design– validation– contract– code generation

• those purposes often need different Schema’s

Schema's serve multiple masters

• design+ reuseability, composability, simplicity- performance

• validation+ performance, strictness, error messages, completeness- reuseability, composability, simplicity, readability

• contract+ readability, strictness, completeness- performance

• code generation+ simplicity, readability- reuseability, composability

The HL7v3 Schema’s

• Let’s look at an example

• Get Person Demographics Query

• Send in person id

• Get name, address, birthdate et cetera

The HL7v3 Schema’sQUPA_101102_V01• MCCI_MT000300UV01

– COCT_MT040203UV01• COCT_MT150003UV03• COCT_MT030203UV02

• MFMI_MT700711– COCT_MT090300UV01

• COCT_MT150000UV02– COCT_MT070000UV01

» COCT_MT710000UV01• COCT_MT150003UV03• COCT_MT070000UV01

– COCT_MT710000UV01

– COCT_MT090100• COCT_MT150000UV02

– COCT_MT070000UV01» COCT_MT710000UV01

• COCT_MT150003UV03• COCT_MT070000UV01

– COCT_MT710000UV01

– COCT_MT090003• COCT_MT150003UV03

– MCAI_MT900001• QUPA_MT101102_V01• QUPA_MT101101_V01

• The XML document, though abbreviated, isn’t difficult– (SOAP omitted here...)– Transmission Wrapper: message-id, creation date– Act Wrapper: query issuer etc.– Payload: person-id

• The Schema is very simple– 5 includes and 1 element– but not very readable!– the schema inclusion tree is very complex

• Schema’s should be readable– tools can solve this– but they make you dependent on the tool

• Therefore: flatten the Schema’s– remove all includes– put included schema’s where they belong

• For readability: make the Schema resemble the instance

• Readable Schema’s generate readable code!

Flatten the Schema’s

• HL7 datatypes– TS: Point in Time– CS: Simple Coded Value– ST: Character String

• Translate to XSD– datetime, string

• HL7 datatypes predate XSD datatypes• With a lot of HL7 datatypes, nothing happens

except translation to XSD datatypes• Do this in the source, generates much more

readable code

Simplify the Schema’s

Layering

Medical Layer

Control Query Layer

Transmission Layer

Web Services Layer

HTTP Layer

Medical Layer

Control Query Layer

Transmission Layer

Web Services Layer

Initiating Application Responding Application

HL7 Medical Application

HL7 Control Query Processing Application

HL7 Transmission Wrapper Adapter

HL7 web services Messaging Adapter

HTTP Client / Server

SOAPMessages

HL7v3 Messages

HL7v3 Acts

HL7v3 MedicalContent

• layer the Schema’s

• anonimyze with xs:any– <xs:any namespace="##any"

processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

• SOAP Headers, soap:Body anon

• HL7 Transmission Wrapper, Act anon

• HL7 Act Wrapper, medical payload anon

Transmission Wrapper

Control Wrapper

Medical Data

Transmission Wrapper

Control Wrapper

Medical Data

Layer the Schema’s

flatten simplify layer

James Clark:

“validity is a relationship between a document and a schema, not a property of

a document”

schema’s can be equivalent:

when two schema’s consider

the same set of documents valid

the schema’s are equivalent

don’t think of THE schema,

but the SCHEMAS

VARIANTS

V1 V2 V3

Truth, Trust and Belief

Authentication

• Smartcard (UZI pass) with:– private key (RSA)– X.509 certificate (includes public key)

• PKI-Government

• Personal pass– guard safely– no sharing– PIN protected

“Hello world”

SHA-1 hash:5llABaWYzxCrKIdjS...

RSA sig value:c9fVK7vYAdvs2DRZVtS...

Private key:shhhh.....

Public key:MIICHzCCAYygAwIBAgI.....

“Hello world”

RSA sig value:c9fVK7vYAdvs2DRZVtS...

Sender Receiver

Security Services (X.800)

• Authentication

• Authorization

• Data Confidentiality

• Data Integrity

• Non-repudiation

Secure connection

Secure data

Security services

Secure connection

Authentication Token

Digital

Signature

Authentication √ √ √

Authorization

Confidentiality √

Integrity √ √

Non-repudiation

Authentication with SSL

Security with SSL

• Works well only in simple scenario’s

• There is no HL7v3 XML at the client

• The client is (relatively) unsecure

• SSL lays an impenatrable tunnel across the instution’s secure zone

• SSL from server to server is fine, but:

• provides no care provider authentication

Context: clients

• all hospitals, GP’s, pharmacists, other healthcare pros

• clients: any kind of client• latest .NET / Java• older dev environments (Delphi, BV, etc.)• thin client/browser• XSLT heavy• XML / no XML• WS-* / no WS-*• HL7v3 / no HL7v3

Context: HL7v3

• no HL7v3 at client (HL7v2, OZIS, other)• not all data at client

– Act.id– medication codes– patient id (BSN) not yet, is reasonable

demand

• destination not always known at client• either: require all data available at client• or: sign subset of data

‘Lightweight’ authentication token

• X.509 style– message id

• nonce• provides unique identification of message• (if duplicate removal has already taken place)

– time to live• security semantics can expire• time to store & check nonce

– addressedParty• replay against other receivers

SSL security

• premises:– healthcare pro keeps smartcard + pin safe– software to establish SSL tunnel not corrupted– PKI, RSA etc. not broken

• assertion:– healthcare pro sets up SSL tunnel

• assumption:– messages going over SSL tunnel come from healthcare pro

• weakness:– insertion of fake messages in SSL tunnel

• measures:– abort SSL tunnel after period of inactivity, refresh regularly

Lightweight token security

• premises:– healthcare pro keeps smartcard + pin safe– software to sign token not corrupted– PKI, RSA etc. not broken

• assertion:– healthcare pro signed auth token

• assumption:– message and auth token belong together

• weakness:– fake message attached to valid token

Lightweight token security

• signedData:– message id– notBefore / notAfter– addressedParty

• coSignedData– patient id (BSN)– message type (HL7 trigger event id)

• only possible to retrieve same kind of data for same patient at same time from same destination

• weakness: tampering with other message parameters• for queries: acceptable (privacy not much more broken)• for prescription: use full digital signature

Hospital workflow

• doctor makes round

• 360 seconds per patient

• nurse has file ready

• retrieval times are not acceptable

• pre-signing tokens and pre-fetching data just in time

• possible with auth tokens, not (so much) with SSL

SOAP Envelope

SOAP Body

Authentication alternatives

HL7 payload

SOAP Header

Auth Token

SOAP Envelope

SOAP Body

HL7 payload

SOAP Header

Auth TokenAuth Token

Auth Token

HL7 payload

HL7 Medical Application

HL7 Control Query Processing Application

HL7 Transmission Wrapper Adapter

HL7 Web Services Messaging Adapter

HTTP Client / Server

SOAPMessages

HL7v3 Messages

HL7v3 Acts

HL7v3 MedicalContent

• Authentication tokens in SOAP Headers separate them from the content

• HL7 sometimes allows multiple payloads, making this problem worse

• The token has to travel across layers with the paylaod

• This violates layering principles

• WS-* is confused about whether it is a document format or a message format

• document: relevant to the end user

• message: relevant to the mailman

• keep metadata with the document

• putting document metadata in SOAP headers violates layering design principles

Digital Signatures

Some philosophy

• “The President of the United States is John McCain”

• “Karen believes ‘the President of the United States is John McCain’ ”

• “John says that ‘the President of the United States is John McCain’ ”

• “Dr. Jones says: ‘Mr. Smith has the flu’ ”

Signed Data

"Dissolve in water"

Digitally signed token

What You See Is What You Sign

<ws:SecToken>

HL7v3 bericht

Token & XML Signature

HL7v3 bericht

Certificate

Digest

Sig value

XML Signature

Getekendegegevens

Prescription1

<ds:Signature>

<ds:SignedInfo>

<ds:KeyInfo>

Certificate

Digest

Sig value

Componenten

Getekendegegevens

Prescription 1

HL7v3 bericht

Met WSS

<ds:Signature>

<ds:SignedInfo>

<ds:KeyInfo>

Certificate

Digest

Sig value

Getekendegegevens

Prescription 1

SOAP envelope

HL7v3 bericht

Getekendegegevens

Prescription 1

headers

In SOAP Headers

Reference

<ws:SecToken>

<ds:Signature>

<ds:SignedInfo>

<ds:KeyInfo>

Certificate

Digest

Sig value

Reference

HL7v3 bericht

Meerdere Signatures, 1 certificaatBericht + handtekening

Certificate A

Digest 1

Sig value 1

Getekendegegevens 1

Prescription 1

Prescription 2

Getekendegegevens 2

<ds:SignedInfo>

Digest 2

Sig value 2

Certificate

Signature

Getekendegegevens

HL7v3Prescription

persisteren

What we’ve (tried to) cover

• Standardisation:– AORTA, the Dutch Healthcare Infrastructure– HL7v3, Vocabulary, Identification, Schema’s– Web Services: SOAP, WSDL, WS-Security

• Truth, Trust and Belief:– Authentication– Digital Signatures

• Versioning

de zorg digitaliseren met xml, hl7v3 en web services

healthcare provider

registry lookups

registry updates

sends message

online 24x7no clinical

dense infrastructure

zorg digitaliseren

sourceonly possible

Documents

rotary 2015 innovatie in de zorg

leren met ict - het digitaliseren van leren - jurgen...

laurens touwen - zorg binnen bereik

micro-zorg verzekeringen christina de vries. ...

the abcd hl7v3 generator

marc de graauw marc@marcdegraauw.com de zorg digitaliseren...

social media in de zorg (introductie)

qs @ ict & zorg congres

workshop digitaliseren 20140508

microsoft crm voor de zorg

zorg & ict 2011 flyer 1

februari 2018 maand van de palliatieve zorg...

radicale innovatie in de zorg

via uitkomstinformatie naar patiëntgerichte zorg?

hl7v3 schema issues

vicus zorg

social media monitor zorg maart 2011

4.1 zorg en veiligheid

20130326 technologie in de zorg

domeinfolder zorg & welzijn