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 what’s available from current KPHC data services
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
2
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
3
Problem List & Terminology Services
Capabilities of problem list service
o Provides a list of a patient’s 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, 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.)
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
4
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)
Specification
MDA: PIM
of Processes, Services, Components, Flows
Realization




Message & Data Persistence Models
(IT-oriented physical models)
Identify & scope individual application domains.
Each domain’s business concept model is a foundation block.
Each domain information model builds on the foundation.
Platform message and persistence models align with the info model.
MDA: PSM
(CIM: computationally independent model)
(PIM: platform independent 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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
5
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
6
Roles for Models
different
adjudicators of
Concept
Model
correctness
/ truth
2 domain models, 2 purposes, 2
experts (business/IT)
A formal representation of the
understanding common to
experts in the application subject Information Model
domain, employing language
A formal representation of digital
coordinated
natural to them, conceived in
information about objects and
layers, notterms of objects and activities,
activities in the application domain
subordinated
unconstrained by the needs and
that is built from the concept
perspectives and technology
model by systematically applying IT
imperatives of IT.
design policies & transformation
rules. IT implementation concerns
The Domain Concept Model (L0)enter
is the
the business
picture when we make
interpretation of the Domain Information
the transitionModel
L0  L1.(L1).
4/26/2012
It provides the standard of truth that is used to
Kaiser Permanente, Shared Application Services - EIS/SOA
validate the
information model.
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
8
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
9
Terminology Concept Model
Visualization of
UML model -doesn’t show
everything.
class KPTerminology - Concept Model
Thing
1..1
1..1
represents
denotes
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.
0..*
1..1
ClinicalConcept
ClinicalTerm
expressesMeaningOf
1..1
0..*
1..1
1
KPTerm
1..1 +
+
ICD9Term
SNOMEDTerm
isPatientFriendly :boolean
isPhysicanFriendly :boolean
1..*
isInvisibleFor
1..1
+
+
0..*
isFullySpecified :string
isPreferred :string
0..*
0..*
SNOMEDTermExpress
1..*
isInterfaceTermFor
ICD9TermExpresses
KPRegion
0..*
KPTermExpresses
Is there help?
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
10
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.
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 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.
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
Messaging
content will
generally
depend on
anticipated
usage.
Format &
encoding is
platform
specific:
SOAP/XML,
REST/XML,
REST/JSON
JMS
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
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.)
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
17
Scenario (1) Terminology Service
Translation: KP term code from Epic EDG  CMT interface term, SNOMED & ICD9
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
18
Problem List Service
The ProblemList capability is
retrieving the patient’s problem list
including relevant terminologies
(SNOMED, ICD9, etc)
KphcProblemList capability:
Terminology 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.
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
19
Scenario (2) Problem List
Translation: Unsuccessful
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
20
Scenario (3) Problem List
Translation: Successful
4/26/2012
Kaiser Permanente, Shared Application Services EIS/SOA
21
Scenario (4) Updated Problem List
New problem added to patient’s chart during an encounter.
Epic Hyperspace GUI for Clinicians
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
22
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
23
Model Driven Development of KPHC Data Services
Canonical Health Concern
Domain Information Model
(one only)
Health Problem
Message Model
(could be multiple)
Legacy (Chronicles)
Storage Model
(one only)
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.
4/26/2012
Kaiser Permanente, Shared Application Services - EIS/SOA
24
Model Driven Development of KPHC Data Services
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
Response: XML format,
data described in terms of
the canonical health
concern domain info
model.
Response: XML format, data
described in terms of the
Chronicles storage model.
Compiled mapping
between domain info
model and Chronicles
storage model.
2
3
Chronicles Retrieval Engine
(works for any canonical domain
model)
4/26/2012
Compiled mapping
between Problem List
message model and
domain info model.
Translated request for
Patient’s Problem List: XML
format, data described in
terms of the Chronicles
storage model.
Canonical domain information
model: same for all services.
Chronicles model: same for all
services. Mapping between them:
same for all services.
Kaiser Permanente, Shared Application Services - EIS/SOA
25