Docstoc

ebXML Proof Of Concept

Document Sample
ebXML Proof Of Concept Powered By Docstoc
					1    ebXML Proof-Of-Concept
2    Technical Planning Document for End-to-
3    End Demonstration in Vienna version
4    0.6300.57
5    Working Draft, April 256, 2001
 6   This version:
 7         ebXML Technical PPlanning Document for End-to-End Demonstration
 8         in Vienna - Version 0.62057
 9   Previous version:
10         ebXML Tecchnical Planning Document for End-to-End eBusiness
11         Demonstration in Vienna - Version 0.566
12




     Authors
     o   Sig Handelman             [swhandel@us.ibm.com]
     o   Sid Askary                [saskary@iona.com]
     o   Mark Hale                 [mark.hale@interwoven.com]




     Contributors
     o   William Cox               [william.cox@bea.com]
     o   Polly Jan                 [pjan@visa.com]
     o   Liora Alschuler           [liora@the-wordword-electric.com]
     o   Matthew Gertner           [matthew.gertner@schemantix.com]
     o   Nita Sharma               [nsharma@netfish.com]




     40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc 10/24/12                 1 of 26
Table of Contents
INTRODUCTION ......................................................................................................... 3
    1.1     ABSTRACT ........................................................................................................... 3
    1.2     SUPPORTING ORGANIZATIONS ............................................................................. 3
    1.3     REFERENCED DOCUMENTS .................................................................................. 4
       1.3.1    Specifications: .......................................................................................... 4
       1.3.2    Schemas: .................................................................................................. 4
       1.3.3    Payloads: ................................................................................................. 4
    1.4     MEETING LOGISTICS ............................................................................................ 5
    1.5     SUBMITTED PROPOSALS ....................................................................................... 5
    1.6     ORGANIZATIONS AND ROLES ............................................................................... 5
2      SYSTEM OVERVIEW ......................................................................................... 6
    2.1     ARCHITECTURE .................................................................................................... 6
    2.2     FUNCTIONAL REQUIREMENTS .............................................................................. 7
       2.2.1    Core Components ..................................................................................... 8
       2.2.2    Business Process ...................................................................................... 8
       2.2.3    Trading Partner ....................................................................................... 8
       2.2.4    Registry/Repository .................................................................................. 8
       2.2.5    Messaging ................................................................................................ 9
       2.2.6    Security .................................................................................................... 9
3      SCENARIOS.......................................................................................................... 9
    3.1     GENERAL DEMONSTRATION FLOW ...................................................................... 9
    3.2     EBUSINESS: TRACK 1 ......................................................................................... 10
       3.2.0        Introduction ........................................................................................... 10
       3.2.1 ...................................................................................................................... 10      Formatted
       3.2.2        Choreography ........................................................................................ 13
       3.2.3        Step 1: Discovery ................................................................................... 15
       3.2.4        Step 2: Catalogue Update....................................................................... 15
       3.2.5        Step 3: Place Order ................................................................................ 17
       3.2.6        Combined Sequence Diagram ................................................................ 18
    3.3     HEALTHCARE: TRACK 2 .................................................................................... 19
       3.3.1        Introduction ........................................................................................... 19
4      APPENDIX A: ..................................................................................................... 23
    3.1        TABLE OF FUNCTIONS ........................................................................................ 23
    4.1        TABLE OF DOCUMENT TYPES............................................................................. 23                      Formatted
                                                                                                                                            Formatted
5      APPENDIX B: ..................................................................................................... 25
    5.1        AIAG................................................................................................................. 25
    5.2        HL7 ................................................................................................................... 25   Formatted
    5.3        OAGI................................................................................................................. 25     Formatted
    5.4        ROSETTANET...................................................................................................... 25


40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                                                                 2 of 26
  5.5      SWIFT............................................................................................................... 26
  5.6      X12.................................................................................................................... 26



Introduction

