WSDL in a Healthcare Enterprise Architecture Lorraine Constable, Constable Consulting John Koisch, Guidewire Architecture Jean 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 Service Contract Environmental Contract QoS Policies, Obligations Information, Invoked Services

Contract Bindings Delivery Structure Context Binding Infrastructure Configuration Faults Business Information 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 Service 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