1. Kaiser Permanente Standards Summit September 7-8, 2011 Stanley M. Huff, MD Huff # 1 A Brief Review of CIMI Plans and Goals London CIMI Meetings November 29, 2011 Stanley M Huff, MD Chief Medical Informatics Officer

2. The Ultimate Value Proposition of CIMI Sharing of: –Data – Information –Applications –Decision logic –Reports –Knowledge Huff # 2

3. Patient

4. Clinical System Approach Intermountain can only provide the highest quality, lowest cost health care with the use of advanced clinical decision support systems integrated into frontline workflow

5. James # 5

6. James # 6 Newborns w/ hyperbilirubinemia

7. Decision Support Modules Antibiotic Assistant Ventilator weaning ARDS protocols Nosocomial infection monitoring MRSA monitoring and control Prevention of Deep Venous Thrombosis Infectious disease reporting to public health Diabetic care Pre-op antibiotics ICU glucose protocols Ventilator disconnect Infusion pump errors Lab alerts Blood ordering Order sets Patient worksheets Post MI discharge meds

8. Strategic Goals Minimum goal: Be able to share applications, reports, alerts, protocols, and decision support with ALL GE customers Maximum goal: Be able to share applications, reports, alerts, protocols, and decision support with anyone in the WORLD

9. Order Entry API (adapted from Harold Solbrig) MUMPS Database Application Service Interface Data VA Order Entry VA Order Services COS Update Medication Order Update PharmacyOrder WHERE orderNumber = “4674” …

10. Order Entry API – Different Client, Same Service (adapted from Harold Solbrig) MUMPS Database Application Service Interface Data Update Medication Order Update PharmacyOrder WHERE orderNumber = “4674” … Dept of Defense VA Order Services COS

11. Dept of Defense Order Entry API – Different Server, Same Client (adapted from Harold Solbrig) GE Repository Oracle Tables Application Service Interface Data Update Medication Order Update PharmacyOrder WHERE orderNumber = “4674” … COS GE Services

12. Order Entry API (adapted from Harold Solbrig) Application Service Interface Data COS...

13. From Ben Adida and Josh Mandel

14. What Is Needed to Create a New Paradigm? Standard set of detailed clinical data models coupled with… Standard coded terminology Standard API’s (Application Programmer Interfaces) for healthcare related services Open sharing of models, coded terms, and API’s Sharing of decision logic and applications

15. Clinical modeling activities Netherlands/ISO Standard CEN 13606 United Kingdom – NHS Singapore Sweden Australia openEHR Foundation Canada US Veterans Administration US Department of Defense Intermountain Healthcare Mayo Clinic HL7 –Version 3 RIM, message templates –TermInfo –CDA plus Templates –Detailed Clinical Models –greenCDA Tolven NIH/NCI – Common Data Elements, CaBIG CDISC SHARE Korea # 15

16. Goal Meet the needs of the clinical modeling community – everyone contributing, benefiting, and actively involved Huff # 16 Clinical Information Modeling Initiative

17. Mission Improve the interoperability of healthcare systems through shared implementable clinical information models. Huff # 17

18. Clinical Information Modeling Initiative Goals Shared repository of detailed clinical information models Using a single formalism Based on a common set of base data types With formal bindings of the models to standard coded terminologies Repository is open and models are free for use at no cost Huff # 18

19. Goal: Models that support multiple contexts Messages Services Decision logic (queries of EHR data) EHR data storage Clinical trials data (clinical research) Normalization of data for secondary use Creation of data entry screens Natural Language Processing

20. Information Model Ideas # 20 Repository of Shared Models in a Single Formalism DCMs CDA Templates openEHR Archetypes CEN Archetypes LRA Models CMETs, HMDs RMIMs CEMsStandard Terminologies Initial Loading of Repository Realm Specific Specializations Realm Specific Specializations Realm Specific Specializations Realm Specific Specializations Realm Specific Specializations V2 “|” HTML UML ADL V2 XML V3 XML V3 Next CEN Archetype CDA SOA Payload CEM LRA OWL CDISC SHARE Translators