1.1 Abstract
            The Proof-of-Concept (POC) working group met during the Vancouver
            ebXML joint meeting held February 12-16, 2001 to begin planning a
            fully choreographed demonstration for the Vienna ebXML joint
            meeting. In preparation, proposals were solicited with a January
            26, 2001 deadline date for functional characteristics of the
            various working group specifications to be reviewed. These
            proposals were originally targeted for a demonstration to be held
            in conjunction with an ebXML joint meeting to be held in early
            April 2001. This meeting has been cancelled. The POC WG decided
            to move forward with the proposal contents for a Vienna
            choreography. Some of the functional characteristics are based
            on the speculative state of the specifications in the upcoming
            months based on the POC WG interaction with the other ebXML
            working groups. The choreography will be updated accordingly as
            the specifications reach quality review.

            At meetings of the POC Work Group, held March 8 and March 15, it
            was decided to add a track for HL7 (Health Level 7). It was also
            decided to augment the Proof of Concept with a demonstration of
            Complementaty Functions between ebXML Registry and UDDI. We also
            discussed on March 15 the possibility of bringing in a
            marketplace, Covisint, to show functionality of ebXML processes
            with an existing marketplace.

    This Document is a controlling agent for the Proof-Of-Concept (POC)
    Working Group’s interoperability demonstration during the ebXML
    conference in Vienna May 7 – 11, 2001.                                                                                              Formatted

    It includes references to the business scenarios, documents and other
    material. To that end, material was provided by other ebXML Working
    Groups whose members also participate in the POC.

    While the goal of the POC WG has been to demonstrate interoperability
    and to provide feedback to the other working groups, this particular
    document and the resulting demonstration mark the end of phase I in the
    ebXML delivery of specifications. As such, the specifications used in
    this document are the versions available as of April 16th, 2001.                                                                    Formatted



1.2 Supporting Organizations
     VISA International Corporation                                                                                                     Formatted: Bullets and Numbering

    HL7


40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                                                             3 of 26
     Covisint/CommerceOne
    This Demonstration will highlight the ability of the ebXML set of
    standards to be used in many industries for many purposes. As such,
    we will showcase documents and business processes from the following
    organizations: AIAG, HL7, OAG, Rosettanet, SWIFT, X12 (APENDIX B).
    These are then demonstrated in the context of two general vertical
    scenarios: eBusiness and Healthcare.


1.3 Referenced Documents

1.3.1          Specifications:
        1.[ebXML-TRP] Messaging Service Specification v0.98b
        2.[ebXML-R&R] Registry Services v0.90
        3.[ebXML-R&R] Registry Information Model v0.90
        4.[ebXML-BP] Business Process Specification Schema v0.99
        5.[ebXML-CPP/A] Collaboration-Protocol Profile/Agreement v0.941     Formatted: Bullets and Numbering
        6.[ebXML-CC] Core Components. ???
                                                                            Formatted: Bullets and Numbering
        5.7.                                  [ebXML-A] Architecture
          Version 1.0


1.3.2          Schemas:

       1. XMLSignature Core –
          http://ebxml.org/project_teams/transport/xmldsig-core-
          schema.xsd
       2. Xlink - http://ebxml.org/project_teams/transport/xlink.xsd
       3. xml:lang -
          http://ebxml.org/project_teams/transport/xml_lang.xsd
       4. SOAP1.1 -
          http://ebxml.org/project_teams/transport/envelope.xsd

       Note that for the demo The location of the urls for the
       references will be modified to reflect a local directory setting.

                                                                            Formatted: Bullets and Numbering

1.71.3.3       Payloads:
       The POC WG would like to take a sidebar during the demonstration
       will demonstrate mto show multiple payload support. They are:. A
       single payload will need to be selected for the baseline
       demonstration. The selection will be from RosettaNet and xCBL
       payloads since they were submitted by the proposal deadline.
       Payload choice should be made no later than six weeks prior to the
       Vienna demonstration.

                   (NEED DOCUMENT SAMPLES)

          1.   RosettaNet for Catalog Update
          2.   OAG for Catalog Download
          3.   OAG for Place Order
          4.   X12 for Purchase Order and Purchase Order Ack



40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012             4 of 26
          5. AIAG XML (from Tokyo POC) for ASN
          6. Core Components for Payment Authorization, Invoice and
             Invoice Response
          7. A “financial XML” for Financial Settlement from Payment
             Authority to Bank
          1.8.      Swift between Banks for Financial Settlements
          2.9.      An XML Bill from the Bank to the Buyer


