WSDL in a Healthcare Enterprise Architecture

1. WSDL in a Healthcare Enterprise Architecture Lorraine Constable, Constable Consulting John Koisch, Guidewire Architecture Jean Henri Duteau, GPI

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

3. 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?”

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

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

6. Information Model

7. Interface Model - Logical

8. 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”

9. Reusable Contracts from the BF Community Contract Policies, Obligations Information, Invoked Services Service Contract Environmental Contract QoS

10. 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 Environmental Contract Service Contract Community Contract

11. Service Response Wrapper

12. WSDL Generation • Requirements: • Many reusable information models • Align with Service Architecture • Locally constrained datatypes specifications (with flavors) • Many behavioral models and patterns

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

15. Modifying WSDL - Before

16. Datatype Map

17. Modifying WSDL - After