Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Michael van der Zel september-2010 1
HL7 ITALY “Open Days”HL7 Int. WG RIMBAA Out-of-Cycle Meeting
Rome, Italy15/16-sep-2010
Michael van der ZelRIM R1 Certified Expert, CDA R2 Certified Expert, TOGAF Certified
Michael van der Zel september-2010 2
Agenda
● Who am I?
● Services for RIMBAA project● Noticeable mail
● UMCG & RIMBAA Services
● Some thoughts about some RIMBAA Issues
Michael van der Zel september-2010 3
Me
● Michael van der Zel● Personality (MBTI) INFJ – Idealist, Perfectionist, Chaotic● “INFJs prefer the future and the pathway along which
they aspire for profundity.”
● University Medical Center Groningen, Netherlands● HIT Architect, Information Systems (EHR-S)
● Results 4 Care, Netherlands● Detailed Clinical Models (ISO), HL7 v3
Michael van der Zel september-2010 4
Michael van der Zel september-2010 5
I Work Here
Michael van der Zel september-2010 6
My Office
Michael van der Zel september-2010 7
Inside the Office
Clinical Statement CMET
Michael van der Zel september-2010 8
Tag Cloud
ISO Detailed Clinical Model
Michael van der Zel september-2010 9
Services for RIMBAA project
● Idea approved Rio WGM may-2010
● Project Scope Statement
● SOA WG project lead? – Ann Wrightson
● RIMBAA WG sponsor● http://wiki.hl7.org/index.php?title=Services_for_RIMBAA
● RIMBAA and SOA hl7 mailinglists
Michael van der Zel september-2010 10
Michael van der Zel september-2010 11
Draft Project Proposal (1)1. Project Name: Services on a RIMBAA application; V3 Services
2a. Ballot Type: Informative
3. Sponsoring Group(s) / Project Team Primary Sponsor / Work Group: SOA Co-sponsor Work Group: RIMBAA
4a. Project ScopeThe aim of this project is to develop an informative document containing a concise account of how SOA and RIMBAA concepts work together to provide working interoperability between two RIMBAA applications.
4b. Project NeedThere is limited understanding at this time within WGs of how the SAIF concept of “working interoperability” would be realized in particular contexts. This project addresses that need for understanding, in the specific context of RIMBAA applications and SOA architectural style.
Michael van der Zel september-2010 12
Draft Project Proposal (2)
4c. Success Criteria1) The project process will enable both WGs to gain a consensus understanding of architectural principles around providing working interoperability deploying RIMBAA applications in a SOA interoperability context, informed by SAIF.2) The completed document will provide a summary of consensus thinking between RIMBAA & SOA that will inform future work in both WGs, and also be available as an informative document to the wider HL7 community.
4d. Project Objectives / Deliverables / Target DatesFirst informative ballot: Jan 2011Project End Date: May 2011
5. Project Approval DatesSponsoring Group Approval Date: 20 May 2010Steering Division Approval Date: TBDTechnical Steering Committee Approval Date: TBD
Michael van der Zel september-2010 13
Related?
● SAIF – ArB
● HSSP – joint HL7 + OMG● Practical Guide to SOA in Healthcare vol I & II
● HL7v3 WebServices?? Cannot find the doc anymore?
● Thomas Erl
Michael van der Zel september-2010 14
UMCG RIMBAAServices
Michael van der Zel september-2010 15
Service =
1. Interface – functions a service exposes
2. Payload – data that functions work on/with
3. Behaviour – inner working of a function
Michael van der Zel september-2010 16http://softwareindustrialization.com/content/binary/design.jpg
The Swing
Michael van der Zel september-2010 17
Michael van der Zel september-2010 18
What's beneath the surface?
Traceability
User Request Functional
Techology
EHR-S FMDCM
HL7 v3
Services
Michael van der Zel september-2010 19
What is EHR-S FM?
Michael van der Zel september-2010 20
Summary of Care Record(KernEPD)
● ICT Masterplan Project, Hospital wide
● Easy access to shared data, Patient Demographics, Allergies, Patient History, Trial, Advance Directives, etc.
● Choices made: CUI, HL7 v3, SNOMED CT, Web, Detailed Clinical Models, EHR-S FM
Michael van der Zel september-2010 21
DC.1.4.1 Manage Allergy, Intolerance and Adverse Reaction List
DC.1.4.1#1 The system SHALL provide the ability to capture true allergy, intolerance, and adverse reaction to drug, dietary or environmental triggers as unique, discrete entries.
DC.1.4.1#2 The system SHOULD provide the ability to capture the reason for entry of the allergy, intolerance or adverse reaction.
DC.1.4.1#3 The system SHALL provide the ability to capture the reaction type.
DC.1.4.1#4: The system SHOULD provide the ability to capture the severity of a reaction.
DC.1.4.1#7 The system SHOULD provide the ability to capture the source of allergy, intolerance, and adverse reaction information.
DC.1.4.1#8 The system SHALL provide the ability to deactivate an item on the list.
DC.1.4.1#9 The system SHALL provide the ability to capture the reason for deactivation of an item on the list.
DC.1.4.1#10 The system MAY present allergies, intolerances and adverse reactions that have been deactivated.
DC.1.4.1#11 The system MAY NOT provide the ability to display user defined sort order of list.
DC.1.4.1#12 The system SHOULD provide the ability to indicate that the list of medications and other agents has been reviewed.
DC.1.4.1#13 They system SHALL provide the ability to capture and display the date on which allergy information was entered.
Functionally and mostly about Content
+ CUI Guidance forRecording Adverse Drug Reactions
Michael van der Zel september-2010 22
See Also (di rect)
DC.1.4.1 Manage Allergy, Intolerance and Adverse Reaction List
S.2.2.1 Heal th Record Output
IN.2.5.1 M anage Unstructured Health Record InformationIN.2.5.2 M anage Structured Heal th Record Inform ation
IN.4.3 T erm inology M appingIN.6 Business Rules M anagement
S.2.2.3 Ad Hoc Query and Report Generation S.3.7.1 Cl in ical Decision Support System Guidel ines Updates
IN.4.1 Standard T erm inologies and T erm inology M odelsIN.4.2 M aintenance and Versioning of Standard T erm inologies
DC.2.3.1.1 Support for Drug Interaction Checking
See Also (indi rect)
IN.1.4 Patient Access M anagem ent
IN.2.4 Extraction of Heal th Record Inform ation
IN.2.2 Audi table Records
IN.1.1 Enti ty Authentication
IN.1.2 Enti ty Authorization
IN.1.3 Enti ty Access Control
IN.5.1 Interchange Standards
S.2.2 Report Generation
IN.2.1 Data Retention, Avai labi l i ty and Destruction
Function = aprox. Service
Rule Engine
Care Record Store Service
SNOMED CTTerminology Service
Authorisation Service
Widget & Service
HL7 v3
Query Tool
Document Service
Report Generator
Michael van der Zel september-2010 23
Manage Structured Health Record Information (IN.2.5.2)
1. The system SHALL capture structured health record information as part of the patient EHR.
2. The system SHALL retrieve structured health record information as part of the patient EHR.
3. The system SHALL provide the ability to update structured health record information.
4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy structured health record information.
5. The system SHOULD provide the ability to report structured health record information.
6. The system MAY track structured health record information over time.
7. The system SHOULD provide the ability to retrieve each item of structured health record information discretely within patient context.
8. The system SHALL provide the ability to append corrected structured health record information to the original structured health record information. A specific type of implementation is not implied.
9. The system SHALL provide the ability to append structured health record information to the original structured health record information. A specific type of implementation is not implied.
10. The system SHALL provide the ability to append augmented structured health record information to the original structured health record information. A specific type of implementation is not implied.
The Behaviour of theCare Record Store Serviceand IF Operations
Michael van der Zel september-2010 24
Widget for Editing
<Kerngegeven> Service
Care Record Store Service
Autorisatie Service
Care Record CDR Database
Com m on M odel HL7 v3 Care
Record
Some Application that Displays
Query Tool / Report Generator
Nam e: StructureAuthor: ZelMVersion: 1.0Created: 7-4-2010 10:10:23Updated: 21-4-2010 10:24:48
Terminology Service
"Bus"
Patient Identity Feed <Kerngegeven> T em plate
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«flow»
«abstraction»
Design inspiredby EHR-S FM IN*InfoStructureFunctions andSeparation of Responsibility
Michael van der Zel september-2010 25
IF Kerngegeven Service
● More Functional oriented layer
● GetStatus, GetSummary, GetEntries
● ActivateEntry, CreateEntry, CompleteEntry, NullifyEntry
Michael van der Zel september-2010 26
IF Care Record Store Service
● CRUD Create, Read, Update, Delete
● And Find, Query, Link
Michael van der Zel september-2010 27
Payload● EHR-S FM function(s)
● Detailed Clinical Model
● Convert to Care Record Template
«Act»Reaction :Organizer
«Act»PropensityToAdverseReaction :Organizer
effectiveT im e = geld igheidsperiode overgevoel igheidcode = SCT :420134006 Propensi ty to adverse reactions (cl in ical finding)statusCode = < S tatusCodeava i labi l i tyT im e = -id = -tem plateId = -
«Participation»dataEnterer :DataEnterer
tim e = registrati e datum
«HL7Role»Auteur :AssignedEntity
CMET
i d = zorgverl enerid
«Participation»recordTarget :RecordTarget
«HL7Role»Patiënt :AssignedEntity
CMET
i d = patientn um m er
«Act»CausativeAgent :Observation
code = SCT :246075003 causative agentvalue < CausativeAgent
«Act»ReactionType :Observation
code = SCT :263851003 reactionvalue < ReactionT ype
«Act»Severity :Observation
code = SCT :246112005 severi tyvalue < Severi ty
«Act»Certainty :Observation
code = SCT :246103008 certa in tyvalue < Causal i ty
«Participation»verifier :Verifier
«HL7Role»Supervisor :AssignedEntity
CMET
i d = zorgverl enerid
«rootconcept»PropensityToAdverseReaction
CD
«data,enum erati ...CausativeAgent
Reaction
CD
«data,enum eration»ReactionType
CD
«data,enum er...Severity
CD
«data,enum eration»Certainty
1..*
triggers
DC.1.4.1#4
DC.1.4.1#1
DC.1.4.1#4DC.1.4.1#3
Common Elementsadded from IN*Patient, Authortime, etc. Care Record Template (Logical)
DCM Information Model
Michael van der Zel september-2010 28
<REPC_MT000100UV01.Organizer xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3 multicacheschemas/REPC_RM000100UV.xsd" xsi:type="REPC_MT000100UV01.Organizer"
classCode="CATEGORY" moodCode="EVN"> <templateId root="2.16.840.1.113883.2.4.3.8.1000.9" extension="TODO" /> <id root="2.16.840.1.113883.2.4.3.8.1000.10" extension="ac13267b-a0a7-4741-9363-2230c3f1da03" /> <code displayName="Propensity to adverse reactions (clinical finding)" code="420134006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" /> <statusCode code="active" /> <effectiveTime><low value="20090309" /></effectiveTime> <recordTarget typeCode="RCT"> <patient classCode="PAT"> <id root="2.16.840.1.113883.2.4.3.8.12" extension="6022832"/> <statusCode code="active"/> <patientPerson classCode="PSN" determinerCode="INSTANCE"/> </patient> </recordTarget> <dataEnterer typeCode="ENT"> <assignedEntity classCode="ASSIGNED"> <id root="2.16.840.1.113883.2.4.3.8.1000.2" extension="10006773"/> </assignedEntity> </dataEnterer> <component typeCode="COMP"> <observation classCode="OBS" moodCode="EVN"> <code displayName="causative agent" code="246075003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/> <value displayName="Non-steroidal anti-inflammatory agent (product)" code="16403005" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" xsi:type="CD" /> </observation> </component> <component typeCode="COMP"> <observation classCode="OBS" moodCode="EVN"> <code displayName="certainty" code="246103008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" /> <value displayName="possible diagnosis" code="60022001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" xsi:type="CD" /> </observation>
Care Record XML (Physical)
Michael van der Zel september-2010 29
Behaviour
● HL7 v3 Act Life Cycle
normal
new
obsoletenullified
<nul l>
active
Nam e: SM D Act State M achineAuthor: ZelMVersion: 1.0Created: 12-2-2010 8:16:55Updated: 12-4-2010 0:14:59
completed
obsoletenul l i fy
activate
activate com pletecreate
revise
com plete
reactivate
Michael van der Zel september-2010 30
Summary
● The business requested a way to Record and Share Allergy Records
● EHR-S FM gives base criteria further specified by interviewing the stakeholders
● EHR-S FM function traceability gives necessary InfoStructure services
● Record Detailed with DCM and converted to Care Record CMET
Michael van der Zel september-2010 31
Conclusions
● EHR-S FM IN* Functions are basis for Services in Healthcare
● DCM great method to get details of Content
● HL7 v3 Care Record and Templates a great model for Payload
● HL7 v3 Act State Model basis for Behaviour
● Traceability great tool to link Technology to Functionality and Impact
Michael van der Zel september-2010 32
Grazie per l'attenzioneThanks for your attention
© 2010 Michael van der Zel
mvdzel AT results4care.nl m.van.der.zel AT ict.umcg.nl