1.4 Meeting Logistics

   The Vienna ebXML joint meeting will be held May 7-11. At the
   writing of this draft, both a POC plenary demonstration and an open
   POC demonstration to the public are being discussed.   The open
   demonstration will be tentatively held on May 9.


1.5 Submitted Proposals
    There were eight proposals submitted for the choreography. The
    proposals are located on the POC WG private web site for download.    The
    proposals are (in no particular order):

        1. ebXML Security and TPA Proof Of Concept, Version 1
        2. TRP Multi-Hop with Reliable Messaging Proof Of Concept, Draft
           Version 0.1
        3. TR&P: Reliable Messaging, Scalability and Robustness, January
           25, 2001
        4. ebXML - Complex Content Exchange, Version 0.1
        5. Registry: Flexible discovery through ad hoc queries, Registry
           Security, January 25, 2001
        6. ebXML London POC Proof-Of-Concept - Core Components, Version
           0.1
        7. ebXML Business Process Editor Toolset Proof Of Concept,
           Version 1.1
        8. Business Collaboration Protocol Specification & Implementation
           Proof Of Concept


1.6 Organizations and Roles
    A table will be created in this specification outlining the
    identification of participants in the choreographed sequences
    outlined in this document was well as the support roles for the poc.
    The roles of the companies include buyer, supplier, registry, market
    place, credit authorization and financial institution as parts of
    first scenario, and the clinical roles of the hl7 scenario. As in
    previous poc’s individual companies or companies in partnerships
    will act in these roles at the demonstration. The support roles
    include certificate authority, registry providers, providers of run
    time codes for specifications.



40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012              5 of 26
2 System Overview

2.1 Architecture

    The choreography for the eBusiness demonstration is designed to step
    through the various aspects of the ebXML technical architecture.
    The three phases that are important for implementation are Design,
    configuration and runtime.

    During design time, the ebXML business processes, core components,
    and dictionaries are installed in the registry. This also includes
    maintenance activities.

    Arrangements to conduct business are done during configuration time.
    This includes binding business processes and business documents to
    business collaborations by creating and registering collaborative
    protocol profiles. From here, collaborative protocol agreements are
    formed in which business can be conducted. Finally, these
    agreements provide the basis for configuring the runtime systems.

    Real time business activities are conducted during runtime, as ebXML
    messaging is used to communicate. Systems configured under the
    collaborative protocol agreements exchange business documents
    according to pre-defined business processes.




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012          6 of 26
                            Business       Context       Core
                            Process                   Components
         Design


                                          Registry
                                         Repository
Configuration
                           Business        Trading    Business
                            Service        Partner     Service

       Runtime
                            TR&P                       TR&P



                            Business       Context       Core
                            Process                   Components
         Design


                                          Registry
                                         Repository
Configuration
                           Business        Trading    Business
                            Service        Partner     Service

       Runtime
                            TR&P                       TR&P




                 Figure 1.      ebXML Technical Architecture

                                                                             Formatted
    It is important to remember that these phases are rough guidelines.
    In implementations, interactions among all of the ebXML architecture
    components will involve ebXML messaging and agreements.
       The POC WG met on Tuesday, February 13 to define functional
    properties of the other working group specifications that should be
    incorporated into the end-to-end demonstration of eBusiness. The work
    group status in this list has been updated on March 26.


2.2 Functional Requirements
    The POC WG met on Tuesday, February 13 to define functional properties
    of the other working group specifications that should be incorporated
    into the end-to-end demonstration of eBusiness. The work group status
    in this list has been updated on March 26. The properties include:




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                 7 of 26
2.2.1          Core Components
       Storage of core components in RegRep
       GUID service as defined in the technical architecture
       Inclusion of core components dictionary
       Core Components will be used to create Sample Business Documents
        for the Payment Authority of the Market Place demo. The creation
        will make use of the following steps.
            A. A design time interface for assembly and context rules per
               the ebXML Specification. The documents will be created
               ahead of the demo; the rules will be documented in this
               specification.
            B. A run-time interface to show the documents and the
               construction rules can be presented as part of the Proof of
               Concept.


