1 / 16

SOA4HL7: Defining Services based on HL7 Messaging Artifacts

SOA4HL7: Defining Services based on HL7 Messaging Artifacts. HL7 Educational Summit, November 2007. Alan Honey , Kaiser Permanente Enterprise Architect (Based on material initially prepared by John Koisch, OCTL Consulting). Goals.

wendy-cash
Télécharger la présentation

SOA4HL7: Defining Services based on HL7 Messaging Artifacts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOA4HL7: Defining Services based on HL7 Messaging Artifacts HL7 Educational Summit, November 2007 Alan Honey, Kaiser Permanente Enterprise Architect (Based on material initially prepared by John Koisch, OCTL Consulting)

  2. Goals Show a (Phase 2) method for using messaging artifacts in HSSP Service Definition and Modeling (SOA4HL7) This is an interim methodology for defining more “SOA compatible” services based on existing messaging artifacts until a full set of standard services are defined Can also support migration activities This is not intended to supplant definition of Service Standards

  3. Problem Statement There are not yet many standard services defined Defining new ones takes time What do we do with more urgent development or implementation needs? • For software vendors: define services using custom methodology based on own database schema (most common current practice)? • For consumers or in-house developers: create service definitions from scratch or from own legacy systems ? Or apply some level of consistent methodology? • What about existing v2 or v3 messaging artifacts? Enter SOA4HL7

  4. Service DefinitionApproaches Build or Re-Use Decision Tree • Use existing service definition • Define a standard service - Use the HSSP Service Specification Process • Follow the SOA 4 HL7 Process

  5. SOA4HL7 Work Products and Deliverables Methodology (Balloted HL7 informative document) • Methodology for creating service definitions and implementations. This offers a more consistent way to define and implement “interim” Services based on HL7 V3 content. NOT a replacement for standard HSSP Services SOA Architecture Framework • Leverage existing IT standards to enable services to be consistently described and used in healthcare environments. Includes a mapping of V3 Infrastructure a the SOA framework. Again an interim until HSSP Reference Architecture is complete. Note - This artifact was not balloted. Focus here is on methodology

  6. 1. Functional Specification Define Requirements Define Process and Information Capabilities Id and Name Service Components Map Requirements to Components Produce Logical Specification 2. Solution Specification (PIM) Refine Interaction Solution Refine Component definitions Define Detailed Dynamic Model Specify Operations and Messages Define QoS considerations Produce PIM Specification 3. Technical Specification (PSM) Platform Selection (e.g. WSDL) Identify Services (/consumers, interfaces, operations, parameters) Produce Interface Specification Define Technical Conformance Levels SOA 4 HL7 - Overall Methodology

  7. SOA 4 HL7 – Deliverable X-Ref Deliverables and their relation to HL7 components

  8. SOA 4 HL7 – Service Description

  9. SOA 4 HL7 - Interface Identification

  10. SOA 4 HL7 – Operation Identification

  11. SOA 4 HL7 – Operation Identification In a messaging world, it is common practice to define large, multi-purpose messages and derive the appropriate instruction and meaning from them in “hidden” business logic. This obscures the behavior from the service client and often leads to non-deterministic states of objects. Wherever possible, explicit actions should be identified that take deterministic action. This does NOT imply that the “how” should be exposed, but it is important that the “what” is made very clear.

  12. Example – Eligibility Service

  13. SOA 4 HL7 – Message Content

  14. SOA 4 HL7 – Design Guidance Guidance is given on each of the following topics: • Modular Design • Tolerance of Independent Invention (Scope and flexibility) • Types of Functional Requirements • Adaptability • Granularity • Abstraction Level and composition • Cohesion / coupling / complexity • Completeness • Design for Reuse • Security • Process Management • Technical Governance

  15. A Word on Implementation Use (or otherwise) of the H7 V3 wrappers. • Transmission wrapper can be omitted (see SOA4HL7 Architecture document for initial suggested mappings) • Include Control Act as payload or omit depending on need / circumstances XML Schema • Some suggestions included in document (based on work in Finland SerAPI project) • Also see New ITS work in UK

  16. SOA 4 HL7 – Worked Example A worked example is included (Appointment Scheduling). This includes: • Storyboard definitions (taken from existing v3 material) • Service, Interface, Operation, Message Definitions • WSDL definitions (partial)

More Related