How XMLEDI will differ from existing EDI and EDIFACT

1
How XML/EDI will differ from existing EDI and
EDIFACT

• Andrew Hinchley
• ahinchley_at_communicationsplanning.ltd.uk
• ISIS European XML/EDI pilot project
• www.tieke.fi/isis-xmledi
• website with implementation experience during
  1999
• www.communicationsplanning.ltd.uk

2
How XML/EDI will differ from existing EDI and
EDIFACT

• Experiences in two projects this year
• Implementation feedback
• ISIS European XML/EDI pilot project
• healthcare (XMLEPR in UK) and transport
• recommendations on XML/EDI to DGIII
• Martin Bryan as SGML/XML expert
• Gerard Freriks provides Netherlands
  representation
• Kettering General Hospital,UK
• Live implementation with two suppliers

3
General developments

• Reaction to industry announcements from Oasis and
  Microsoft-repositories/DTDs/schemas
• Some detailed issues
• security
• headers/ routing
• acknowledgements

4
Existing EDI/EDIFACT problems

• Limited definition support, supplement message
  definitions with MIGs - Message Implementation
  Guidelines (text!!!)
• Limited tools and software
• No real support for business variation
• UN/EDIFACT Attempts both repository and message
  control - huge resources needed
• Too complex for simple applications
• Too simple for complex applications

5
XML and Convergence!!

• EDI and messaging
• -fully structured DTDs with managed XML tags
• -agreements between sender and receiver!
• Documents
• Forms
• Databases
• Influence of Internet/Web technologies
• But where is the convergence point?
• What is the role of XML/EDI in this?

6
XML/EDI-origins

• XML/EDI proposed by small group in early 1998
• Group formalised under GCA
• No formal outputs as such from group
• In Europe
• ISIS XML/EDI project
• CEN ISSS XML/EDI Workshop(October 27th)
• Dick Raman, EDI-TIE
• DGIII/CEN XML/EDI December 1st event

7
XSL
8
Which XML standards should be used?

• YES
• XML 1.0 valid well-formed DTDs and namespace
• Schemas needed-all will move to these with W3C!
• Experimentation
• XSL with HTML output, also SMIL
• NO
• XML links/Xpointers used so far
• Some SGML features have been evaluated but keep
  to XML standards -architectural forms
• RDF!

9
Main approaches to message DTD development

• Derive DTDs/schemas from information rich
  message models
• OR
• Derive from EDIFACT messages
• OR
• Develop new object repositories,then message
  DTDs/schemas

10
EDIFACT and DTD development-options

• Automatic translation of segment and data
  elements tags (X12 favours this)
• MIG-based, capture semantics, retain relation to
  EDIFACT tags(ISIS-transport)
• UN/EDIFACT announcement on with Oasis on
  repositories-methods to be agreed
• Commerce-Onesomewhere between these-electronic
  commerce

11
(No Transcript)
12
UN/EDIFACT and Oasis

• Boston, MA, USA/Geneva, Switzerland, September
  15, 1999-- The United Nationsbody for Trade
  Facilitation and Electronic Business (UN/CEFACT)
  and theOrganization for the Advancement of
  Structured Information Standards (OASIS)have
  joined forces to initiate a worldwide project to
  standardize XMLbusiness specifications.

13
UN/EDIFACT and Oasis

• UN/CEFACT and OASIS have established the
  Electronic Business XML Initiative to develop a
  technical framework that will enableXML to be
  utilized in a consistent manner for the exchange
  of all electronicbusiness data.

14
UN/EDIFACT and Oasis

• Industry groups currently working on XML
  specifications have been invited to participate
  in the 18-month project. The results of
  theElectronic Business XML Initiative will be
  placed in the public domain on XML.org

15
Commerce-One

• CBL2.0
• Common Business Library
• focussing on the supply chain
• Candidate set of repository objects
• Retains linkages to EDIFACT, particularly use of
  code lists
• Standard Messages then composed from CBL objects
• BT offers European procurement service