2.2.2          Business Process
       Storage of business process in Reg/Rep
       Dynamic configuration of run-time infrastructure using CPA
       Show link of business process in the CPA
       Business Process Editor and other tools
       Choreography of Business Process expressed in ebXML Schema
           A. XML schema possibility to run Workflow
           B. XML schema loaded into the Registry Classification scheme
       CPA rendering through the Business Process Editor
       Monitoring of the Business Processes
        It is our intent in this Proof of Concept to automate as much as
        possible the business scenario of the Market Place through the
        use of Business Process tools. At the same time, the tools may be
        used for the Health Level 7 scenario.


2.2.3          Trading Partner
           Dynamic configuration of run-time infrastructure using CPA
           Business processes for negotiation of CPA
           ebXML Trading Partner 0.94+


2.2.4          Registry/Repository
     Query (Ad Hoc)
     CPP Discovery process
     Business document discovery
     Core components discovery



40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012              8 of 26
       Dynamic configuration of run-time infrastructure using CPA
       Coordination with UDDI. The coordination with UDDI will be
         included in this specification in a later version.


2.2.5          Messaging
         Multi-hop
         Security
         Support for multiple transports (HTTP, SMTP, per SOAP enveloping)
         Multi-part payloads
         ebXML Messaging Spec 98b+


2.2.6          Security
         XML DSIG for Authentication Purposes
         Include security at the messaging level
         Secure access to registry contents
         Security of payloads in messages optional between Trading
          Partners
         We are planning for a Certificate Authority to be available
          during the Proof of Concept for Security Purposes
      The functions used in the Proof of Concept are summarized in the
      Appendix of this document.



3 ebXML technical ArchitectuScenarios

3.1 General Demonstration Flow
      There will be a brief introduction followed by two business tracks.
      All the tracks utilize the same ebXML infrastructure and
      specifications, but the business scenarios and the payloads will
      vary. The demo will also try to highlight certain unique aspects,
      such as security and reliable messaging, in individual tracks.
1.1                                                                            Formatted: Bullets and Numbering
               1. Business Process - The Business Processes are comprised of
                  request and response transactions between two parties.
                  These transactions are asynchronous. More complex
                  processes involve third parties or multiple request and
                  responses. A response indicates the request has been
                  processed and a business decision has been made. The
                  business-level transactions are typically combined with
                  asynchronous message-level acknowledgements for receipt of
                  a completed data set.




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012               9 of 26
               2. Core Components (Business Documents) - A business message
                  is sent during each transaction of the business process.
                  The message is comprised of a header and business document
                  (e.g. payload). All headers and payloads need to be
                  explicitly called out for the demonstration.

               3. Collaborative Partner Agreement - The data for the business
                  process and business documents are explicitly called out in
                  the CPA. This includes such things as: end points for the
                  transactions, protocol, business documents associated with
                  the transaction, etc. The CPA can be used to configure
                  interoperable implementations at run-time.



               4. Transactions - There are a number of variables in the
                  implementation environment that do not show up in the
                  schematic that do need to be configured as well. These
                  include:

                       A.      Assignment of domain names and IP addresses for   Formatted: Bullets and Numbering
                            closed demonstrations.
                       B.      Assignment of DUNS+4 numbers for demonstrations
                            with RosettaNet payloads.
                       C.      Screenshots for underlying software. Most
                            ebXML components are services. For a
                            demonstrations, simple GUI interfaces need to be
                            created to illustrate the functional aspects.


3.2 eBusiness: Track 1

3.2.1          Introduction

3.2.2
                                                                                 Formatted
3.2.33.2.1            Market Place
               A corporate buyer wants to purchase corporate
               supplies using a Market Place and a Payment System.
               A corporate supplier has available wares for Market
               Place users and is willing to accept payment
               through the Payment System.

        The eBusiness scenario looks as shown in Figures 2. These are
        pictures that have been taken from the Business Process Work
        Group’s documents provided to the Proof of Commercencept WG. Two
        changes will be worked out between the groups. We will have a set
        of processes using a Catalogue on the eMarketPlace server. The use
        of Product lists and price lists in Catalogues is outlined later in
        this document. The Proof of Concept will also have additional



