Presentation on theme: "Model Driven Software Development KP-IT Shared Application Services – EIS/SOA Rex Lam, Pascal Mattiocco, Enrique Meneses, Michael Rossman April, 2012."— Presentation transcript:
Model Driven Software Development KP-IT Shared Application Services – EIS/SOA Rex Lam, Pascal Mattiocco, Enrique Meneses, Michael Rossman April, 2012
Purpose Propose a KP Modeling Reference Framework. Demonstrate its use for model driven software development (MDSD). Business Benefits Expected from MDSD – better alignment of IT and business – enhanced reusability of services & implementation artifacts – more productive, higher quality development Demonstration cases: health problem list & terminology services – illustrate the modeling approach and benefits – create capabilities beyond whats available from current KPHC data services 4/26/20122 Kaiser Permanente, Shared Application Services - EIS/SOA
Familiar Use Cases For problem list service: Use cases III and VI were examined in order to identify some problem list requirements. HIE scenarios call for inclusion of SNOMED terminology information in documents being exchanged. Contact Center (Stargate) doesnt. 4/26/20123 Kaiser Permanente, Shared Application Services - EIS/SOA
Problem List & Terminology Services Capabilities of problem list service o Provides a list of a patients health problems described using both KP CMT and industry standard terminologies, code sets. Capabilities of terminology service o Returns descriptions for a KP terminology code, plus available codes and descriptions from other coding systems that express the same/similar clinical concepts. Version 1.0 of the service accepts any KP code used in the Epic diagnostic master file (EDG) and returns the corresponding interface term, KPs patient friendly term, plus ICD-9 code(s), the SNOMED code and SNOMEDs fully specified name if these are available. (Note: readily extendible to include ICD-10/11.) 4/26/20124 Kaiser Permanente, Shared Application Services - EIS/SOA
Model Driven Business Process Automation and Service Development 4/26/20125 Kaiser Permanente, Shared Application Services - EIS/SOA Realization Specification of Processes, Services, Components, Flows Identification of candidate Processes, Services, Components, Flows Domain Information Model (IT-oriented logical model) Message & Data Persistence Models (IT-oriented physical models) Domain Concept Model (scope: business knowledge) Identify & scope individual application domains. Each domains business concept model is a foundation block. (CIM: computationally independent model) Each domain information model builds on the foundation. (PIM: platform independent model) Platform message and persistence models align with the info model. (PSM: platform specific model) Some Canonical Modeling Objectives 1.Optimize reuse by developing services with enterprise scope. 2.Align Business Process Automation / SOA with Enterprise Information Architecture. 3.Make service discovery easier for analysts & architects. 4.Support both new and legacy application data sources. 5.Create re-usable service parts that reduce development costs. 6.Reduce specification and design effort for individual services. 7.Build a foundation for automating development of data access services using data virtualization techniques. MDA: CIM MDA: PIM MDA: PSM
MDSD Best Practices 4/26/20126 Kaiser Permanente, Shared Application Services - EIS/SOA Employ UML to express models. Doesnt exclude using other forms of expression as well! Apply KP Modeling Reference Framework (MRF) to obtain uniformity, quality, productivity in modeling process. Generate documentation and implementation components from the models. Create canonical domain concept and information models as the foundation for message and persistence models. Proposal: a model must apply the MRF in order to be canonical.
Roles for Models coordinated layers, not subordinated different adjudicators of correctness / truth 2 domain models, 2 purposes, 2 experts (business/IT) Concept Model A formal representation of the understanding common to experts in the application subject domain, employing language natural to them, conceived in terms of objects and activities, unconstrained by the needs and perspectives and technology imperatives of IT. Information Model A formal representation of digital information about objects and activities in the application domain that is built from the concept model by systematically applying IT design policies & transformation rules. IT implementation concerns enter the picture when we make the transition L0 L1. The Domain Concept Model (L0) is the business interpretation of the Domain Information Model (L1). It provides the standard of truth that is used to validate the information model. 4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA
Modeling Reference Framework 4/26/20128 Kaiser Permanente, Shared Application Services - EIS/SOA Why do we need it for domain concept models? Challenge (only one of several) A domain concept model addresses a specific, limited application domain. Domain models will overlap – that is, two domain models may both express subject matter expert knowledge about one or more business objects or activities of mutual interest. These overlaps are dependencies. They need to be identified. Their presence has an impact on model management (shared, versioned artifacts). Result: Completeness and consistency may not be trivial to obtain when there are many domains of considerable complexity. Foundation for Response The framework helps create domain concept models which have well-understood properties and exhibit a uniformity of construction that helps achieve completeness and consistency. Exploiting the MRF allows MDSD tools to automate model checking and management.
MRF Contents 4/26/20129 Kaiser Permanente, Shared Application Services - EIS/SOA A reference framework provides ready-made data types and structures. N OTE. MRF artifacts will be shared by many domain models. This imposes certain requirements on model management practices and tools.
Terminology Concept Model 4/26/ Kaiser Permanente, Shared Application Services - EIS/SOA Visualization of UML model -- doesnt show everything. KP-IT has 2 standard toolsets that support creation of UML models. Novices and casual users find that becoming productive with either toolset is non-trivial. Is there help?
ModelSheet A tool that pares the effort of getting a domain concept model started down to the bare essentials. Input format: Excel workbook containing description of model. Output format: UML model in format usable by RSA or EA. Impact: ModelSheet allows you to specify a domain concept model even if you arent adept at using one of our standard tools. 4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA
Toolset Choice Models, and model fragments (packages), can be transferred between RSA and EA. 4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA
Terminology Information Model A domain information model is intended to address information management issues which fall outside the scope of the domain concept model. The Modeling Reference Framework includes encoding types for creating information models. Examples Information may be collected about only some elements in the concept model. The information thats collected about an element of the concept model may be incomplete. (The concept model expresses what can be known about the domain, not what is actually known at any particular time.) In order to manage a record of information about some entity that is represented in the concept model, the record must have some feature that allows it to be uniquely identified. The entity itself (e.g. an individual bacterium) has no unique identifier. Auditing concerns typically lead to the inclusion of data which record the times information was collected. This is superfluous in concept models. 4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA
Terminology Information Model 4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA
Roles for Models 4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA Messaging content will generally depend on anticipated usage. Format & encoding is platform specific: SOAP/XML, REST/XML, REST/JSON JMS
Generate Message & Service Schema 4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA The standard toolsets (RSA and EA) can generate schema definitions and web-service interface definitions for SOAP services: XSDs and WSDLs. Input: UML message and service models. (Translation to other formats like JSON can be handled.)
Scenarios for Todays Demo (1) Terminology service called by SOAPUI – successful translation of KP Code (the Epic EDG – diagnoses master file – is the source of these) (2) Problem list service called by SOAPUI – KP code which has no SNOMED and ICD9 codes in the terminology database (the request message, the response message) (3) After updating terminology database, rerun (2) and get response with translations of KP code to SNOMED and ICD9. (4) Add another problem using EPIC workstation client (hyperspace) & rerun (3) to see that the new problem appears. 4/26/ Kaiser Permanente, Shared Application Services - EIS/SOA
Scenario (1) Terminology Service Translation: KP term code from Epic EDG CMT interface term, SNOMED & ICD9 4/26/201218Kaiser Permanente, Shared Application Services - EIS/SOA
Problem List Service 4/26/201219Kaiser Permanente, Shared Application Services - EIS/SOA KphcProblemList capability: retrieving KPHC data about patients health problems from Epics Chronicles database – including KPCodes (proprietary) but no industry standard SNOMED terminology and codes. Terminology Capability: Input: KPCode(s); service returns the corresponding KP Interface term and KP Patient Friendly term, in addition to any available ICD-9 code(s) and SNOMED code and SNOMED Fully Specified Name (most clinically complete description of a problem). Completely independent of the Problem List Domain models & services. The ProblemList capability is retrieving the patients problem list including relevant terminologies (SNOMED, ICD9, etc)
Scenario (2) Problem List Translation: Unsuccessful 4/26/201220Kaiser Permanente, Shared Application Services - EIS/SOA
Scenario (3) Problem List Translation: Successful 4/26/ Kaiser Permanente, Shared Application Services - EIS/SOA
Scenario (4) Updated Problem List New problem added to patients chart during an encounter. Epic Hyperspace GUI for Clinicians 4/26/ Kaiser Permanente, Shared Application Services - EIS/SOA
Model Driven Development of KPHC Data Services 4/26/ Kaiser Permanente, Shared Application Services - EIS/SOA Terminology service used a relational database to hold KP CMT terminology and code set mappings. The database schema was generated from a UML class model representing the database structure. This class model was derived from the terminology domain information model by applying well-known DB design rules. Retrieving data from Epic Chronicles database doesnt involve creating a DB schema. Instead, it was necessary to create a UML class model that represented the relevant portion of the Chronicles database structure, then mapping it to the health problem domain information model.
Model Driven Development of KPHC Data Services 4/26/ Kaiser Permanente, Shared Application Services - EIS/SOA Health Problem Message Model Canonical Health Concern Domain Information Model Legacy (Chronicles) Storage Model request translated request response translated response Goals: (1)Allow service analysts and designers to specify request and response messages in terms of the canonical domain information model – independently of the storage model. (2)Allow implementation of the service query to be reduced to specifying the mapping between the message model and the canonical domain information model. (could be multiple) (one only)
Model Driven Development of KPHC Data Services 4/26/ Kaiser Permanente, Shared Application Services - EIS/SOA Request for Patients Problem List: XML format, data described in terms of the canonical health concern domain info model. Mapping Engine ( works for any canonical domain model ) Compiled mapping between Problem List message model and domain info model. Compiled mapping between domain info model and Chronicles storage model. Translated request for Patients Problem List: XML format, data described in terms of the Chronicles storage model. 1 2 Chronicles Retrieval Engine (works for any canonical domain model) Response: XML format, data described in terms of the Chronicles storage model. 3 Response: XML format, data described in terms of the canonical health concern domain info model. 4 Canonical domain information model: same for all services. Chronicles model: same for all services. Mapping between them: same for all services.