21. Roadmap (some parallel activities) Choose a single formalism Choose the initial set of agreed data types Define strategy for the core reference model and our modeling style and approach –Development of “style” will continue as we begin creating content

22. Roadmap (continued) Create an open shared repository of models –Requirements –Find a place to host the repository –Select or develop the model repository software Create model content in the repository –Start with existing content that participants can contribute –Must engage clinical experts for validation of the models

23. Roadmap (continued) Create a process (editorial board?) for curation and management of model content Resolve and specify IP policies for open sharing of models Find a way of funding and supporting the repository and modeling activities Create tools/compilers/transformers to other formalisms –Must support at least ADL, UML/OCL, Semantic Web, HL7 Create tools/compilers/transformers to create what software developers need –Examples: XML schema, Java classes, CDA templates, greenCDA, RFH, SMART RDF, etc.

24. Selected Decisions

25. Decisions (London, Dec 1, 2011) We agree to create and use a single logical representation (the CIMI core reference model) comprising one or more models as the basis for interoperability across formalisms. We approve ADL 1.5 as the initial formalism in the repository using OpenEHR Constraint Model noting that modifications are required. The corresponding Archetype Object Model will be included and adapted as the CIMI UML profile The CIMI UML profile will be developed concurrently as a set of UML stereotypes, XMI specification and transformations

26. Decisions (London, Dec 1, 2011) We will create a workplan to say how we review and update the Constraint Model, reference models and languages including HL7 Clinical Statement Pattern and Entry model of 13606 / OpenEHR. The workplan to be approved in January. The CIMI information model as described in the UML profile must be consistent with the evolving AOM. We will ensure this consistency by creating a single technical working group.

27. Definition of “Logical Model” Models show the structural relationship of the model elements (containment) Coded elements have explicit binding to allowed coded values Models are independent of a specific programming language or type of database Support explicit, unambiguous query statements against data instances

28. Definition of “Logical Model” (cont) Models shall specify a single unit of measure (unit normalization) Models can support inclusion of processing knowledge –Models can support recommend defaults –Models can specify assumed values of attributes (meaning of absence of the item) Examples can be created for the model

29. # 29 Isosemantic Models data 37 % HematocritManual (LOINC 4545-0) HematocritManualModel data 37 % quals Hematocrit (LOINC 20570-8) HematocritModel data Manual Hematocrit Method HematocritMethodModel Precoordinated Model (CIMI deprecated Model) Post coordinated Model (CIMI preferred Model)

30. Isosemantic Models CIMI is committed to isosemantic clinical models in terms of both: –The ability to transform CIMI models into iso-semantic representations in other languages/standards (e.g. OWL, UML, HL7); –The ability to transform CIMI models between iso-semantic representations that use a different split between terminology pre-coordination versus structure.

31. Isosemantic Models (cont) Only include isosemantic models in the repository when they are useful –Re-use of transforms by other enterprises –Re-use of transforms by other processes Lab data transforms Data normalization for clinical trials or secondary use Repository requirement –Know which models are part of the same isosemantic family Transform rules may be reused based on “type of model” –Only difference may be terminology mapping

32. Terminology SNOMED CT will be the primary reference terminology LOINC was also approved as a reference terminology –In the event of overlap, SNOMED CT will be the preferred source CIMI will propose extension to the reference terminologies when needed concepts do not exist –CIMI will maintain the extensions until they are accepted by the RT organization

33. The primary version of models will only contain references (pointers) to value sets We will create tools that read the terminology tables and create versions of the models that contain enumerated value sets Terminology (cont)

34. Three Task Forces Glossary Reference Model Clinical Models

35. Some Principles CIMI DOES care about implementation. There must be at least one way to implement the models in a popular technology stack that is in use today. The models should be as easy to implement as possible. Only use will determine if we are producing anything of value –Approve “Good Enough” RM and DTs –Get practical use ASAP –Change RM and DTs based on use