SOA Implementation in HL7 and RIMBAA

SOA Implementation in HL7and RIMBAA

A Demonstration of EA in action in the US NIH NCI’s caCIS Program

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.

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

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

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

caCIS - Enterprise Architecture and System Architecture

BusinessServiceLayer

Clinical ServiceLayer

caCIS Deployment w Tolven and other EHR Clinical Components, as well as other Clinical

Systems

PACS

Lab Systems Order Systems

Referral

OutcomesE H R Clinical Systems

Allergy

Medication List

History

Vital Signs

Tolven Clinical Systems

Problem List

History

Immunizations Tolven Bus

VirtualEHR Scaffold

CompletePatient Profile

Choreography

Analytics

BusinessServiceLayer

E H R Clinical Systems

Clinical ServiceLayer

caCIS Deployment wo Tolven, but with other Clinical Systems

Allergy

Medication List

Problem List

History

Immunizations

Vital Signs

PACS

Lab Systems

Order Systems

VirtualEHR Scaffold

CompletePatient Profile

Choreography

Analytics

Referral

Outcomes

caCIS Candidate E H R Adapter / Trading Partner RIMBAA Architecture

SAIF – Service and Interoperability Specifications

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

caCIS Deployment Logical Overview

Interoperability Specifications and Compositional Services

Interoperability Specification

Commissioning System Role

Proxy For

Commissioning Agent (Required Interface Implementation)

Responsible System Role

Responsible Agent / Service Interface (Provided Interface Implementation) Operation

CDA Creation Referrer N/A Tolven 1 DocumentExchangeCDADocumentBuilderService buildDocument

DocumentExchange ReferrerCDA Builder Choreography Patient Registry

DemographicsService

retrievePersonDemographics

DocumentExchange ReferrerCDA Builder Choreography E H R AllergyService retrieveAllergyList

DocumentExchange ReferrerCDA Builder Choreography E H R

MedicationListService retrieveMedicationList

Referral Referrer N/A Tolven 1 OrderRequestManager ReferredTo createReferralOrder

OrderRequestManager ReferrerReferralConsult Choreography Referral Provider ReferredTo createReferralOrder

Referral Provider N/A Tolven 2 OrderRequestManager ReferredFrom acceptReferralOrder

OrderRequestManagerReferralProvider

ReferralConsult Choreography Referrer ReferredFrom acceptReferralOrder

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

Interoperability Specification

Commissioning System Role

Proxy For

Commissioning Agent (Required Interface Implementation)

Responsible System Role

Responsible Agent / Service Interface (Provided Interface Implementation) Operation

Resolve Patient OrderRequestManagerReferral, E H R

Referral_Consult Choreography

Patient Registry (Shared jurisdiction, shared trust) PatientCorrelation

resolvePatientIdentifier()

Patient Registry (Shared jurisdiction, shared trust)

OrderRequestManager

PatientResolution Choreography

Patient Registry (Organizational jurisdiction, local trust)

PatientDemographics getPatientById()

caCIS – SAIF Service Specifications

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)

Relationship of Essential Service Components

• Business Agent• Business Resources• Knowledge Object• Business Object• Information Object• Data Object

• Nothing

• Do()• Restful()• RLUS()• Create()• CreatePatient()• UpdateAge

(“Robert Smith”, 29)

• UpdateRobertSmithAgeTo29()

Beha

vior

Payl

oad

• 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

Behavior PayloadLess Meaning

More Meaning

More Meaning

Less Meaning

Semantic Load

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.

Services and ActsPrincipal Reasoning Consequences

Context for the use of information is explicit in the invocation of behavior.

The contract between two parties is embodied in the Service Specification, the Interoperability Specification, and / or a technical, computable contract. In practice, this means that the contract is apparent at an interface, not in an information structure.

Informational elements that reflect contract semantics (specifically behavior) are removed from the information model

Remove information that reflects behavior

See #1 Information models will reflect the behavior to which they are bound. In all cases, models will not carry behavior-specific information. Update modes, for example are expressed by an operation.

Remove information that reflects the context of a service.

See #1 Patient information may be passed as context to a service call or may be passed as additional parameters to a service call. As an example, in addition to passing a Lab Order, the operation may also have a Patient CMET as a parameter.

Information Models will have fixed HL7 Mood codes.

See #1 Non-fixed Mood Codes reflect the addition of behavior semantics into the information model. As #1 stated, information models will not have behavior semantics embedded within them.

Exceptions are handled through business-level concepts

It is bad practice to break the encapsulation barrier except to provide the essential information to fulfill the terms of the contract.

Exceptions are categorized, as are Errors and Faults, through the Specification layers. This allows interactions to communicate several semantics: that a business process failed through no technical cause, and that technical causes were responsible for a business-level failure .

caCIS – Service Implementations

caCIS Service Implementation RIMBAA Architecture

caCIS Deployment Phase 1

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

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

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

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

Connections between RIMBAA and SAIF

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

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

Contact

• John Koisch– [email protected]