Docstoc

SOA_and_IHE_Concepts_v8_04282009.xls - IHE

Document Sample
SOA_and_IHE_Concepts_v8_04282009.xls - IHE Powered By Docstoc
					Mapping of SOA and IHE concepts (Work in progress)
          SOA Concept                                    SOA Definition

Service Provider                Provider of a service

Service Consumer                Requester of a service
                                The service definition contains metadata which describes the
                                terms for information exchange with the service, desribing the
                                service's technical constraints and requirements as well as any
                                semantic information needed to consume the service. The
                                abstract portion describes the functionality of the service using
                                a series of technology-independent elements, including
Service Definition - abstract   interface, operations and operation semantics, and data
portion                         structures.




                                The service definition contains metadata which describes the
                                terms for information exchange with the service, desribing the
                                service's technical constraints and requirements as well as any
                                semantic information needed to consume the service. The
                                concrete portion of the service definition describes how to
Service Definition - concrete   access the service. It effectively acts as the intersection
portion                         between the abstract portion and the service implementation.

                                The core logic in support of the Service Defintion. A service’s
                                implementation is basically the code behind the service, often
Service Implementation          written in an application language like Java, .Net or C++.


Service                         Service Definition and Service Implementation taken together.




Operation                       A service function or method.
                                Data structures shared between a service consumer and
                                service provider. Also called a Message in SOA literature. The
                                payload is part of the Service Definition, abstract portion as well
Payload                         as the Service Defintion, concrete portion.
                               Ability of a service to be composed with another service to
                               create a new service. Composition is a core principle of SOA,
                               which permits business logic to be represented at different
                               levels of granularity, and promotes reuse and abstraction (also
Composition                    core principles of SOA)

                               In the context of WSDL, a binding is the association of protocol
Binding                        and message format information to a service operation

                               A late-binding, stringing together of services to implement a
                               workflow. Rules that govern behavioral charactistics of how a
                               group of services interact, usually in the context of a business
Orchestration                  process



                               Josh to supply. Orchestration is managed by a single
Choreography                   controller; choreography has multiple controllers.



                               A classification of services for the purpose of identifying reuse
                               of services. A SOA solution is often analyzed and depicted as
Taxonomy                       layers of services corresponding to these classifications.
Conformance (of the
concrete portion of the
Service Defintition to the
abstract portion)
                               Ability to service implementation to fulfill the requirements of a
Conformance (of a service      Service Defintition, both abstract and concrete parts. Only
implementation to a Service    applicable in the context of a specific standard (e.g. OMG), or
Defintition)                   implementation guidelines (e.g. WS-I).

Parking Lot
OSI model?
ESB
Message (SOA)
Benefits of SOA.

The idea here is to list the
desired benefits and work
backwords to relevant
concepts that result in the
benefits - then find the
corresponding IHE concepts
Agility
Flexibility
…
Optimized Workflow
Reduced Cost
progress)
                         Corresponding IHE Concept                                         Example
       Service Provider is similar to IHE Actors that are recipients of   Patient Demographics Supplier is similar to
       transactions.                                                      the Service Provider
       Service Provider is similar to IHE Actors that are initiators of   Patient Demographics Consumer is similar
       transactions.                                                      the Service Consumer




       Generally speaking, the content in TF Vol I most closely matches Common elements PIX/PDQ HL7 V2 and
       the abstract portion.                                            HL7 V3




                                                                          Vol II sections of HL7 V2 PIX, HL7 V2 PDQ,
       Generally speaking, the content in TF Vol II most closely          HL7 V3 PIX/PDQ as described in required
       matches the concrete portion.                                      transactions



       Maps to vendor products which implement IHE profiles.
                                                                          PIX and PDQ plus their implementations
       IHE Technical Framework (Vols I and II) combined with vendor       map to HSSP EIS plus implementation of
       products                                                           EIS
                                                                          Patient Identity Management ITI-30
                                                                          messages may map to several EIS
                                                                          operations. By sending different trigger
       Loosely corresponds to transaction or message. Sometimes           events as allowed by ITI-30, corresponding
       service operations correspond directly to IHE transactions or      EIS add, update, link and unlink operations
       message, but not always.                                           may be supported.


       Relates to an IHE profile section called Message Semantics
       which may or may not reference a Content Profile.
The way IHE uses UML in Vol I and Vol II to show interactions or
implement a workflow is close to the idea of composition. IHE
does not have a concept as complete as composition, but some
of the concepts come through in the requirements IHE uses
around Grouping. It is also related to Dependency, which is a
term used in IHE to point to Grouping. For example, a
Document Consumer Actor may also have to play a security role.
The association between the use case and the transactions is
found in Volume I; the expected actions are found in Vol II
Transactions
                                                                      Use of PDQ by a Document Consumer; use
IHE does not have a concept that corresponds well to                  of Patient Identity Feed i(PIX) n conjunction
orchestration. However, sometimes the stringing together of           with Patient Demographics Quiery (PDQ) -
profiles is either implied or suggested in a white paper, appendix,   Examples: Vol I Apendix E; Vol II
or informal notes.                                                    Appendix.




See Orchestration

The first level of taxonomy is in the breakup of profiles into IHE
domains. ITI and PCC domains were explicitly created to foster
reuse of profiles. Within domains, IHE has begun developing           Example domains include ITI, PCC,
lower level taxonomy.                                                 Radiology, and so forth.


                                                                      Integration Statement is a self-declared
Testability of vendor implementations at Connectathon.                statement of conformance to profile actors.


                                                                      Integration Statement is a self-declared