40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                10 of 26
        messages between the e-Marketplace and the Payment Server. In
        addition the business messages between the e-Market Place and the
        Payment Server have been enhanced to include Credit Request,
        Invoice and Invoice Response.




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012            11 of 26
                        Net Market : Net                            Payment Authority :
      Seller : Seller        Market
                                           Buyer : Buyer             Payment Authority Registry : RegistryBuyer Bank : BuyerSeller Bank : Seller
                                                                                                                 Bank               Bank
                                                       Insert my CP, Request Seller's CPP

                  Send CPA                                          Seller's CPP




                                                        CPP/CPA
                                                        formation BEA
               Catalog Upload                           and CONTIVO
                                Catalog Download


                                   Place Order
               Purchase Order
                   PO Ack
                    ASN               ASN


                                            Payment Authorization
                                                                                          Registry:
                                                                                          STERLING
                                                                                          COMMERCE

                                            Invoice
                                    Invoice Response
                                                                                                          BuyerBank:
                                                                                   Payment                BOWSTREET
                                                      Catalog Download                                    Seller Bank:
                             Catalog                                               Authorization and
                                                      and Place Order:                                    XML GLOBAL
         Seller:             Download, Place                                       Invoice:
                                                      SAVVION/NTT
         Catalog             Order, Purchase                                       IBM/VISA
                                                      COM/NTT DATA
         Upload:             Order, Purchase          ASN: TIE
         SAMSUNG             Order Ack,
         Purchase            COMMERCE
         Order, PO           ONE,
         ACK                 Payment                                                            Financial Settlement
         NETFISH             Authorization and                                                                     Financial Settlement
         ASN: TIBCO          ASN, GE
         Invoice                                                                                                    Financial Settlement
                                                                                   Bill
         Processing:
         NTT
         COMM/NTT
         DATA




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                                                                     12 of 26
                          Figure 2.       eBusiness Track

              by Nita Sharma. They will be normalized into one case over the
              next week.


3.2.43.2.2            Choreography
    The choreography is broken into the three segments that comprise the
    ebXML architecture as described earlier: design, configuration and
    runtime.

    The choreography of this part of the business process will be automated
    through the use of the Business Editor.



    Step                                                    Functionality
    Design
        1.     Edit Business Process for secure
               payment
        2.     Register secure payment Business             BP support in Reg/Rep
               Process in Registry/Repository
        3.     Demonstrate Core Components dictionary
        4.     Select secure payment Core Components
               from dictionary
        5.     Form Business Document from Core
               Components
        6.     Register Business Document in                BD support in Reg/Rep
               Registry/Repository
             A. Focus on Registry/Repository security       Security
    Configuration
        1.     Show a secure seller CPP template
        2.     Show ability to edit CPP template
        3.     Show Business Document discovery in          Drilldown
               Registry/Repository
               (Uses drilldown)
        4.     Show Business Process discovery in           Drilldown
               Registry/Repository
               (Uses drilldown)
        5.     Show interface to form CPP with BD and       CPP has all necessary
               BP                                           components
        6.     Register CPP in Registry/Repository          CPP support in Reg/Rep
        7.     Registry interaction (merge, delete,
               etc.)




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                     13 of 26
        8.      Secure buyer discovers a secure seller    Ad Hoc Support
                in the Registry/Repository
                (Uses Ad Hoc query)
        9.      Secure buyer retrieves secure seller
                CPP from Registry/Repository
        10.     CPA formation for secure payment
        11.     Approval is gained by secure buyer
                sending CPA to seller and
                acknowledgement returned
        12.     CPA is used to configure secure payment
                runtime environment
    Step                                                  Functionality
    Runtime - Marketplace
        0.      Buyer discovery of seller in
                marketplace. (Already done in
                configuration.)
    Runtime - Exchange
        1.      Secure seller creates ‘Product
                Catalogue’
              A. Multipart catalogue                      Test payload support in
                                                          messaging
              B.Message sniffer                           Shows messaging properties
        2.      Secure buyer contacts exchange for
                ‘Product Catalogue’
        3.      ‘Product Catalogue’ exchange is
                coordinated by Exchange
              A. Show seller interacting with exchange    Complex routing
                 through a hub
              B. Show exchange interacting with buyer     Reliable messaging
                 using reliable messaging
              C. Show multiple payload types for          Payload/Business
                 exchange content                         Document Support
              D. Show multiple transport capability for   Messaging is transport
                 buyer and seller interaction with        agnostic
                 exchange
    Runtime – Payment Authority
        4.      Secure buyer submits ‘Arrange Payment’
                to Payment Authority
              A.Focus on how secure payload and           Security
                messaging
        5.      Secure seller receives ‘Authorize
                Payment’ from Payment Authority
        6.      Secure seller arranges ‘Shipment’ to
                the secure buyer


