Product Brief - SOA4HL7
- 1 Product Brief - SOA4HL7
- 1.1 Product Name
- 1.1.1 Standard Category
- 1.1.2 Integration Paradigm
- 1.1.3 Type
- 1.1.4 Releases
- 1.1.5 Summary
- 1.1.6 Description
- 1.1.7 Business Case (Intended Use, Customers)
- 1.1.8 Benefits
- 1.1.9 Resources
- 1.1.10 Relationship to/ Dependencies on, other standards
- 1.1.11 Links to current projects in development
- 1.1 Product Name
HL7 Version 3 Methodology: Service Oriented Architecture; Service Definition, Release 1
- Implementation Guide
V3 SOA4HL7 R1; HL7 V3 SOA, R1 January 2007
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.
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.
- 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.
- Tutorial Slides at http://hssp.wikispaces.com/space/showimage/HL7%20LA%202007%20November%20Tutorial%20Slides.zip
- See more at http://www.hl7.org/implement/training.cfm
- See slides at http://hssp.wikispaces.com/space/showimage/EducationalSlides_HL7_Atlanta_WGM_20070823.zip
- See also http://hssp.wikispaces.com/Service+Overviews
Relationship to/ Dependencies on, other standards
- HSSP Service Specification Framework.
Links to current projects in development
- Project Insight ID # 129, Infrastructure: SOA4HL7 Methodology