16
XMLEPR Business Objectives

• To implement a major new European standard for
  transfer of patient records
• To use XML/EDI to achieve this by developing
  automated XML creation rules
• Success would mean that the same approach can be
  used for many existing h/c messaging standards
  from European healthcare standards -TC251

17
The UK NHS requirement

• An ability to transfer structured patient records
  between systems from different suppliers would
  mean that the clinical record can always follows
  the patient
• The solution needs to be clinically safe and as
  full as possible
• Use of XML and current use of EDIFACT?
• National standards! Multi-organisation and
  suppliers

18
GP
Patient
19
Defining patient record structure

• The activity to create a message structure
  adequate to meet requirements has not itself been
  XML-specific
• It has been carried out in the CEN TC251
  healthcare IT standards process
• It is the combination of this work plus the
  capabilities of XML which has led to the solution
  now available

20
Mapping from information models

• The message structure is defined in UML with
  fully defined object classes and attributes which
  reflect requirements
• Careful selection of XML functions to support the
  model leads to the potential for automated XML
  output from the process
• This has a substantial effect on reducing
  development resources and increasing the accuracy
  of the process

21
Other benefits

• TC251 has been developing clinical messages using
  information models since 1995. There is a large
  library of messages which can benefit from the
  XML solutions indicated
• There is substantial common interests with XML
  solutions for HL7 version 3 in the US.
• A shared result would be a world XML standard for
  patient-focussed clinical messaging generally

22
How to use XML to achieve the goals indicated

• Aim at a complete DTD -no undefined tags
• Focus on XML 1.0 and existing parsers/tools/use
  of DOM
• No absolute requirement in this application for
  XSL/presentation
• Arrive at a set of consistent mapping rules from
  the information model direct to the DTD

23
XML DTD Mapping Process
Clinical Information Model
Complete DTD
Naming rules
XML element and attribute names
All UML object classes
XML Elements
Relationships
XML has direct equivalents in most cases
Data Content Already partly defined
XML attributes
Object Model References
Hyperlinks in Word NOI for viewer support
24
Clinical validation
25
Tools

• 700 line DTD
• HTML version for easy reading
• Special viewer developed for analysing clinical
  messages
• Investigate using style sheets/XSL to present
  messages for analysis-under way
• Now also using available off-the-shelf tools for
  DTD viewing XML Authority

26
Mapping rules from UML

• Formal set of rules published
• Semi-automatic production of DTDs/schemas
• Standard for Europe for clinical healthcare
• World-wide application investigated
• Directly applicable to other sectors?

27
Maximising the Return on Investment
28
What have we done that we could not do with
EDIFACT?

• Presentation
• XML/EDI messages can be displayed using standard
  tools
• XSL Considered Harmful
• Declaration of War
• by Michael Leventhal

29
XSL-presentation

• XSL transformations to HTML display
• EDI implies strong business relationships between
  sender and receiver
• Who controls display?
• Sender controlled
• receiver controlled
• ISIS XML/EDI - Experimenting with various
  (community-controlled) stylesheets
• Initial implementation at Kettering
• send HTML and XML in message

30
What have we done that we could not do with
EDIFACT?

• Implementation differences
• No longer use standard EDI translator/management
  software?
• Parse part of the message -keep message fragments
  for parsing later in sequence/in the application
• Data capture/forms management

31
XML/EDI headers and acknowledgements

• New project at Kettering General Hospital UK to
  implement live patient referral/discharge
  messages by XML/EDI
• Review what is required for XML/EDI header
• Mixed flows with EDIFACT Interchanges?
• What have Biztalk proposed?
• Do we need a standard?

32
Headers -requirements

• Identify XML/EDI message sender and recipient
• Indicate whether acknowledgment required
• Unique message id. for acknowledgement and audit
• Routing function needed?
• Direct internet use
• Continue to use VANs/third-parties?

33
Acknowledgement message

• lt!-- RcptAckMsg I00000) --gt
• lt!ELEMENT RcptAckMsg (MsgId ,
• MsgIssueDate ,
• MsgSender ,
• MsgRecipient ,
• MsgRef,
• MsgErrorText?)gt

