SOA Implementation in HL7 and RIMBAA

1. SOA Implementation in HL7and RIMBAA A Demonstration of EA in action in the US NIH NCI’s caCIS Program

2. Abstract • We look at an emerging lightweight platform for extending oncology capabilities to existing EHRs. It is defined by the services that it exposes, and utilizes the HL7 Behavioral Framework to define contracts with arbitrary trading partners, who also are defined by services. • This discussion will detail some of those services from a top down / bottom up perspective, showing how technology is influenced by the interface design, and will detail elements of the interface design and implementation. It will discuss aspects of the enterprise architecture and how these pieces are developed and have dependencies. • Modeling and the SAIF layers are important, but will not be laid out in detail. Discussion will center around the ways that the modeling, the SAIF layers, and the implementation work in harmony and facilitate a rich specification.

3. Goals • Discuss a methodology for using RIM-based components in services • Look at the difference between Service Interfaces, Service Specifications, and Service Implementations • Show how information composition and service composition are related • Show how RIM-based systems (applications, systems, middle-ware, and persistence) can be combined to support good system and enterprise architecture • The relation between RIMBAA and services

4. Outline • Overview of caCIS • Enterprise Architecture and System Architecture • SAIF Service and Interoperability Specifications • Service Implementations - Using RIM-based components in an Enterprise Architecture • Connections between RIMBAA and SAIF • Next steps for RIMBAA and Services

5. caCIS - Overview • Cancer – Clinical Information System • Part of US National Institute of Health’s National Cancer Institute’s caBIG® Program • These capabilities will: • Be highly modular and configurable to address a wide range of clinical settings; • Position users for effective integration with other clinical, administrative and research systems; • Leverage existing HIT standards and extend these standards from an oncology perspective where appropriate; and • Be released with a full set of specifications that can be used by vendors and implementers to leverage all or portions of the caBIG Clinical Information Suite deliverables. • https://wiki.nci.nih.gov/x/zSJyAQ • Project State • We are beginning the design of the integration architecture • We have started reference implementations of services

6. caCIS - Enterprise Architecture and System Architecture

7. caCIS Deployment w Tolven and other EHR Clinical Components, as well as other Clinical Systems Clinical Service Layer Business Service Layer Tolven Clinical Systems Virtual EHR Scaffold Tolven Bus Immunizations History Problem List Outcomes E H R Clinical Systems Referral Choreography Vital Signs History Medication List Complete Patient Profile Allergy PACS Analytics Lab Systems Order Systems

8. caCIS Deployment woTolven, but with other Clinical Systems Clinical Service Layer E H R Clinical Systems Business Service Layer Virtual EHR Scaffold Vital Signs Outcomes Immunizations History Referral Choreography Problem List Medication List Allergy Complete Patient Profile PACS Lab Systems Analytics Order Systems

9. caCIS Candidate E H R Adapter / Trading Partner RIMBAA Architecture

10. SAIF – Service and Interoperability Specifications

11. SAIF – Service and Interoperability Specifications • The SAIF Behavioral Framework gives us a contract framework to work in • Defines who does what when • Gives us the ability to define services and binds them to RIM-based information models • Gives us the ability to bind services together to form communities to get things done • Extensibility between Architecture Iterations • The means to define our “atomic” units

12. caCIS Deployment Logical Overview

13. Interoperability Specifications and Compositional Services

14. Compositional Contracts- Internal • The Specifications choose boundaries based on where we can reasonably lock down behavior • This is not arbitrary – there are design considerations • BUT … we can also build other interoperability Specifications for smaller decomposable chunks • These contracts MUST BE compositional and subsumed by the encapsulating interface • For example, in the caCIS community, conforming to a Referral Interoperability Specification means that you have a service that can resolve a patient and “re-hydrate” the Patient CMET

15. caCIS – SAIF Service Specifications

16. Service Design Consideration • You want to build services that are • Reusable as often as possible • To whatever extent possible, make all commissioning agents interchangeable • Represent an adequate / appropriate contract • Form an encapsulated perimeter of responsibility • Utilize the flexibility of specifying a topic (Referral Consult) versus deploying a useful encapsulation (ReferredTo WSDL and ReferredFrom WSDL)

17. Relationship of Essential Service Components Behavior Payload Behavior Payload • Do() • Restful() • RLUS() • Create() • CreatePatient() • UpdateAge (“Robert Smith”, 29) • UpdateRobertSmithAgeTo29() • Business Agent • Business Resources • Knowledge Object • Business Object • Information Object • Data Object • Nothing Less Meaning More Meaning Semantic Load More Meaning Less Meaning • The Semantic at the Interface is composed between Payload and Behavior • Must consider the other systems in the community • We can find efficiencies by expressiveness in the specification – e.g. substituting II for the full person cmet • This is not laid out for us by HL7 …. You can fit HL7 Messages in at each of the payload levels

18. Services and Systems • Services define the perimeter of a system • What goes “in” is not necessarily what comes “out” • Querie Results can take many shapes • CRUD operations could happen through a service, but the real impact of the CRUD Operation should be apparent at an interface • Services externalize or internalize complexity • There are situations where you want to hide complexity and times where you want to make it very apparent.

19. Services and Acts

20. caCIS – Service Implementations

21. caCIS Service Implementation RIMBAA Architecture

22. caCIS Deployment Phase 1

23. Layers and Granularity of Services • Commonly specified services can be deployed variably • As long as they adhere to the contract, they may encapsulate complex processes and behaviors • This means that “traditional” v3 messages would be business process services that would then execute the work invoked in the message in multiple streams. • Nominally, you can detail a service taxonomy that relates characteristics of services (Process, Utility, Capability, etc) • But the reality is that the contract is invoked through the operation – e.g. if you call “CreatePatient” the details of that should be hidden

24. Persistence • We want to use a RIM-Based persistence Layer • It allows a single physical model to be usable in many deployment scenarios • It allows good engineering to make appearances in a lot of solutions

25. Serialization • Right now, we are using the XML ITS • Business Concepts expressed in the schema that are referenced by the interface • Implies business-level validation at the service implementation – that may not be correct • Forces us to bind our implementation to our serialization models • We want to explore using the RIM ITS • Business Concepts would only be apparent in the operation signature • Business validation and processing could be appropriately handed off to other components • Our implementations would be bound to interfaces rather than to parameters

26. Object Representation • With the RIM-ITS, Objects are bound to the serialization model that is bound to the interface • More componentized • Concepts are part of the contract, so that forces us into decompositions and solid behavioral designs • XML ITS creates an explosion of Objects • We are forced into using tools like jaxb to manage things • But XML ITS is easier to create traceability between architecural layers • There are impedence mismatches between objects (OOD) and SOA, data and information, messages and parameters • Services don’t express isomorphic properties that are implied by the objects that are expressed at the interface

27. Connections between RIMBAA and SAIF

28. RIMBAA and SAIF • RIMBAA is about system design, and SAIF is about the ways that systems communicate • Using SAIF and Services, you can define a system’s perimeter in terms of the services that it exposes • Using RIMBAA and services, you can find engineering efficiencies in the way that you implement services • RIMBAA-constructed components, in other words, is the means by which a contract is fulfilled

29. Next Steps for RIMBAA and Services • Best Practices • SOAP / REST • Provenance, Jurisdiction • Service Implementation Stubs • As part of a SAIF Specification • HL7 Extensions to WSDL

30. Contact • John Koisch • jkoisch@guidewirearchitecture.com