Service Oriented Architectures in Healthcare IM /IT + SOA 101

1. Service Oriented Architectures in Healthcare IM /IT + SOA 101 May 2007 HL7 Service Oriented Architecture Special Interest Group (SOA SIG) OMG Healthcare Domain Task Force (HDTF) Prepared by John Koisch, VA john.koisch@va.gov

2. The 20 Second Interoperability Quiz Are you interoperable… • … if you and your business partners “speak” different languages • … if gender = “01” means “male” in your business and “female” for your business partner? • …if the primary context for information sharing is e-mail or fax? • … if electronic data is exchanged via CD-ROM, or DVD-ROM? • …if you use XML? • …if you use Web Services?

3. The 20 Second Agility Quiz How well can your organization’s IT adapt to… • … address the new business rules that resulted from a legislated policy? • … deployment changes resulting from adding a data center? • … integrating clinical information with a new business partner? • … integrating with “the new <place clinical specialty here> system” • … emerging public interest in personal health records?

4. “Enterprise Architecture 101” • The practice of aligning IT with business objectives • Identifying unplanned redundancy in work processes and systems • Rationalizing systems and planning investment wisely • Establishing target environment and a viable migration path • Addresses all facets of IT and the business: • Core business capabilities and business lines • Identification of business functions • Identification of IT needed to support the business

5. Reference Model for Open Distributed Processing Multiple Views of IM / IT • RM-ODP • Enterprise – Why? The business perspective … • Information content – What? Semantics, constraints, and syntax … • Systems (computational) view – What functionality in what components? • Process (engineering) view – What does the solution look like? System Distribution … • Technology (infrastructure) view – What technologies or products realize the vision? References: http://www.cs.helsinki.fi/u/summanen/opetus/2004/middleware/luennot/5-rmodp.pdf http://www.nature-soft.com/retail_system.html http://www.rmodp.net

6. So, what about web services? • Web services alone (e.g., SOAP/WSDL, etc) do not solve the problem: • What behaviors do we expect of an MPI? What does an MPI Interface look like? Where is it specified? • What behaviors are not expected or should remain unspecified? • What confidence do we have that two MPIs can interoperate in an SOA intra- or inter-organization? • What about information semantics? • How will business exceptions be managed across instances? • How does an MPI for a hospital interoperate with the index for cohort selection? • WSDL / SOAP are a technology from the RM-ODP viewpoint • These issues are not addressed via selection of SOAP/WSDL as a platform • These issues are not entirely addressed via Web Services as an ITS

7. In fact, “Services” are only part of the picture Web Services as technology and a system: • don’t provide for optimization to workflow or to QOS standards • don’t easily allow for complex and rich semantics • Web Services don’t explicitly allow for an applied model • Web Services usually don’t provide semantics, only syntax • Web Services don’t allow for self-description within an organization’s service portfolio • Web Services have no inherent taxonomy, and don’t have attributes that optimize interoperability • There are no satisfactory standards for Service Metamodels • for Description and Discovery • Necessary, but not sufficient • Open Group’s SOA Ontology work • Oasis Reference Model for Services • CBDI MetaModel for Business Services For SOA, you still need to account for Informational, Computational, and Engineering viewpoints

8. The differences between SOA and services • SOAs provide at least some of these missing links • Systems - Services based on horizontal (cross domain) organizational themes (“Delivery Service” as opposed to “Outpatient Note Service”) • Allow for business composition • Enterprise - Services optimized around business goals • Engineering - Services structured as “atomic”, “compositional”, “infrastructure”, and so on. Services support encapsulation • Informational - Allow for rich semantic interactions • HSSP SOA SIG seeks to provide guidance about these and other issues

9. SOA = Investment • Health IT is seen as an expense, not as an investment • SOA can help previous expenditures (“systems”) extend longevity • Systems become a business investment rather than cost • BUT …. SOA is an investment, not an expense. • It requires analysis and organizational will • Organizations that enable SOA now will be more agile, more interoperable, and less technology-bound going forward

10. Working Definitions • Services represent a constrained or transformed representation of the underlying domain model focused by business goals • The emphasis is on behavior • HSSP includes behaviors based on semantics • Conformance is asserted at the Interface • Focused on exchanging information, not necessarily data • “Credit authorization approved” v “He has $20 in his checking account” • GetMedicalRecords(_patientID) v GetBloodPressure(_patientID)

11. Working Definitions (cont’d) • A SOA is people, process, and technologies • A service is nothing but specification • Systems implement a service • A SOA Implementation is a set of components that leverage, extend, scale, and enable the service representations. • Efficiency and effectiveness defined by business needs • Focus defined by business goals

12. Working Definitions (more) • Interoperability between systems usually happens in an engineering-poor environment, meaning that an organization’s implicit assumptions and context must be made explicit • SOA Implementations are prime candidates • good SOAs are explicit in their services, interfaces, and semantics

13. Template Usage – An example of Services and Interoperability Paradigms HL7 Templates fall into one of three categories • Expressed Models • Represented directly “on the wire” • Names of the classes and associations are found in the instance • Implied Models • Where did the model come from? • RIM is the ultimate implied model • Applied Models (Templates) • Constraints applied after the message is delivered • What is a “valid” range for bp? • What are the top three medications by dosage? • Represent additional semantics, and possibly additional business semantics

14. Templates and Services • Being explicit about usage of Implied models v Expressed Models v Applied Models is not dealt with by most messaging systems or by a “generic web service” implementation of HL7 messages • Services provide a means to make the relationship and the sequencing explicit, in both complex and simple scenarios • Services are implicit about their data, but explicit about their behaviors • Services may be composed • Services may be choreographed

15. Templates and Messages (v3) • Messaging systems are explicit about their data, but implicit about their behaviors • Templates cannot add meaning to v3 Messages, only be used for validation

16. Information • SOAs and Services lend themselves to rich semantic use cases • Composable • Interface Definitions • With the notion of Semantic Profiles added to the usual Functional profiles, HSSP services are semantically enabled.

17. HSSP Meta-Model

18. Acknowledgements • Thanks to HSSP members who contributed to the HSSP SOA model and the HSSP Service meta-model • Dr. Wendell Ocasio, Northrup Grumman • Ken Rubin, EDS • Alan Honey, Kaiser Permanente • Paul Boyes, WRMC, DoD