34
Biztalk proposals

• The BizTalk Framework is an XML framework for
  application integration and electronic commerce.
  It includes a design framework for implementing
  an XML schema and a set of XML tags used in
  messages sent between applications

35
Biztalk proposals-header

• No acknowledgements-Biztalk say that this is a
  network function
• LocationID. This is the abstract information that
  pertains to a place. This information should be
  compatible with whatever delivery service or
  agent is used to manage flows that use BizTalk
  Framework messaging.
• LocationType. This is a secondary qualifier on
  LocationID.

36
Biztalk proposals-header

• Process. This tag is for conveying the name of
  the business or technical process that needs to
  be invoked or notified when a message is
  delivered.
• Path. This attribute is provided as a place for a
  delivery agent to annotate a message as it passes
  through each delivery agent.
• Handle. This attribute represents an abstract
  identifier used by the final application.

37
Biztalk proposals-header

• ltBizTalk xmlns"urnschemas-biztalk-org/biztalk-0.
  81.xml"gtltRoutegtltFrom locationID"111111111"
  locationType"DUNS"process"" route""
  handle"45"/gtltTo locationID"222222222"
  locationType"DUNS"process"" route""
  handle"93"/gtlt/RoutegtltBodygt ltPO
  xmlns"urnschemas-biztalk-orgfabrikam-com/Purcha
  seOrder"gt Purchase order body document in XML
  data here lt/POgtlt/Bodygtlt/BizTalkgt

38
Biztalk issues

• IETF/W3C should be defining headers not
  Microsoft?
• Sender and Recipient identification should allow
  multiple schemes DUNS,EAN etc.
• This can be achieved through use of ISO6523
  register
• Routing is an issue
• if complete DTD is encrypted then routing info.
  will not be available

39
XML/EDI -security

• A number of existing message security standards
  exist and can be used
• Secure MIME (now part of CMS) is most commonly
  available
• Email products may not be suitable for XML/EDI
  flows
• EDIFACT security standard is not useful as it is
  heavily dependent on EDIFACT syntax
• In current UK work, implementing encryption for
  all patient-content messages

40
XML/EDI -security

• XML/EDI takes us towards persistent documents of
  document/message hybrids
• messaging security is no longer appropriate-but
  what do we need?
• W3C working on XML digital signature standard
• can be used anywhere in the XML message or
  document to sign any part of it
• multiple signatures for overlapping parts will be
  possible

41
Further problems to be addressed -Validation

• EDIFACT never got on top of validating messages
• some tools captured MIG validation
• some products implemented some features
• XML/EDI should sort this problem
• Where to Validate?
• sender and/or receiver?

42
Other requirements -Message Validation

• What to Validate
• Data types
• Constraints
• Code ranges
• repetition
• Dependencies
• Schemas can support a number of these
  requirements- but element in context?
• HL7 call this Indiana dot problem

43
Further problems - Standardising DTDs/schemas

• If message models are standardised or if we have
  repositories , do we need standardised
  DTDs/schemas?
• Where profiles/local variation occurs, should
  this be implemented by modifying message model or
  DTD/schema?

44
XML/EDI and W3C

• Should XML/EDI focus on particular W3C XML
  standards?
• If so, how can this be expressed generally
  /standardised?rely on Biztalk??
• Would W3C reconsider their position on XML/EDI?
• OR is XML/EDI just any use of XML for messaging?

45
Web sites

• ISIS European XML/EDI pilot
• www.tieke.fi/isis-xmledi
• Recommendations on XML/EDI mapping this month
• Transport DTDs in conjunction with Finnish
  transport sector- also experimenting with
  WAP/mobiles!
• XMLEPR detailed h/care results
• www.communicationsplanning.ltd.uk

46
European Commission Workshop on XML/EDI

• DG III and CEN ISSS support
• December 1st Brussels
• Limited places, but no charge
• www.cenorm.be