40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                   14 of 26
        7.    Payment Authority sends an ‘Invoice’ to
              the secure buyer
    Runtime – Financial Institution
        8.
    Runtime – Reporting Institution
        9.



3.2.53.2.3             Step 1: Discovery


       Marketplace: Conversation

                The following pictures will be updated with the addition of
                material from the Business Process Team.


                                    Buyer                   RegRep                   Seller
                                                                                         CPP Registration

                   Seller CPP Query



                 Seller CPP Retrieval




                      CPA Approval




                       Documents: (NEED SAMPLE DOCUMENTS)
                                       ebXML CPP and CPA for Discovery


3.2.63.2.4             Step 2: Catalogue Update


       Marketplace: Conversation (Normal Messaging)




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                        15 of 26
                                   Buyer               Exchange                    Seller
                 Send Product List



                                                                                            Acknowledgement



                 Send Price List



                                                                                            Acknowledgement




                                                                     Business Transaction
                                                                     Messaging Level Ack

                          Documents: (NEED SAMPLE DOCUMENTS)
                              RosettaNet for Catalog Update

                                 OAG for Catalog Download


    MarketPlace: Conversation (Reliable Messaging)

                                Buyer      Hub       Exchange                   Seller
              Send Product List                              MSH             MSH


                                                                                      Acknowledgement



              Send Price List



                                                                                          Acknowledgement




                                                                   Business Transaction
                                                                   Messaging Level Ack

                          Documents: (NEED SAMPLE DOCUMENTS)
                              RosettaNet for Catalog Update



40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                      16 of 26
                             OAG for Catalog Download


3.2.5          Step 3: Place Order
                  This table will require closure by April 10.




      Payment Authority: Conversation
           The Business Process using the Exchange simplifies the
           operation of the Payment Authority, since the Exchange has
           details of the Secure Buyer. In this model (Fig. 3), the
           Secure Buyer selects the goods to be bought from the Exchange,
           the Exchange requests a Credit Request for the goods, and the
           Payment Authority does a Credit Authorization to the Secure
           Seller, who now sends a Shipment Notice to the Secure Buyer.
           At month’s end the Payment Authority sends an Invoice to the
           Secure Buyer.




            : SecureBuyer         : SecureSeller       Exchange :                            :
                               BuyingMessage            Exchange                      PaymentAuthority


                                                                      CreditRequest




                                                         CreditAuthorization


                      ShipmentNotice




                                                   Invoice




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                              17 of 26
                        Documents: (NEED SAMPLE DOCUMENTS)
                                   X12 for:
                                       1. Purchase Order
                                       2. Purchase Order Ack
                                   ebXML Core Components for:
                                       1. Credit Request.
                                       2. Credit Authorization (“Secure Electronic
                                          Transactions (SEC) Version 1.0”).
                                       3. Shipment Notice.
                                       4. Invoice.
                                   AIAG XML (from Tokyo POC) for ASN


        Financial Institution: Conversation
                           NEED GRAPH



                       Documents: (NEED SAMPLE DOCUMENTS)
                             A “financial XML” for Financial Settlement
                               from Payment Authority to Bank
                             Swift between Banks for Financial
                               Settlements
                                    An XML Bill from the Bank to the Buyer


