model driven software development

Model Driven Software Development

KP-IT Shared Application Services – EIS/SOARex 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 what’s available from current KPHC data services

4/26/2012 2Kaiser Permanente, Shared Application Services - EIS/SOA

Familiar Use CasesFor 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.4/26/2012 3Kaiser Permanente, Shared Application Services - EIS/SOA

Problem List & Terminology Services

Capabilities of problem list serviceo Provides a list of a patient’s health problems described using both

KP CMT and industry standard terminologies, code sets.

Capabilities of terminology serviceo 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.)


Model Driven Business Process Automation and Service Development


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

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


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 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 ModelA 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 ModelA 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


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


A reference framework provides ready-made data types and structures.

NOTE. MRF artifacts will be shared by many domain models. This imposes certain requirements on model management practices and tools.

Terminology Concept Model


class KPTerminology - Concept Model

ClinicalConceptClinicalTerm

ICD9Term

KPRegion

KPTerm

+ isPatientFriendly :boolean+ isPhysicanFriendly :boolean

SNOMEDTerm

+ isFullySpecified :string+ isPreferred :string

Thing

1..1

denotes

1..1

1..*

isInterfaceTermFor

0..*

0..*

represents

1..1

0..*

KPTermExpresses

1..1

0..*

ICD9TermExpresses

1..1

1..1

isInvisibleFor

1..*

0..*

expressesMeaningOf

1..1

0..*

SNOMEDTermExpress

1

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?

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.

4/26/2012 Kaiser Permanente, Shared Application Services - EIS/SOA

Toolset Choice

Models, and model fragments (packages), can be transferred between RSA and EA.


Terminology Information ModelA 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.

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


Terminology Information Model


Roles for Models


Messaging content will generally depend on anticipated usage.

Format & encoding is platform specific:

SOAP/XML,REST/XML,REST/JSONJMS

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

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.


Scenario (1) Terminology Service

Translation: KP term code from Epic EDG CMT interface term, SNOMED & ICD9


Problem List Service


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.

The ProblemList capability is retrieving the patient’s problem list including relevant terminologies (SNOMED, ICD9, etc)

Scenario (2) Problem ListTranslation: Unsuccessful


Scenario (3) Problem ListTranslation: Successful


Scenario (4) Updated Problem ListNew problem added to patient’s chart during an encounter.

Epic Hyperspace GUI for Clinicians


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.



Health Problem Message Model

Canonical Health Concern Domain Information Model

Legacy (Chronicles) Storage Model

request

translated

request

responsetransla

ted

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)

(one only)



Request for Patient’s 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 Patient’s 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.

model driven software development

Documents

individual services

psmkaiser permanente

kp terminology code

kp code

domains business concept

problem list requirements

info model

business benefits