1 / 25

Model Driven Software Development

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).

olinda
Download Presentation

Model Driven Software Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Model Driven Software Development KP-IT Shared Application Services – EIS/SOA Rex Lam, Pascal Mattiocco, Enrique Meneses, Michael Rossman April, 2012

  2. Purpose Propose aKP 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 what’s available from current KPHC data services Kaiser Permanente, Shared Application Services - EIS/SOA

  3. 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) doesn’t. Kaiser Permanente, Shared Application Services - EIS/SOA

  4. Problem List & Terminology Services Capabilities of problem list service • Provides a list of a patient’s health problems described using both KP CMT and industry standard terminologies, code sets. Capabilities of terminology service • 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, KP’s patient friendly term, plus ICD-9 code(s), the SNOMED code and SNOMED’s fully specified name if these are available. (Note: readily extendible to include ICD-10/11.) Kaiser Permanente, Shared Application Services - EIS/SOA

  5. Model Driven Business Process Automation and Service Development Domain Concept Model(scope: business knowledge) MDA: CIM Identification of candidate Processes, Services, Components, Flows Domain Information Model (IT-oriented logical model) MDA: PIM Specification of Processes, Services, Components, Flows Realization Message & Data Persistence Models (IT-oriented physical models) MDA: PSM • Identify & scope individual application domains. • Each domain’s 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 • Optimize reuse by developing services with enterprise scope. • Align Business Process Automation / SOA with Enterprise Information Architecture. • Make service discovery easier for analysts & architects. • Support both new and legacy application data sources. • Create re-usable service parts that reduce development costs. • Reduce specification and design effort for individual services. • Build a foundation for automating development of data access • services using data virtualization techniques. Kaiser Permanente, Shared Application Services - EIS/SOA

  6. MDSD Best Practices • Employ UML to express models. • Doesn’t 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 modelsas the foundation for message and persistence models. • Proposal: a model must apply the MRF in order to be canonical. Kaiser Permanente, Shared Application Services - EIS/SOA

  7. Roles for Models different adjudicators of correctness / truth • 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. 2 domain models, 2 purposes, 2 experts (business/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. coordinated layers, not subordinated 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. Kaiser Permanente, Shared Application Services - EIS/SOA

  8. Modeling Reference Framework • 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. Kaiser Permanente, Shared Application Services - EIS/SOA

  9. MRF Contents • A reference framework provides ready-made data types and structures. • Note. MRF artifacts will be shared by manydomain models. This imposes certain requirements on model management practices and tools. Kaiser Permanente, Shared Application Services - EIS/SOA

  10. Terminology Concept Model Visualization of UML model -- doesn’t 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? Kaiser Permanente, Shared Application Services - EIS/SOA

  11. 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 aren’t adept at using one of our standard tools. Kaiser Permanente, Shared Application Services - EIS/SOA

  12. Toolset Choice Models, and model fragments (packages), can be transferred between RSA and EA. Kaiser Permanente, Shared Application Services - EIS/SOA

  13. 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 that’s 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. Kaiser Permanente, Shared Application Services - EIS/SOA

  14. Terminology Information Model Kaiser Permanente, Shared Application Services - EIS/SOA

  15. Roles for Models Messaging content will generally depend on anticipated usage. Format & encoding is platform specific: SOAP/XML, REST/XML, REST/JSON JMS Kaiser Permanente, Shared Application Services - EIS/SOA

  16. Generate Message & Service Schema The standard toolsets (RSA and EA) can generate schema definitions and web-service interface definitions for SOAP services: XSD’s and WSDL’s. Input: UML message and service models. (Translation to other formats like JSON can be handled.) Kaiser Permanente, Shared Application Services - EIS/SOA

  17. Scenarios for Today’s 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. Kaiser Permanente, Shared Application Services - EIS/SOA

  18. Scenario (1) Terminology Service Translation: KP term code from Epic EDG  CMT interface term, SNOMED & ICD9 Kaiser Permanente, Shared Application Services - EIS/SOA

  19. Problem List Service The ProblemList capability is retrieving the patient’s problem list including relevant terminologies (SNOMED, ICD9, etc) KphcProblemList capability: retrieving KPHC data about patient’s health problems from Epic’s 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. Kaiser Permanente, Shared Application Services - EIS/SOA

  20. Scenario (2) Problem List Translation: Unsuccessful Kaiser Permanente, Shared Application Services - EIS/SOA

  21. Scenario (3) Problem List Translation: Successful Kaiser Permanente, Shared Application Services - EIS/SOA

  22. Scenario (4) Updated Problem List New problem added to patient’s chart during an encounter. Epic Hyperspace GUI for Clinicians Kaiser Permanente, Shared Application Services - EIS/SOA

  23. Model Driven Development of KPHC Data Services 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 doesn’t 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. Kaiser Permanente, Shared Application Services - EIS/SOA

  24. Model Driven Development of KPHC Data Services (one only) Canonical Health Concern Domain Information Model request translated request translated response response Health Problem Message Model (could be multiple) Legacy (Chronicles) Storage Model • Goals: • Allow service analysts and designers to specify request and response messages in terms of the canonical domain information model – independently of the storage model. • Allow implementation of the service query to be reduced to specifying the mapping between the message model and the canonical domain information model. (one only) Kaiser Permanente, Shared Application Services - EIS/SOA

  25. Model Driven Development of KPHC Data Services Compiled mapping between Problem List message model and domain info model. Request for Patient’s Problem List: XML format, data described in terms of the canonical health concern domain info model. 1 Mapping Engine (works for any canonical domain model) 4 Compiled mapping between domain info model and Chronicles storage model. Response: XML format, data described in terms of the canonical health concern domain info model. 2 Translated request for Patient’s Problem List: XML format, data described in terms of the Chronicles storage model. Response: XML format, data described in terms of the Chronicles storage model. 3 Canonical domain information model: same for all services. Chronicles model: same for all services. Mapping between them: same for all services. Chronicles Retrieval Engine (works for any canonical domain model) Kaiser Permanente, Shared Application Services - EIS/SOA

More Related