de zorg digitaliseren met xml, hl7v3 en web services
DESCRIPTION
De Zorg digitaliseren met XML, HL7v3 en Web Services. Marc de Graauw Informatieketens 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 - PowerPoint PPT PresentationTRANSCRIPT
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
HIB
BSN (“BurgerService
Nummer”)Registry
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
PatientRegistry
Messa-ging
Services
Provider Registry
ActRegistry
UZI (PKI)Registry
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
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)
Marc de [email protected]
Ministry of Healthcare
NICTIZNational
Institute for ICT in Care
CIBGHealthcare
ProfessionalsAuthority
UZI-RegisterHealthcare
Provider Registry
SBV-ZUnique Person Id Registry Provider
Healthcare Information
Broker
Hospitals OthersPharmacistsGP’s
Healthcare System
Suppliers
HealthcareAccess
Providers
Regional Facilities
Gov
Market
Marc de [email protected]
HIB
BSN (“BurgerService
Nummer”)Registry
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
PatientRegistry
Messa-ging
Services
Provider Registry
ActRegistry
UZI (PKI)Registry
Marc de [email protected]
HIB
BSN (“BurgerService
Nummer”)Registry
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
PatientRegistry
Messa-ging
Services
Provider Registry
ActRegistry
UZI (PKI)Registry
Marc de [email protected]
AORTA
• 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
Marc de [email protected]
Messageto HIB
HIB
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Query(to multiple HIS)
Message to HIS
ActRegistry
ActRegistry
Marc de [email protected]
HIB
BSN (“BurgerService
Nummer”)Registry
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
PatientRegistry
Messa-ging
Services
Provider Registry
ActRegistry
UZI (PKI)Registry
Marc de [email protected]
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
Marc de [email protected]
HIB
BSN (“BurgerService
Nummer”)Registry
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
PatientRegistry
Messa-ging
Services
Provider Registry
ActRegistry
UZI (PKI)Registry
Marc de [email protected]
“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
Marc de [email protected]
HIB
BSN (“BurgerService
Nummer”)Registry
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
PatientRegistry
Messa-ging
Services
Provider Registry
ActRegistry
UZI (PKI)Registry
Marc de [email protected]
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
Marc de [email protected]
HIB
BSN (“BurgerService
Nummer”)Registry
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
Healthcare Information
System
PatientRegistry
Messa-ging
Services
Provider Registry
ActRegistry
UZI (PKI)Registry
Marc de [email protected]
Infrastructure example
Marc de [email protected]
Actually, it’s not that simple...
Marc de [email protected]
Healthcare Information Systems
• Must qualify “Well Maintained HIS”– performance, security, maintenance, uptime
etc.
• Implement National Guidelines
• Do logging
• Do local authorizations
Marc de [email protected]
HL7v3, the vocabulary
Marc de [email protected]
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
Marc de [email protected]
TCP
HTTP, SSL
SOAP / Web Services
HL7 Transmission Wrapper
HL7 Query Control Wrapper
lower protocol layers
HL7v3 Layered Model
HL7 Medical Data
Marc de [email protected]
StoryboardsStoryboardsStoryboardsStoryboards
Spec
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
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
Interaction ModelInteraction ModelInteraction ModelInteraction Model
Interaction Diagram
HL7 Development Framework
(HDF)
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}}
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}}
Marc de [email protected]
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.
Marc de [email protected]
RIM (Reference Information Model)
Marc de [email protected]
0..*
1 0..*
1
RIM (Reference Information Model) Backbone
EntityEntity ParticipationParticipation ActAct
ActActRelationshipRelationship
1 1
0..* 0..*
ReferralTransportationSupplyProcedureCondition NodeConsentObservationMedicationAct complexFinancial act
OrganizationLiving SubjectMaterialPlaceHealth Chart
PatientGuarantorHealthcare providerInsurerPractitioner
RoleRole1
0..*
Marc de [email protected]
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 *
0..1 prescribedOrDispensedMedication
typeCode*: <= TPAtherapeuticAgent / therapeuticAgentOf
Medication Combined Order(PORX_RM932000NL)
Voorschriftbericht
0..1 medicationDispenseProcess
0..1 prescribedOrDispensedMedication
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
Marc de [email protected]
Interaction diagram
QURX_AR990110NL MedicationDispense Event Query
Placer
QURX_AR990120NL MedicationDispense Event Query
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
QURX_AR990110NL MedicationDispense Event Query
Placer
QURX_AR990120NL MedicationDispense Event Query
Fulfiller
ZorgInformatieMakelaar
Vragend systeem(bijv. apotheek A)
Bronsysteem(bijv. apotheek B)
Marc de [email protected]
Refinement through ‘Constraints’
Marc de [email protected]
XML fragment
Marc de [email protected]
Person Healthcare
Marc de [email protected]
Marc de [email protected]
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
Marc de [email protected]
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)
Marc de [email protected]
Identification
Marc de [email protected]
Identification in HL7
• HL7v3 datatype Instance Identifier<patientID>
<value extension="012345672" root="2.16.840.1.113883.2.4.6.3"/>
</patientID>
• roots are OID’s (Object IDentifier)
• ITU-T ASN.1
• hierarchy
• extension is local identification system – in this case, BSN (social security number)
Marc de [email protected]
HL7 in the OID tree
Marc de [email protected]
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
Marc de [email protected]
Identification in HL7
Marc de [email protected]
Identification in HL7
Marc de [email protected]
Schema Issues
Marc de [email protected]
Schema's serve multiple masters
• Schema’s serve more than one purpose– design– validation– contract– code generation
• those purposes often need different Schema’s
Marc de [email protected]
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
Marc de [email protected]
The HL7v3 Schema’s
• Let’s look at an example
• Get Person Demographics Query
• Send in person id
• Get name, address, birthdate et cetera
Marc de [email protected]
The HL7v3 Schema’s
Marc de [email protected]
The HL7v3 Schema’s
Marc de [email protected]
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
Marc de [email protected]
The HL7v3 Schema’s
• 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
Marc de [email protected]
The HL7v3 Schema’s
• 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!
Marc de [email protected]
Flatten the Schema’s
Marc de [email protected]
The HL7v3 Schema’s
Marc de [email protected]
The HL7v3 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
Marc de [email protected]
Simplify the Schema’s
Marc de [email protected]
Layering
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
The HL7v3 Schema’s
• 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
Marc de [email protected]
Layer the Schema’s
Marc de [email protected]
The HL7v3 Schema’s
James Clark:
“validity is a relationship between a document and a schema, not a property of
a document”
Marc de [email protected]
The HL7v3 Schema’s
schema’s can be equivalent:
when two schema’s consider
the same set of documents valid
the schema’s are equivalent
Marc de [email protected]
Truth, Trust and Belief
Marc de [email protected]
Authentication
Marc de [email protected]
Authentication
• Smartcard (UZI pass) with:– private key (RSA)– X.509 certificate (includes public key)
• PKI-Government
• Personal pass– guard safely– no sharing– PIN protected
Marc de [email protected]
“Hello world”
SHA-1 hash:5llABaWYzxCrKIdjS...
RSA sig value:c9fVK7vYAdvs2DRZVtS...
Private key:shhhh.....
Public key:MIICHzCCAYygAwIBAgI.....
“Hello world”
RSA sig value:c9fVK7vYAdvs2DRZVtS...
OK
Sender Receiver
Marc de [email protected]
Marc de [email protected]
Security Services (X.800)
• Authentication
• Authorization
• Data Confidentiality
• Data Integrity
• Non-repudiation
Marc de [email protected]
Secure connection
Marc de [email protected]
Secure data
Marc de [email protected]
Security services
Secure connection
Authentication Token
Digital
Signature
Authentication √ √ √
Authorization
Confidentiality √
Integrity √ √
Non-repudiation
√
Marc de [email protected]
Authentication with SSL
Marc de [email protected]
Marc de [email protected]
Marc de [email protected]
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
‘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
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
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
Marc de [email protected]
SOAP Envelope
SOAP Body
Authentication alternatives
HL7 payload
SOAP Header
Auth Token
Marc de [email protected]
SOAP Envelope
SOAP Body
Authentication alternatives
HL7 payload
SOAP Header
Auth TokenAuth Token
Auth Token
HL7 payload
HL7 payload
Marc de [email protected]
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
Marc de [email protected]
Authentication alternatives
• 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
Marc de [email protected]
WS-*
• 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
Marc de [email protected]
Digital Signatures
Marc de [email protected]
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’ ”
Marc de [email protected]
Signed Data
Marc de [email protected]
<code code=”27” codeSystem=”2.16.840.1.113883.2.4.4.5” />
"Dissolve in water"
Marc de [email protected]
Digitally signed token
Marc de [email protected]
What You See Is What You Sign
Marc de [email protected]
<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
body
HL7v3 bericht
Getekendegegevens
Prescription 1
headers
In SOAP Headers
Reference
<ws:SecToken>
<ds:Signature>
<ds:SignedInfo>
<ds:KeyInfo>
Certificate
Digest
Sig value
Reference
Marc de [email protected]
HL7v3 bericht
Meerdere Signatures, 1 certificaatBericht + handtekening
<Signature1>
<SignedInfo>
Certificate A
Digest 1
Sig value 1
Getekendegegevens 1
Prescription 1
Prescription 2
Getekendegegevens 2
<Signature2>
<ds:SignedInfo>
Digest 2
Sig value 2
Certificate
Signature
Getekendegegevens
HL7v3Prescription
persisteren
Marc de [email protected]
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
Marc de [email protected]