Transcript BT experience of HL7

How HL7v3 Infrastructure issues affect
implementation and testing.
Joseph Waller – Solution Architect (XML Solutions ltd)
Copyright
© British Telecommunications plc 2007
Registered Office: 81 Newgate Street, London EC1A 7AJ
Confidentiality
All information in this document is provided in confidence for the sole purpose of adjudication of the document and shall not be used for any other
purpose and shall not be published or disclosed wholly or in part to any other party without BT’s prior permission in writing and shall be held in
safe custody. These obligations shall not apply to information which is published or becomes known legitimately from some source other than
BT.
Many of the product, service and company names referred to in this document are trademarks or registered trademarks.
They are all hereby acknowledged.
Notice
To the extent that this document contains any information concerning Clinical Safety (such term having its ordinary meaning until a specific definition
may be agreed upon by NHS CFH and the Contractor) or any other information not specifically mandated by the Project Agreement, it is shared
by the Contractor with NHS CFH on a voluntary, Confidential and 'without prejudice' basis for the purpose of informing NHS CFH and advancing
mutual learning on the subject matter concerned.
Introduction
This discussion focuses on Transport Issues with HL7v3 (transmission wrappers
etc)
Found on our (CFH & BT & co) large programme
Straw poll
Please feel free to ask questions
Contents
Intro to English NHS National Programme for IT. (Optional)
What does Spine do, by subsystem (Optional)
Where is HL7 used
How each subsystem uses HL7
Briefly mention the benefits of HL7
Five challenges faced by BT. (recommendations or advice)
Some solutions
Introduction: An National Integrated Care Record System
National Programmes:
•N3 (BT)
•NWCS (BT)
•CAB (Atos)
•NHS Spine (BT)
Accenture
CSC
CSC
British Telecom
Fujitsu
Owner: Peter Wilson. Doc. No. AH204. Issue 2. May ‘04. Review: Oct. ‘04. Page 5 of 47
Introduction: Some figures… so far
Smartcard registration
There are 410,575 Smartcard holders who are registered and approved for access to the Spine.
Electronic Prescription Service (EPS)
Over 48 million (48,044,505) prescription messages have now been transmitted electronically.
6,894 GP practices have had technical upgrades to the new system. 4,293 of these practices are actively operating the
Electronic Prescription Service (EPS).
7,077 pharmacy systems have had technical upgrades to the new system and 4,887 are actively operating EPS.
EPS is being used for over 17% of daily prescription messages.
Choose & Book
Over five and a half million (5,959,307) bookings have been made to date.
Choose and Book is being used for over 45% of NHS referral activity from GP surgery to first outpatient appointment.
Over 85% of all GP practices have used Choose and Book to refer their patients to hospital
GP2GP Transfer
GP2GP has now been used for 34,434 medical record transfers.
3,503 GP practices have had technical upgrades to the new system. 2,346 of these practices are now actively operating
GP2GP.
What does Spine do? How all the parts fit together …
Electronic
Booking
Personal
Demographic
Service (PDS)
Personal Spine
Information
Service (PSIS)
Electronic
Transfer of
Prescriptions
Data services
for Secondary
Uses
Spine (NASP)
delivers
national
services
TMS
processes all
messages
Message traffic both-ways
LSPs
deliver a
range of local
functionality
StHAs /
Trusts / Units /
Primary Care /
Social Care
care & services
for patients
A Cluster
What does Spine do? A Typical Flow of Information
Example Spine
Information
Personal Details
Referral information
Previous Care Summaries
Medication Information
Details of Clinical Events
Clinical correspondence
Discharge summaries
Current Care Providers
Patient care
domain
NHS CRS
domain
Information
The
Spine
LSP
Service
Healthcare
service
Clinical Event
LSP Systems
• GP systems
• Hospital systems … etc.,.
● A clinical event takes place in a healthcare service
● The Local service requests summary information from
the Spine
● Information is used to inform current care
● Care given – details placed onto LSPs local service
● The Spine is also updated with recent care details
9
Where is HL7 used? Architectural Overview
Data
Messages
ebXML
WS-A
Patient Details
eBooking
eBooking
Clinical Messages
Clinical Messages
eTP
eTP
Live A
Data Centre
Applications
Personal Spine
Information
Service
Patient Details
Data Centres
Other Links
Spine
Directory
Service
Personal
Demographic
Service
Transaction Messaging Service
Links to
‘Health
Space’
Links to
National
Services
Clinical
Applications
(View)
Clinical
Applications
(Input)
Infrastructure/
Services
Help Desk NHS
Help
Desk
Patients
Interfaces
Secondary
Uses
Services
Data Quality &
Data Quality
Management
Access
and
Control
Live B
Data Centre
Links to Remote
Settings
Replacement NWCS
Business
continuity
and DR
COMMERCIAL IN CONFIDENCE & WITHOUT PREJUDICE
To the extent that this document contains any information concerning clinical safety (such term having its ordinary meaning until a specific definition may be agreed upon by the Authority and the Contractor)
or any other information not specifically mandated by the Project Agreement, it is shared by the Contractor with the Authority on a voluntary, confidential and 'without prejudice' basis for the purpose of
informing the Authority.
Where is HL7 used? Commercial considerations
Different partners had different capabilities with HL7
Some partners were able to receive and send HL7
For others BT needed to build adapters
Where is HL7 used: How does each Spine subsystem use HL7v3?
TMS – Routes HL7 (e.g. GP2GP, eBooking) but translates transmission
information to an internal canonical format – CSF- for routing to subsystems.
PDS – Java DTOs (VOs) – required adapter layer to translate HL7 Demographics
into Java.
ETP – state engine – stores HL7 in CLOBS plus meta data.
PSIS – HL7 document storage. CLOBS plus meta data.
SDS – Provides directory services. LDAP directory. Currently most interaction is
via LDAP queries but also some HL7.
ACF – Authorisation subsystem providing Legitimate Relationships between
patients and clinicians. Java DTOs.
Benefits of implementing HL7
Improved interoperability;
Benefit from the wealth of knowledge and work
already done;
An assurance of quality backed by a defined
methodology.
Challenges of implementing HL7
Problem One: Inflexible wrappers. (HL7v3 dictates serialisation of meta data)
Problem Two: Lack of guidance on addressing.
Problem Three: Inflexible Interaction Id. (Versioning HL7v3 messages)
Problem Four: Messages were perceived as unnecessarily complicated and
verbose
Problem Five: Typically slow processing of XML messages (Not really an HL7v3
problem). (Optional)
Problem One: Inextensible and Inflexible Infrastructure Wrappers
HL7 Infrastructure prescribes a payload wrapper.
Confuses the layering.
Leads to confused error handling e.g. Need to send MCCIs from
middleware.
Can lead to repetition of data
Result
Both the SOAP header and the HL7 Transmission Wrapper are
required. Would be nice to avoid the Transmission Wrapper.
Problem One: Confuses the layering
MIME
SOAP Envelop
SOAP Header
ebXML Header
…meta data
SOAP Body
ebXML Manifest
…meta data
HL7 Wrapper
…meta data
HL7 Control Act
HL7 Payload
Problem One: Repetition of Wrapper and Control Act Components
Wrapper Header
Wrapper Response
Additions
Message Id
Duplicate
ACK Type Code
Duplicate
Creation Time
Duplicate
Ref-to Message Id
Duplicate
Version Code
Required
ACK Detail Code
Duplicate
Interaction Id
Duplicate
ACK Acceptance Code
Duplicate
Processing Code
Required
Control Act
Processing Mode Code
Not Used
Author Person Role
Required
Accept ACK Code
Not Used
Author Person User
Required
Device To/From
Required
Author Person Role
Profile
Required
Organisation To/From
Required
Participant System Id
Required
Detected Issue Code
Required
Problem One Solution: A more flexible binding for the infrastructure
ebXML Message
Header
ebXML Message
Header
Interaction
Party Address
Context
Message Data
Message Id,
CreateTime
Message Policy
Acknowledgment
Ack Codes, Ref to
Message Id
ErrorList
CFH Extensions
Manifest
Device, Organisation
To/From, Processing
Code
Problem One Solution: A more flexible binding for the infrastructure
Simpler HL7 Wrapper
HL7 Template
HL7 Meta Data
Version Code
Author, Participant
Author, Participants
Business Signal
Service Message
Detected Issue
Problem One Solution: HL7 Message Query Request Example
< QUPA_IN010000UK xmlns="urn:hl7-org:v3">
<id root="F2CFA430-AD2C-3FDB-E034-0003BA4D7E9F"/>
<creationTime value="20050321084802"/>
<versionCode code="V3NPfIT3.0"/>
<interactionId root="2.16.840.1.113883.2.1.3.2.4.12" extension="PORX_IN020101UK05"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/>
<communicationFunctionRcv>
<device>
<id root="1.2.826.0.1285.0.2.0.107" extension="ETP_ASID"/>
</device>
</communicationFunctionRcv>
<communicationFunctionSnd>
<device>
<id root="1.2.826.0.1285.0.2.0.107" extension="15903"/>
</device>
</communicationFunctionSnd>
<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
<AgentPersonSDS classCode="AGNT">
<id root="1.2.826.0.1285.0.2.0.67" extension="role profile id"/>
<agentPersonSDS classCode="PSN" determinerCode="INSTANCE">
<id root="1.2.826.0.1285.0.2.0.65" extension="user id"/>
</agentPersonSDS>
<part typeCode="PART">
<partSDSRole classCode="ROL">
<id root="1.2.826.0.1285.0.2.1.104" extension="job role id"/>
</partSDSRole>
</part>
</AgentPersonSDS>
</author>
<author1 typeCode="AUT">
<AgentSystemSDS classCode="AGNT">
<agentSystemSDS classCode="DEV" determinerCode="INSTANCE">
<id root="1.2.826.0.1285.0.2.0.107" extension="15903"/>
</agentSystemSDS>
</AgentSystemSDS>
</author1>
<subject typeCode="SUBJ">
<ServiceMsg>
<person.address>
<value use="H">
<postcode>aa1 2bb</postcode>
</value>
</person.address>
</ServiceMsg>
</subject>
</ControlActEvent>
</QUPA_IN010000UK>
<QUPA_IN010000UK>
<MsgData>
<hl7versioncode msg=“xx“ collab=“aaa” domain=“bbb”/>
</MsgData>
<authorPerson>
<id root="1.2.826.0.1285.0.2.0.67" extension="1234"/>
<agentPersonSDS>
<id root="1.2.826.0.1285.0.2.0.67" extension="abcd"/>
</agentPersonSDS>
<partSDSRole>
<id root=".2.826.0.1285.0.2.0.65" extension="9999"/>
</partSDSRole>
</authorPerson>
<authorSystem>
<id root="1.2.826.0.1285.0.2.0.107" extension="aaa-bbb"/>
</authorSystem>
<ServiceMsg>
<person.address>
<value use="H">
<postcode>aa1 2bb</postcode>
</value>
</person.address>
</ServiceMsg>
</QUPA_IN010000UK>
Problem Two: How to do addressing.
HL7 didn’t provide a lot of guidance on how to address a system
(use of the DeviceID).
How the National Programme performs Addressing and Routing
(MHSs and ASIDs)
They will address the message to an Accredited System ID. They
will locate the Party Key (MHS ID) for that ASID (HL7 App ID).
A client will look up a binding in the SDS directory based on
PartyKey, Service, Interaction to find the binding.
Messages arrive as HL7/ebXML or HL7/WS-A Web Services.
But many suppliers have implemented ASID topologies in
different manners.
Problem Two Solution: More guidance
Better definition and descriptions of Device ID
Reference Implementations?
Problem Three: Inflexible Interaction Id
< QUPA_IN010000UK xmlns="urn:hl7-org:v3">
<id root="F2CFA430-AD2C-3FDB-E034-0003BA4D7E9F"/>
<creationTime value="20050321084802"/>
<versionCode code="V3NPfIT3.0"/>
<interactionId root="2.16.840.1.113883.2.1.3.2.4.12" extension="PORX_IN020101UK05"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/>
<communicationFunctionRcv>
<device>
<id root="1.2.826.0.1285.0.2.0.107" extension="ETP_ASID"/>
</device>
</communicationFunctionRcv>
<communicationFunctionSnd>
<device>
<id root="1.2.826.0.1285.0.2.0.107" extension="15903"/>
</device>
</communicationFunctionSnd>
<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
<AgentPersonSDS classCode="AGNT">
<id root="1.2.826.0.1285.0.2.0.67" extension="role profile id"/>
<agentPersonSDS classCode="PSN" determinerCode="INSTANCE">
<id root="1.2.826.0.1285.0.2.0.65" extension="user id"/>
</agentPersonSDS>
<part typeCode="PART">
<partSDSRole classCode="ROL">
<id root="1.2.826.0.1285.0.2.1.104" extension="job role id"/>
</partSDSRole>
</part>
</AgentPersonSDS>
</author>
<author1 typeCode="AUT">
<AgentSystemSDS classCode="AGNT">
<agentSystemSDS classCode="DEV" determinerCode="INSTANCE">
<id root="1.2.826.0.1285.0.2.0.107" extension="15903"/>
</agentSystemSDS>
</AgentSystemSDS>
</author1>
<subject typeCode="SUBJ">
<ServiceMsg>
<person.address>
<value use="H">
<postcode>aa1 2bb</postcode>
</value>
</person.address>
</ServiceMsg>
</subject>
</ControlActEvent>
</QUPA_IN010000UK>
<QUPA_IN010000UK>
<MsgData>
<hl7versioncode msg=“xx“ collab=“aaa” domain=“bbb”/>
</MsgData>
<authorPerson>
<id root="1.2.826.0.1285.0.2.0.67" extension="1234"/>
<agentPersonSDS>
<id root="1.2.826.0.1285.0.2.0.67" extension="abcd"/>
</agentPersonSDS>
<partSDSRole>
<id root=".2.826.0.1285.0.2.0.65" extension="9999"/>
</partSDSRole>
</authorPerson>
<authorSystem>
<id root="1.2.826.0.1285.0.2.0.107" extension="aaa-bbb"/>
</authorSystem>
<ServiceMsg>
<person.address>
<value use="H">
<postcode>aa1 2bb</postcode>
</value>
</person.address>
</ServiceMsg>
</QUPA_IN010000UK>
Problem Three: Inflexible Interaction Id
Is a composite key of the MessageType, Trigger Events and the version. It is the root
element of the message.
InteractionID as root:
Inefficient generic XPaths and for XSLT processing e.g. to find HL7 message id XPath is
hl7:*/hl7:id/@root
Difficult to create generic schema to validate instance messages (for intermediary /
integration engines).
Made creation of WSDL with multiple possible responses difficult.
Using the root node as version identifier - A small change to the message causes a
change to the same element on which a message is processed. This causes:
More substantial changes to the application
Unnecessary changes to the integration / routing infrastructure
How do you version for vocabulary changes.
Corrupted use of InteractionId. Limited success utilising InteractionId as a
composite key.
The National Programme rarely creates a new Interaction ID for a different trigger event.
Problem Three Solution
Our solution. We generally worked around the problems
Response wrappers for WSDL
Tolerated inefficient XPaths
Accept cost of changes to InteractionsIDs
Possible HL7 solutions
Should we separate trigger (conversations) and versioning from the
Interaction ID?
Should we create a generic root element and keep Interaction as an
attribute?
Problem Four: Messages were perceived as unnecessarily complicated /
verbose.
Some aspects of HL7 are verbose.
Makes message less human readable
Increases message development time.
Increases implementation time.
Increases testing
Resource issues
Increased processing costs
Increased storage costs
Increased traffic on network
Problem Four: Sample PDS Message
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example message is provided for illustrative purposes only. It has had no clinical
validation nor is it guaranteed to be fully compliant with the written message specification.
Where there are conflicts with the written message specification or schema, the
specification or schema shall be considered to take precedence. -->
<PdsSuccessfulRetrieval xmlns="urn:hl7-org:v3"
xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:msg="urn:hl7-org:v3/mif"
xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3
../Schemas/PRPA_MT040101UK31.xsd" classCode="OBS" moodCode="EVN">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<!-- NHS number -->
<id root="2.16.840.1.113883.2.1.4.1" extension="9999999484"/>
<!-- To indicate "Sensitive" -->
<confidentialityCode code="S" codeSystem="2.16.840.1.113883.2.1.3.2.4.16.1"/>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<!-- (Current) Usual name -->
<name use="L">
<prefix>Ms</prefix>
<given>Three</given>
<given>Zoe</given>
<family>Editestpatient</family>
<validTime>
<low value="20030930"/>
</validTime>
<id root="2.16.840.1.113883.2.1.3.2.4.18.1" extension="P000000021"/>
</name>
<!-- (Previous) married name -->
<name use="PREVIOUS">
<prefix>Mrs</prefix>
<given>Three</given>
<given>Zoe</given>
<family>Virtualpatient</family>
<validTime>
<low value="19960822"/>
<high value="20030930"/>
</validTime>
<id root="2.16.840.1.113883.2.1.3.2.4.18.1" extension="P000000022"/>
</name>
<!-- Administrative gender of "Female" -->
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example message is provided for illustrative purposes only. It has had no clinical validation nor is it guaranteed to be fully compliant with the written message
specification. Where there are conflicts with the written message specification or schema, the specification or schema shall be considered to take precedence. -->
<PdsSuccessfulRetrieval xmlns="urn:hl7-org:v3" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:msg="urn:hl7-org:v3/mif" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3
../Schemas/PRPA_MT040101UK31.xsd" classCode="OBS" moodCode="EVN">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<!-- NHS number -->
<id root="2.16.840.1.113883.2.1.4.1" extension="9999999484"/>
<!-- To indicate "Sensitive" -->
<confidentialityCode code="S" codeSystem="2.16.840.1.113883.2.1.3.2.4.16.1"/>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<!-- (Current) Usual name -->
<name use="L">
<prefix>Ms</prefix>
<given>Three</given>
<given>Zoe</given>
<family>Editestpatient</family>
<validTime>
<low value="20030930"/>
</validTime>
<id root="2.16.840.1.113883.2.1.3.2.4.18.1" extension="P000000021"/>
</name>
<!-- (Previous) married name -->
<name use="PREVIOUS">
<prefix>Mrs</prefix>
<given>Three</given>
<given>Zoe</given>
<family>Virtualpatient</family>
<validTime>
<low value="19960822"/>
<high value="20030930"/>
</validTime>
<id root="2.16.840.1.113883.2.1.3.2.4.18.1" extension="P000000022"/>
</name>
<!-- Administrative gender of "Female" -->
<administrativeGenderCode code="2"/>
<!-- Full date of birth -->
<birthTime value="19780719"/>
<!-- Full date and time of death -->
<deceasedTime value="200312020635"/>
</patientPerson>
<subjectOf7 typeCode="SBJ">
<nhaisRegistration classCode="OBS" moodCode="EVN">
<!-- To indicate this is an observation of a NHAIS registration -->
<code code="14" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.35"/>
<!-- To indicate "No current NHAIS posting" -->
<value code="X" codeSystem="2.16.840.1.113883.2.1.3.2.4.16.12"/>
</nhaisRegistration>
</subjectOf7>
<subjectOf3 typeCode="SBJ">
<consent classCode="OBS" moodCode="EVN">
<!-- To indicate that type of consent is "Consent to NHS Care Record sharing" -->
<code code="4" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.35"/>
<effectiveTime value="20030506"/>
<!-- To indicate Express Consent where the consent type is "Consent to NHS care record sharing" -->
<value code="1" codeSystem="2.16.840.1.113883.2.1.3.2.4.16.2"/>
<pertinentInformation typeCode="PERT">
<pertinentSupplementaryComments classCode="OBS" moodCode="EVN">
<!-- To indicate this is an observation of consent supplementary comments -->
<code code="7" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.35"/>
<value>Patient would like to discuss further with citizens advice bureau before agreement</value>
</pertinentSupplementaryComments>
</pertinentInformation>
</consent>
</subjectOf3>
<subjectOf2 typeCode="SBJ">
<deathNotification classCode="OBS" moodCode="EVN">
<!-- To indicate this is an observation of a death notification -->
<code code="3" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.35"/>
<!-- "Formal death notice received from Registrar of Deaths" -->
<value code="2" codeSystem="2.16.840.1.113883.2.1.3.2.4.16.5"/>
</deathNotification>
</subjectOf2>
<replacementOf typeCode="REPL">
<oldVersion classCode="PAT">
<!-- Temporary NHS number issued by an NHAIS registration authority -->
<id root="2.16.840.1.113883.2.1.3.2.4.3" extension="BRS123456"/>
</oldVersion>
</replacementOf>
</patientRole>
</subject>
<!-- Serial Change Number always returned -->
<pertinentInformation typeCode="PERT">
<pertinentSerialChangeNumber classCode="OBS" moodCode="EVN">
<!-- To indicate this is an observation of a Serial Change Number -->
<code code="2" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.35"/>
<value value="2"/>
</pertinentSerialChangeNumber>
</pertinentInformation>
</PdsSuccessfulRetrieval>
Problem Four Solution: Two species of HL7 message – Books and Magazines
Magazines stalls
Magazines are lighter;
Magazines are generally transported more quickly;
Magazines use slang, they make cultural assumptions about the
semantic meaning of their content.
Magazines are generally thrown away once they have been read.
Magazines know their target audience.
Books shops
Books are heavier.
Books tend to be stored once received and read again later.
Books tend to provide more background to their main point (semantics
/ meta data).
Don’t always expect to know target audience
Problem Four Solution: Are Spine subsystems books or magazines?
PDS
ACF
SDS
ETP
PSIS
Solution Four Solution: Design for both species – New XML ITS
Applications in which HL7 is used as a transport mechanism
(Magazines) can use the New XML ITS to reduce message bloat.
Demographics applications like PDS
Data translated to own semantics
May not be interested in HL7 meta data.
Applications that use store and query HL7 (Books) can take full
advantage of HL7 specific meta data to aid semantic interoperability.
Mainly clinical like PSIS
Electronic Transfer of Prescriptions
Tend to require semantic interpretation
Problem Five: Typically slow processing of XML
Were getting processing of 8 message per second per CPU and still failing
response time SLAs or 200ms.
Problem complicated by unnecessary spaghetti code.
We could have tried to improve the current J2EE code but we were so far behind
required performance we realised a paradigm shift was required.
Realised that without radical change we would need a new data centre.
Solution Five: Design for XML handling
XML Acceleration Devices
Fast XML processing
Encourages simple design
Naturally separates services
Also create an architecture focussed on messaging
Careful consideration of persistence
Achieving throughput of 100-200 transactions per second with significantly lower
response times.
Solution Five: Benefits of Appliances
Using appliances for accelerating integration and security.
Lower cost – Smaller code base, reduced development time, higher
performance.
Whilst meeting performance and capacity requirements.
Service - Simplicity
Deployment - Rapid deployment with less effort
Flexibility – cross-SPINE support
Security – New capability (outbound SSL, DOS protection, more validation)
Solution Five: Integration Hub Services
Conceptual Architecture
Endpoint validation check.
Orchestration & Routing
Contract validation
Message transformation
Outbound SSL encryption
De-duplication
Accredited system (Authorisation checks)
Messages Persistence
Dead Letters
Retry Mechanisms
Transport and routing
Endpoint check, Orchestration & Routing,
Contract Validation, Message Transformation,
Outbound SSL, Accredited System checks
De-duplication
Dead Letter
Administration
Retry mechanisms
Message
Persistence
Transport and Routing
Solution Five: Integration Hub Architecture
Realised Architecture
XML Accelerator checks and transforms
the message. On the outbound channels
the SSL acceleration is also provided.
Inbound it performs a Endpont check.
Trad. Application Server and Database
Queries provide duplicate checking, dead
letter and retry mechaisms.
Oracle Database or JMS Queue
provides Messages Persistence
JMS queues provide Transport and
Routing except for synchronous
messaging where this is provided by
HTTP.
XML Acceleration Device
Application Server
and Database Query
Database or
JMS Queue
JMS queue or HTTP
Summary
Problem One: Inflexible wrappers. (HL7v3 tries to force addressing into payload)
New Wrappers may address much of this.
Problem Two: How to do addressing
More guidance
Problem Three: Inflexible Interaction Id. (Versioning HL7v3 messages)
New XML ITS may address this.
Problem Four: Messages were perceived as unnecessarily complicated and
verbose
New XML ITS
Problem Five: Typically slow processing of XML messages (Not specifically an
HL7v3 problem).
Messaging / SOA focussed architecture
Thank you
Offices worldwide
Telecommunications services described are subject to availability and may be modified from time to time.
Services and equipment are provided subject to British Telecommunications plc's respective standard
conditions of contract. Nothing in this publication forms any part of any contract.
© British Telecommunications plc 2006