3.2.73.2.6            Combined Sequence Diagram


    The Sequence Diagram for all the components worked out on the Face-to-
    Face meeting on April 17, is presented in the following picture.




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                      18 of 26
     Seller : Seller     Net Market : Net                            Payment Authority :                             Seller Bank :
                              Market                                  Payment Authority          Buyer Bank :         Seller Bank
                                            Buyer : Buyer                                         Buyer Bank
                Catalog Upload

                                  Catalog Download


                                    Place Order
                Purchase Order


             Purchase Order Ack              Payment Authorization
                                       ASN

                                            Invoice
                                    Invoice Response




                                                                                           Financial Settlement
                                                                                                        Financial Settlement
                                                                                                         Financial Settlement
                                                                             Bill




3.3 HealthCare: Track 2

3.3.1                  Introduction

       The Healthcare track in the POC will demonstrate the exchange of
       information between a physician office, a hospital, a laboratory and
       a third-party clinical data repository or portal.

    In this scenario, A patient comes to the physician (primary care
    provider or PCP) for an examination. A record of the exam is created
    (an encounter note) and the physician decides to admit the patient to a
    hospital for further procedures and diagnosis. The physician office
    sends the hospital an admit message (registration) and, optionally,
    sends the encounter note as well.

    At the hospital, the patient has a second examination. As a result,
    a laboratory test is ordered and a second encounter note is created.
    The lab order is sent to a laboratory. The laboratory responds with
    a results message. The lab results are sent to the hospital and to


40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                                                           19 of 26
    the PCP. The clinical database/portal can receive copies of all
    information artifacts such that at the end of the sequence, it
    contains:
                       PCP encounter note
                       Registration message
                       Hospital encounter note
                       Lab order
                       Lab result

    The transport and routing will be defined by ebXML while Security
    will meet ebXML specifications. HL7 vendors will partner with ebXML
    vendors to accomplish secure, remote transactions and Collaboration
    Partner Agreements will be created describing the role and
    interactions of all parties.

    In summary the scenario for the Health Care Demo as proposed looks
    as is found in Figure 5.

                       1st Phase,
                       examination by
                       PCP                                    2nd Phase, PCP
                                                              Registers
                                                              Patient for
                                                                                                            Contains:
                                                              Hospital, sends
                                                                                       Clinical             * PCP encounter note
                                                              encounter note
                                                                                 Database-Repository        * registration
                                                                                                            * hospital encounter note
                          Examination                                                                       * lab order
          Patient                             PCP                                                           * lab results




                    Procedure              Registration

                                                                                Send Results


                                                                                               5th Phase, Lab
                                                                                               sends Results to
                                                                                               Clinical Database,
     3rd Phase,
                                                                                               PCP and Hospital
     Hospital
     peforms                                                     Laboratory
                                Hospital
     Procedure

                                             Order Lab Test

                                                                     4th Phase, Hospital
                                                                     Orders Lab Test




                                    Figure 5. Health Scenario




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                                                 20 of 26
        : Patient           : PCP            Hospital : Hospital                      : Laboratory      : Clinical Portal
                                                                   Hub : Hospital
                Examination

                                       Register
                                                                                                     Clinical
                                                                                                     Reports




                                                              Forward Report

                           Procedure


                                                                            Forward Report



                                                                                             Forward Report



                                                               Callup Results




       The Roles of the Health Scenario are explained in the Sequence
       Diagram found in Figure 6.




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                                                      21 of 26
        : Patient           : PCP            Hospital : Hospital                      : Laboratory      : Clinical Portal
                                                                   Hub : Hospital
                Examination

                                       Register
                                                                                                     Clinical
                                                                                                     Reports
                                                       Lab Test Via Hub




                                                              Forward Report

                           Procedure


                                                                            Forward Report



                                                                                             Forward Report



                                                               Callup Results




                                                                                         Lab:                   Clinical
                                                                   Hub: VIQUITY                                 Portal;
                        SYBASE                Hospital:                                  NETFISH,
                                                                                         NTT                    CARE DATA,
                                              CYCLONE
                                                                                         COMM/NTT               WEB
                                                                                         DATA                   METHODS




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                                                   22 of 26
4 Appendix A:


1.1 Table of Functions

The Face-to-Face meeting April 17, 2001 worked out the following table, summarizing
the use of the ebXML specifications during the Proof of Concept Demonstration.


