This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Product SOA4HL7

From HL7Wiki
Jump to navigation Jump to search

Product Brief - SOA4HL7

back to Main_Page
back to Product_List

Product Name

HL7 Version 3 Methodology: Service Oriented Architecture; Service Definition, Release 1

Standard Category

  • Implementation Guide

Integration Paradigm

  • Services

Type

Informative

Releases

V3 SOA4HL7 R1; HL7 V3 SOA, R1 January 2007

Summary

This document is a detailed but informal document, aimed at defining an approach for implementing healthcare services within a Service Oriented Architecture. This is intended to complement the Service Specification Framework (SSF) defined within the Healthcare Services Specification Project (HSSP), but provide an additional interim method of defining and implementing web services based on HL7 V3 artifacts.

Description

This document describes a methodology for defining services within the healthcare domain, in particular, for areas covered by Health Level 7 (HL7) domain content; an effort known as Service Oriented Architecture for Health Level 7 (SOA4HL7). The methodology described herein is accompanied by a set of deliverables relating to infrastructure and architecture that collectively form the overall approach. The document is particularly aimed at providing guidance that will help in the identification and enumeration of services based on existing HL7 messaging artifacts. The document aims to provide a practical approach, especially to existing HL7 committees interested in SOA. Following this methodology should lead to the production of appropriate (from a SOA perspective) service definitions, which may then be proposed as standards through the main HSSP process if this is appropriate.

Business Case (Intended Use, Customers)

The intended audience for this document includes any organization or group planning on defining automated services within the healthcare domain. This could be standards development organizations (SDO), software vendors, healthcare payers or providers etc. The term “services definers” will be used throughout this document to identify these groups and individuals. The two key targets are really HL7 domain committees that wish to define services, and also healthcare software vendors that are implementing services in their solutions.

Benefits

When to Use Services
  • From a standards perspective the answer is a great deal easier than from an individual project perspective. When should a standard service be defined? The simple answer is when sufficient organizations taking an SOA approach identify the requirement for the service. Certainly, interactive request reply scenarios make very good candidates, e.g. scheduling, eligibility checking, entity identification, demographics or other data look up and updates etc. It is however, worth considering the latter question, i.e. in what project situations should services be used rather than messaging, or vice versa.
  • One of the main points of SOA is to enable loose coupling which frees the Service Consumer from the details of the implementation of the Service itself. From a standards and interoperability perspective, this is an important aspect.

Resources

Work Groups

Services Oriented Architecture (SOA)

Education

Presentations

Relationship to/ Dependencies on, other standards

  • HSSP Service Specification Framework.

Links to current projects in development