Testability of vendor implementations at Connectathon.                statement of conformance to profile actors.
IHE Concept                   Formal IHE Definition*                           Working Def

                      1) A functional component of a              Essential component of an IHE
                      communicating healthcare IT system          Integration Profile that is an
                      and device.                                 abstraction of the endpoint
                      2) Actors are information systems or        responsible for the initiation or
                      components of information systems           response to a Transaction. Systems
                      that produce, manage, or act on             implement one or more Actors
                      information associated with                 (Grouped) as declared in the systems
Actor                 operational activities in the enterprise.   Integration Statement.

                      An IHE Integration Profile specifies a
                      coordinated set of interactions
                      exchanged between the functional
                      components of communicating
                      healthcare IT systems and devices.
                      These functional components are             An IHE Integration Profile is a
                      called IHE actors. An IHE Integration       reusable specification that defines the
                      Profile specifies their interactions in     Interoperability solution to a healthcare
                      terms of a set of coordinated,              workflow that requires two or more
Integration Profile   standards-based transactions.               systems to work together.


                      1) Transactions are interactions
                      between actors that communicate the
                      required information through                Essential component of an IHE
                      standards-based messages.                   Integration Profile that is the pre-
                      2) Transactions are interactions            defined interaction between Actors.
                      between actors that transfer the            IHE Transaction defines the network
                      required information through                semantics, trigger events, and
Transaction           standards-based messages.                   expected actions


                      A testing event to which developpers
                      have registered their implementations
                      for supervised interoperability testing
                      with other implementations. Each
                      participating system is tested for each
                      registered combination of IHE Actor
Connectathon          and IHE Integration or Content Profile.
                      A collection of Profile Specifications
                      related to an IHE Domain and its
                      specific clinical or technological focus.
                      Profiles within a Technical Framework
                      and across Technical Frameworks
Technical Framework   may be combined.

                                                                  Encoding rules for the message as
Message Semantics                                                 communicated.


                                                                  Named variance in the Integration
Option                                                            Profile.
                        A textual and graphical depiction of
                        the actors and operations that
                        addresses information exchange in         The defined healthcare workflow that
                        the context of a set of specific tasks    outlines the interoperability problem
                        performed by different systems or         that is the focus of an Integration
Use Case                devices.                                  Profile
                        IHE Integration Statements are
                        documents prepared and published by
                        vendors to describe the conformance
                        of their products with the IHE
                        Technical Framework. They identify
                        the specific IHE capabilities a given
                        product supports in terms of IHE
Integration Statement   actors and integration profiles
                        A graphical illustration of the flow of
                        processes and interactions among the
                        actors involved in a particular
Process Flow Diagram    example.

                        An event such as the reception of a
                        message or completion of a process,
Trigger Events          which causes another action to occur
                        A diagram that depicts data flow and
Interaction Diagram     sequencing of events
                        Actions which should occur as the
Expected Actions        result of a trigger event

                        An IHE Content Profile specifies a
                        coordinated set of standards-based
                        information content exchanged
                        between the functional components of
                        communicating healthcare IT systems
                        and devices. An IHE Content Profile
                        specifies a specific element of content
                        (e.g. a document) that may be
                        conveyed through the transactions of
                        one or more associated Integration
Content Profile         Profile(s).


                        Describes the payload of a
                        transaction. A content module is
                        specified so as to be independent of
Content Module          the transaction in which it appears.
                                                                  Set of related and interdependant
                                                                  profiles driven from requirements that
                                                                  an actor supporting one profile be
                                                                  grouped with one or more actors
Grouping                                                          supporting other integration profiles

* Sources
IHE ITI TF 5.0
IHE PCC TF 4.0
ISO 28380
IHE Wiki glossary
Corresponding SOA Concept             Example




Related to SOA concept of role,
e.g. service provider, service        Patient Demographics Supplier
consumer                              is similar to the Service Provider




When defining the same scope
this is related to a SOA service
implementation. When the SOA
service is defining a higher level
colaboration then a IHE Profile is
closer to a an implmenentation of
a capability.
Most similar to SOA concept of a
concrete Service-Interface where
the SOA service is defining a
network service. May be similar
to a SOA Capability where
capability is used to identify
network service intereface in a
larger service definition. May also
be similar to the SOA Operation
concept.




none. This isn't a necessary
concept in SOA as SOA is a
open method and not an
organization publishing their
specifications.
Related to the SOA detail found
in an Implmenetation
Specification

Related to the SOA concept of a
Profile when used to identify
different grouping of capabilities.
Related to SOA use-case




???



same



same

same

same




Most similar to SOA concept of
Payload, where the payload is
not defined in the Service
because the Service is agnostic
to the Payload content.

Most similar to SOA concept of
Payload, where the payload is
not defined in the Service
because the Service is agnostic
to the Payload content.


Related to SOA concept of
service composition when applied
to automate a business process.
Overall similarity and difference of SOA and IHE concepts
                                    SOA Concept

Defines service in terms of functional and non-functional requirements

Definition does not include implmentation details



SOA defines Composition, Orchistration and Cooreography
nd IHE concepts
                                         IHE Concept
      Defines functional requirements only if the requirement is critical to ensure
      interoperability. Never defineds non-functional requirements.
      Definition is focused on exact specification of interoperability implmentation
      details

      Defines an Interoperability solution through standard selection and constraints
      IHE does not specify how to use Profiles to solve larger problems. IHE profiles
      are reusable through Composition, Orchistration and Cooreography.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:12/4/2011
language:English
pages:11