WSDL in a Healthcare Enterprise Architecture

Lorraine Constable, Constable ConsultingJohn Koisch, Guidewire ArchitectureJean Henri Duteau, GPI

caCIS Overview

• Originated to see how an EHR and HIS fit into traditional cancer care, clinical trials, and research

• Focused on a few main types of services – Query, Retrieve, Locate– Order Request / Fulfillment Management

• Document Services• Referral Management

– Patient Trial Finder• Atomic Services are Choreographed in

communities of systems to achieve Objectives

Proper Abstraction Level

• Services need to be reusable in two dimensions– Deployments– Specifications

• Reusability based on the HL7 Behavioral Framework – Defines

• Community Roles and their obligations• Role decomposition into Interfaces• Behavioral correspondence with Information

– Provides• Reusable Contracts• Defined lines of Authority and Jurisdiction

– WSDLs realize this “stack”, not replace it• WSDLs, WADLs, IDLs, etc are under-specified

• Competency Question: “How and under what conditions can we reuse this allergy service + information model?”

caCIS Solution Space• caCIS defines boundaries

of authority for functions and information types

• Allows architecture to define semantics and communities

• Allows deployments to build to different Integration Points

• Most of all, leverages and provides for reuse

Information, Contracts, Context

• UV RMIMs have a lot of context that must be decomposed for services– Patients, Record Targets, Providers, etc.

• Working with the architects, the breakdown of the full payload into appropriate parameters is done:– Patient becomes a separate parameter– Various providers are either service context or separate parameters– Actual information payload becomes just the required information

• Finally, the context of the service operation, eg. Create referral, is made explicit in the structural semantics of the RMIM– There are no models that will have multiple mood codes.– Fixed mood codes and/or status codes means that we need separate operations

for create and update – We have A LOT of models

• Information and Interface Models are highly reusable within the architecture

Information Model

Interface Model - Logical

Reusable Contracts

• What is reusable are core information models and the abstractions of behaviors (interfaces)– Service Contract

• Achieving reusable Specified Services means that we are ignoring some thorny issues• Comprehensive Fault Management (e.g., business errors

that do not terminate the service contract)• Placeholders for business tokens (security,

communications, encoding)• Services as “expert systems”

Reusable Contracts from the BF

Community Contract

Community Contract

Service ContractService

Contract

Environmental Contract

Environmental Contract

QoSQoS

Policies, Obligations

Policies, Obligations

Information, Invoked Services

Information, Invoked Services

Contract Bindings• caCIS developed a simple model for delivering content that is “lazy”

bound to context-specific things• E.g., fault management that does not invalidate the service

contract even though it invalidates the community contract• Can be used in asynchronous messaging or for responses to service

invocations

Community Contract

Community Contract

Service ContractService

Contract

Environmental Contract

Environmental Contract

Service Response Wrapper

WSDL Generation

• Requirements:– Many reusable information models– Align with Service Architecture– Locally constrained datatypes specifications (with

flavors)– Many behavioral models and patterns

WSDL Generation Supports

• AGILE– Test Driven Development– Contract-driven Development

• Un-hiding the complexity• MDA-driven Design• WSDL Versioning• Cross-functional Teams

• The potential for families of WSDLs in multiple deployment context

Modifying WSDL - Before

Datatype Map

Modifying WSDL - After