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