Presentation on theme: "Clinical Information Modeling Initiative Complements of the CIMI team and task forces Especially Stanley M. Huff, MD Chief Medical Informatics Officer."— Presentation transcript:
1 Clinical Information Modeling Initiative Complements of the CIMI team and task forces Especially Stanley M. Huff, MD Chief Medical Informatics Officer Intermountain Health (Utah)Infoway SCSCJune 27, 2012Presented by Dennis Giokas, Chief Technology Officer
2 Agenda Mission and Goals Scope Why a new paradigm? Roadmap Logical ModelsIsosemantic ModelsTerminologyDecisions to DateNext Steps
3 Clinical Information Modeling Initiative MissionImprove the interoperability of healthcare systems through shared implementable clinical information models.
4 Clinical Information Modeling Initiative GoalsMeet the needs of the clinical modeling community – everyone contributing, benefiting, and actively involvedShared repository of detailed clinical information modelsUsing a single formalismBased on a common set of base data typesWith formal bindings of the models to standard coded terminologiesRepository is open and models are free for use at no cost
5 Strategic GoalsMinimum goal: Be able to share applications, reports, alerts, protocols, and decision support with ALL GE customersMaximum goal: Be able to share applications, reports, alerts, protocols, and decision support with anyone in the WORLD
6 Clinical Modeling Activities Netherlands/ISO StandardCEN 13606United Kingdom – NHSSingaporeSwedenAustraliaopenEHR FoundationCanadaUS Veterans AdministrationUS Department of DefenseIntermountain HealthcareMayo ClinicHL7Version 3 RIM, message templatesTermInfoCDA plus TemplatesDetailed Clinical ModelsgreenCDATolvenNIH/NCI – Common Data Elements, CaBIGCDISC SHAREKorea
7 What Do We Want To ModelAll data in the patient’s clinical record, including:AllergiesProblem listsLaboratory resultsMedication and diagnostic ordersMedication administrationPhysical exam and clinical measurementsSigns, symptoms, diagnosesClinical documentsProceduresFamily history, medical history and review of symptoms
8 Intermountain’s Modeling Initiative Number of models createdLaboratory models – 2933Evaluations – 210Measurements – 353Assertions – 143Procedures – 87Qualifiers, Modifiers, and ComponentsStatuses – 26Date/times – 27Others – 400+
9 Value Proposition of CIMI Sharing of:DataInformationApplicationDecision logicReportsKnowledge
10 Modeling Contexts Messages Services, e.g. service calls Decision logic (queries of EHR data)EHR data storageClinical trials data (clinical research)Normalization of data for secondary useCreation of data entry screensOrder entryNatural Language Processing
11 What Is Needed to Create a New Paradigm? Standard set of detailed clinical data models coupled with…Standard coded terminologyStandard API’s (Application Programmer Interfaces) for healthcare related servicesOpen sharing of models, coded terms, and API’sSharing of decision logic and applications
12 Model & terminology must be done together Terminology models and information modelsModels made by data modelers (message standards)Models made by terminology groups (maintenance of terms)“Impedance mismatch” arises when one group is making terms and another group is making the modelPost coordination in a single field in the model is just a way of hiding part of the model
13 Some PrinciplesCIMI is 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 valueApprove “Good Enough” Reference Model and Data TypesGet practical use ASAPChange Reference Model and Data Types based on use
14 Specific Specializations V2 “|”HTMLUMLADLV2 XMLV3 XMLV3 NextCENArchetypeCDASOAPayloadCEMLRAOWLCDISCSHARETranslatorsStandardTerminologiesDCMsCDATemplatesopenEHRArchetypesCENLRAModelsCMETs, HMDsRMIMsCEMsRepository of SharedModels ina Single FormalismRealmSpecific SpecializationsInitial Loading of Repository
15 Roadmap Choose a single formalism Choose the initial set of agreed data typesDefine strategy for the core reference model and our modeling style and approachDevelopment of “style” will continue as we begin creating content
16 Roadmap (cont) Create an open shared repository of models RequirementsFind a place to host the repositorySelect or develop the model repository softwareCreate model content in the repositoryStart with existing content that participants can contributeMust engage clinical experts for validation of the models
17 Roadmap (cont)Create a process (e.g. editorial board) for curating and management of model contentResolve and specify IP policies for open sharing of modelsFind a way of funding and supporting the repository and modeling activitiesCreate tools/compilers/transformers to other formalismsMust support at least ADL, UML/OCL, Semantic Web, HL7Create tools/compilers/transformers to create what software developers needExamples: XML schema, Java classes, CDA templates, greenCDA, FHIR, SMART RDF, etc.
18 Definition of “Logical Model” Models show the structural relationship of the model elements (containment)Coded elements have explicit binding to allowed coded valuesModels are independent of a specific programming language or type of databaseSupport explicit, unambiguous query statements against data instances
19 Definition of “Logical Model” (cont) Models shall specify a single unit of measure (unit normalization)Models can support inclusion of processing knowledgeModels can support recommend defaultsModels can specify assumed values of attributes (meaning of absence of the item)Examples can be created for the model
20 Isosemantic Models - Definition A model that, while different in structure, represents the same semantic content as a second model
21 Isosemantic Models User interface models Storage models Convenient for data entryTypically pre-coordinatedMany variationsStorage modelsOnly one model is designated as the storage modelComprehensive set of qualifiers and modifiersThe storage model is referenced in reports, rules, protocols, data analysisComposition – Decomposition mappings
22 Fully Atomic SysBP Model data138 mmHgSystolicBPSystolicBPObsSubjectsubjectBodyLocationbodyLocationplus “Standard Qualifiers”BodySitebodySiteBodyLateralitybodyLateralityMethodDevicemethodDeviceBodyPositionbodyPosition
23 Post Coordinated subject, loc, device, position data138 mmHgSystolicBPSystolicBPObsmodsSubjectsubjectBodyLocationPrecoordbodyLocationPrecoordplus “Standard Qualifiers”MethodDevicemethodDeviceBodyPositionbodyPositionquals
24 Most Pre-Coordinated Model data138 mmHgPatientSystolicBPRightArmSittingAdultCuffPatientSystolicBPRightArmSittingAdultCuffObsqualsAbnormalFlagabnormalFlagDeltaFlagdeltaFlagReferenceRangeNarreferenceRangeNarRelativeTemporalContextrelativeTemporalContextObservedobservedReportedReceivedreportedReceivedVerifiedverified“Standard Qualifiers”In SubsequentModels
25 Isosemantic Models – Example of Problem e.g. “Suspected Lung Cancer”Complements of Singapore MOHH
26 Isosemantic Models – Example Instances e.g. “Suspected Lung Cancer”
28 Isosemantic ModelsCIMI 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.
29 Isosemantic ModelsOnly include isosemantic models in the repository when they are usefulRe-use of transforms by other enterprisesRe-use of transforms by other processesLab data transformsData normalization for clinical trials or secondary useRepository requirementKnow which models are part of the same isosemantic familyTransform rules may be reused based on “type of model”Only difference may be terminology mapping
30 Terminology SNOMED CT will be the primary reference terminology LOINC was also approved as a reference terminologyIn the event of overlap, SNOMED CT will be the preferred sourceCIMI will propose extensions to the reference terminologies when needed concepts do not existCIMI will maintain the extensions until they are accepted by the RT organization
31 TerminologyThe primary version of models will only contain references (pointers) to value setsWe will create tools that read the terminology tables and create versions of the models that contain enumerated value sets
32 Three Task Forces Glossary Reference Model Clinical Models See Appendices for the first two items
33 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 profileThe CIMI UML profile will be developed concurrently as a set of UML stereotypes, XMI specification and transformations
34 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 / 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.
35 Key Decisions from the Pleasanton & Vancouver Meeting in May CIMI held its 6th group meeting from May 10 – 12, 2012 in Pleasanton California and via video conference in Vancouver. Over 40 people attended in person at the two locations with additional participants attending via WebEx.At this meeting, the group:Reviewed, revised, and approved a reference model developed by the Reference Model Task ForceAgreed to undertake work to map existing clinical models to the reference modelAgreed to establish a new Modeling Task Force to oversee the clinical model mappingEstablish participation guidelines for members of CIMI task forcesReviewed the work of the Glossary Task ForceAgreed that CIMI should not become a separate organization and that an RFI should be issued to identify a parent organization and determine the contributions of collaborating organizationsReviewed the draft RFP to be presented to OMGBegan plans for next face-to-face meeting in September/October 2012
36 Next Steps - RFIThe CIMI IEC is nearing completion of the Request for Information to solicit proposals for the following:Organizational infrastructure: CIMI’s primary focus is on the development of specifications and models. Since CIMI strongly prefers to not create a new organizational structure we are requesting information about how an organization might support CIMI with administrative support, overall governance, and collaboration with other SDOs and major stakeholders. We are interested in an assessment of the resources, facilities, people or skills that collaborating members would be willing to provideIntellectual property (including models and tooling): The development of CIMI models will require the integration of intellectual property (IP) from a number of organizations. The RFI lays out a series of intellectual property issues and asks for suggestions on how these might be addressed.
37 Next Steps – Reference Model Validation Several clinical models will be used for mapping to the CIMI Reference Model. Various examples of these models will be contributed by CIMI members and will be uploaded to the CIMI wiki. The models are:Heart rate (observation entry/measurement) Apgar Score (Entry)BMI (grouping for calculation)Apgar Score (Entry)Glucose tolerance (Entry)Adverse reaction report (composition)Medication order (composition)Problem list (Composition)Care giver reported Nausea (observation entry/assertion)Wound culture (Reflex test results, e.g., automatically triggered orders based on a result)The reference and clinical model TFs will be combined and work together
38 Next Steps – Organizational Structure By consensus the meeting participants agreed that CIMI should not become an organization, but should look to affiliate with another organization. The IEC will continue to work on the development of and circulation of an RFI to lay the groundwork for such an affiliation
42 Glossary - CharterTo define terms and abbreviations that are used in communication relating to CIMI and which may not be commonly understood, or those required for logically grouping these terms, and to document these definitions in a commonly accessible glossaryCriterion for what “may not be commonly understood”: whether there has been debate, or such debate might reasonably be predicted
43 Glossary – SKMT Glossary Tool Joint Initiative Council of Health Informatics Standards Development OrganisationsBest practices documented in ISO TC 215/SC Development of terms and definitions for the Health Informatics GlossaryAllows batch upload of termsIncludes harmonisation process
44 Reference Model - Mission To define a candidate CIMI reference modelDefine a set of requirements for the CIMI reference modelDefine or choose a candidate CIMI reference modelWork with the Clinical Modeling taskforce to test the candidate reference model in the development of a set of initial clinical information modelsCompare the candidate CIMI reference model with the requirements to identify gapsPresent the results at the face-to-face meeting in May
45 Reference Model - Definition The CIMI Reference Model is the underlying Reference Model on which CIMI’s clinical models will be defined.This reference model defines a rigorous and stable set of modelling patterns, including a set of structural patterns, complex data types and demographic classes.All CIMI clinical models (i.e. archetypes) will be defined by constraining the CIMI reference model.Each example instance of a CIMI Clinical Model will be an instance of the CIMI reference model, which conforms to the constraints defined by the associated clinical model.
46 Reference Model Team Members Linda Bird (Chair) – Ministry of Health Holdings, SingaporeMichael van der Zel – Results4Care & LifeLinesGerard Freriks, EN13606 AssociationJosh Mandel, SMARTThomas Beale – Ocean InformaticsDave CarlsonStephen Chu – NeHTAMichael LincolnRahil Qamar SiddiquiMark ShafarmanGE/Intermountain - TBD
47 Reference Model - Requirements General TechnicalSupport for architectural frameworkMultiple purpose & outputsRealm-specific specialisations & extensions (*)Move clinically-relevant attributes to clinical patternsModel mapping & query support (*)Versioning & Approval status (*)StabilityGeneral governanceGovernance, cost and licensingClinician verification (*)Inter-organisation semantic interoperability
48 Reference Model - Requirements StructuralData elementsRelationships / LinksData groupsTree structureEntry / Clinical statementCompositionData absentInformation PatternConcept modelParticipationParties and roles
49 Reference Model - Requirements Terminology BindingSemantic / Value / Name binding (*)Relationship semantics (*)Concept model terminology definition (*)TranslationsDatatypeCommon datatypesDatatype constraints & mappingsInheritance from single typePrimitive & string-based datatypesComplex datatypesAttachment, Ordinal, Codeable concept, Coding, Identifier, Interval, Quantity, Ratio
50 Reference Model - Resolution By formal vote of the CIMI membership present the following resolution was passed unanimously:Resolution: The reference model presented by the Reference Model Task Force is endorsed as a starting point and establishes the direction that CIMI wishes to take. We expect that this model will be tested and modified as modeling work continues.
51 Reference Model Selection – Starting Point openEHR reference model selected as starting point by 6 of 9 membersReasonsThe range of existing archetypes, tooling, infrastructure, methodology and documentation;Established reference model tested by multiple authoring participants;Can benefit from lessons learned by many implementations;Able to start designing clinical models straight away;Demonstrable use within a two-level modelling architecture;Specification is freely available on the web to read and redistribute without cost;Willingness of the organisation to work with CIMI and make changes as needed to meet CIMI’s needsConcerns Complexity of current model - a simplified model is preferred;Need to bridge the gap between the model and the requirements;Requires us to work together to simplify and improveIt is not a standard, and there are IP concerns relating to the specificationsRequires work to develop a UML-based profile and editing environment
Your consent to our cookies if you continue to use this website.