TRP               CPP/CPA           BP               CC               Registry        Formatted

    SMTP –        Discover of       BP Definition    CC Document      Content         Formatted

    MAIL          CPP                                Creation         lifecycle
    SERVER
HTTP-SOAP-        CPP into          BP Schema        Assembly         3 types of
MSG               Registry          Generation       Methodology      services
Some Reliable     CPA Assembly      BP Storage in    Registry         Retrieving
Message                             Registration     Interaction      objects
Security          Use of CPA for    Build CPP
SMIME/PGP         Runtime           Based
CA Server
                  CPA Negotiate     Store CPA in
                                    Registry
                  CPA Service       Binary
                  Extension         Collaboration
                                    Drill Down

                                                                                      Formatted


4.1 Table of Document Types

   Institution          Documents                Comments             Contact

RosettaNet         PIP21 (Catalogue)       Submitted by            Jeffrey Eck,
                   PIP3A4 (Purchase        proposal deadline       GE
                   Order)                  but not tied to any
                                           specifications          Hicham Bahi,
                                                                   Documentum


CommerceOne        XCBL                    Submitted by            Dimitri
                                                                   Cherkassky,


40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                     23 of 26
                                           proposal deadline   Commerce One

OAG                                                            Glenn
                                                               Thomsen,
                                                               Killdara

EDI                                        Shows legacy        Jeffrey Eck,
                                           compatibility       GE




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012                 24 of 26
5 APPENDIX B:


3.45.1         AIAG
    The Automotive Industry Action Group is a globally recognized
    organization founded in 1982 by a group of visionary managers from
    DaimlerChrysler, Ford Motor Company, and General Motors. The
    purpose: To provide an open forum where members cooperate in
    developing and promoting solutions that enhance the prosperity of
    the automotive industry. AIAG’s focus is to continuously improve
    business processes and practices involving trading partners
    throughout the supply chain.
                                                                           Formatted


5.2 HL7
    Health Level Seven is one of several ANSI-accredited Standards
    Developing Organizations (SDOs) operating in the healthcare arena.
    Health Level Seven’s domain is clinical and administrative data. Our
    mission is to: "To provide standards for the exchange, management
    and integration of data that support clinical patient care and the
    management, delivery and evaluation of healthcare services.
    Specifically, to create flexible, cost effective approaches,
    standards, guidelines, methodologies, and related services for
    interoperability between healthcare information systems."


3.55.3         OAGI
    The Open Applications Group is a non-profit consortium focusing on
    best practices and process based XML content for eBusiness and
    Application Integration. It is the largest publisher of XML based
    content for business software interoperability in the world. Open
    Applications Group, Inc. members have over 5 years of extensive
    experience in building this industry consensus based framework for
    business software application interoperability and have developed a
    repeatable process for quickly developing high quality business
    content and XML representations of that content.


3.65.4         Rosettanet
    A consortium of more than 400 of the world's leading Electronic
    Components (EC), Information Technology (IT) and Semiconductor
    Manufacturing (SM) companies, RosettaNet is a self-funded, non-
    profit organization dedicated to creating, implementing and
    promoting open e-business standards. These standards form a common
    e-business language, aligning processes between trading partners on
    a global basis.




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012          25 of 26
3.75.5         SWIFT
    SWIFT is an industry owned co-operative supplying secure messaging
    services and interface software to over 7,000 financial institutions
    in 192 countries.
    We provide messaging services to banks, broker-dealers and
    investment managers, as well as to market infrastructures in
    payments, treasury, securities and trade. These services help our
    customers reduce costs, improve automation and manage risk.


3.85.6         X12
    The Accredited Standards Committee (ASC) X12, comprised of cross-
    industry representation, delivers the most widely implemented
    electronic data interchange (EDI) standards that interact with a
    multitude of e-commerce technologies and serves as the premier
    source for integrating electronic applications. Through the X12
    Committee's standards and active participation in emerging and
    technically relevant initiatives, ASC X12 links together multiple
    industries and sets the norm for a more effective exchange of
    information.




40f3f767-31a7-4d9a-8704-c0c45b9b506c.doc10/24/2012          26 of 26

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:10/25/2012
language:English
pages:26