Healthcare Analytics with WebSphere Message Broker

© 2012 IBM Corporation
Healthcare Connectivity Pack
Healthcare Analytics
Ant Phillips
antphill@uk.ibm.com

Use Restrictions
The Program is capable of being used as a medical device data system to transfer, store, and convert data from one
format to another. The Program may occasionally transmit data to bedside medical devices (e.g., for polling and telemetry).
However, the Program itself is not a medical device.
The following uses of the Program are prohibited:
a. use to control any bedside medical device for clinical, therapeutic or treatment purposes (for example, but without
limitation, the administration of medication, anaesthetics, saline solutions and the like);
b. use for active patient monitoring (i.e., where the Program is used as the sole means of monitoring life-critical patient data
, e.g. heart rates);
c. use for decision support (i.e., where the Program is used as the main basis to determine patient-specific treatment or
immediate clinical action); or
d. use in any active monitoring that depends on the timeliness of data transmission.
Indemnity to IBM
Licensee will indemnify International Business Machines Corporation and its affiliated companies against any and all third
party claims and liability arising directly or indirectly from any use of the Program by or for Licensee for a use or purpose
that is prohibited by the provisions of the foregoing section, "Use Restrictions".
As of December 11th
2012, WebSphere Message Broker Connectivity Pack for Healthcare is currently available for purchase
through the Passport Advantage program only for use in the following specific countries :
Australia; Austria; Canada; Chile; China; Colombia; Denmark, Finland; Germany; Italy; Malaysia, Mexico; Netherlands; New Zealand; Norway; Poland;
Portugal, Singapore; Spain, Switzerland; Sweden, United Kingdom; United States of America
For the current list of licensed geographies please see the following URL:
http://www-01.ibm.com/software/integration/wbimessagebroker/healthcare/license/index.html
Important Disclaimer and Availability Information
WebSphere Message Broker Connectivity Pack for Healthcare

Where Does It Fit?
3

© 2012 IBM Corporation4
Big Data
 The healthcare world is increasingly reliant on data for business insight
– Analytics can provide dramatic real world cost savings and efficiency improvements
– It is an enabling technology allowing scarce resources to be used more effectively
– Analytics works at many levels across the healthcare continuum
– Small departments all the way up to population management and health economics
 IBM Integration Bus is an outstanding source for analytics applications
– Huge amounts of healthcare data flow through IBM Integration Bus every day
– Using the integration engine to feed downstream applications makes great sense
– Covers three key healthcare standards: CDA, DICOM and HL7 (v2)
 Tooling simplifies many scenarios when working with healthcare data
– Understand what clinical information is present in the data
– Extract the relevant clinical information and remove the noise
– Feed the information to downstream databases and applications
– Validate the incoming data meets the appropriate standard

Data Analysis Profiles
 The knowledge of a standard is encapsulated in a Data Analysis Profile
– Healthcare Connectivity Pack provides profiles for CDA, DICOM and HL7 (v2)
– The profile specifies how to identify interesting data in source documents
– It also contains zero or more glossaries where medical terms are stored (LOINC)
 Your starting point is to create a Data Analysis project in your workspace
– It is a design project where you explore data and select relevant data for extraction
– You select the type of data you will work with when you create the project
– Add the data you want to extract from the source documents into a target model
– The target model generates the IBM Integration Bus artifacts (map, subflow, validation)

CDA/CCD

CDA Introduction
 Clinical documents are derived from the foundational HL7 v3 standards
– Arguably the most successful part of the HL7 v3 initiative
– Based on an underlying Reference Implementation Model (RIM)
– Clinical document specifications are derived (cloned) from the RIM
 This technology has been piloted at several sites worldwide
– Guan Dong Hospital of Traditional Chinese Medicine
– Largest modern hospital enterprise in South China
– Over 10,000 patients visit per day (in excess of 2000 beds)
– 4 million patient-visit per year across one central hospital and four branches
– Pilot project included a data warehouse for clinical studies
 CDA is gaining use worldwide as healthcare seeks to join systems up
– Clinical Document Architecture (CDA) standard is tremendously flexible
– CDAs can model a wide variety of clinical information both coded and narrative
– More than 100 implementation guides have been written for CDAs alone!
 Our aim is to simplify the creation and consumption of clinical documents
– Often this is with a view to extracting clinical information into a database
– Simplifies the use of analytics to gain insight into healthcare data
– Wide variety of uses such as patient similarity searches and public health studies

Clinical Document Data Analysis
 Understanding your clinical documents is the vital first step
– Recursive nature of CDAs makes working from the schema very difficult
– component, section, entry and entryRelationship to mention just a few!
– Great flexibility in representing and modelling rich clinical statements
 The Healthcare Connectivity Pack understands clinical documents
– IBM Integration Bus is configured with a CDA Data Analysis Profile
– Load example documents representing your implementation guide(s)
– Pre-configured with CDA, C-CDA, CCD, HITSP (C32 and C83) template IDs
– A glossary of LOINC terms is built-in so that codes are understandable
Import your source documents into a
Data Analysis project – the summary
page shows you how many documents
were loaded, validation issues, and
information about missing LOINC
codes

Navigating Documents
 Data Analysis Profile identifies key sections in the clinical document
– Navigate easily from the logical model to your source documents
– Multiple example documents can be loaded into your Data Analysis project
– Cardinality of the clinical data can be explored across the document set
The Data Analysis
project shows you the
meaning of different
parts of your documents
Search for clinical
concepts across all
your source documents
See where the relevant
information is actually
stored in your documents

Target Model
 The target model represents the information you want extracted
– The goal is to identify and map out the relevant clinical information
– The Data Analysis Profile creates an XML schema for the target model
– Typically large amounts of the clinical document is not relevant
 Simply drag-and-drop your clinical data onto the target model
– By default all attributes and elements are assumed to be required
– Refine the target model by removing unnecessary data and renaming elements
– Often this refinement means removing structural attributes like classCode
The target model contains just
the information you want to
extract from the source
documents – the tooling creates
an XML schema to represent this
simplified model

Generation
 Generate the map, XSD, XSLT and subflow from the target model
– The XSD defines a schema for the data specified in the target model
– The map (MSL) extracts data in CDAs into the target model
– As with XML schemas, maps can be deployed direct to IBM Integration Bus
 The XPATH expression shows what has been mapped automatically
– Clearly building this kind of expression by hand would be tedious (at best!)

DICOM

DICOM Introduction
 DICOM is a widely adopted integration standard for medical imaging
– All modern imaging systems support DICOM (CT, MRI, Ultrasound, X-Ray etc)
– DICOM includes a file format definition and a network communications protocol
– Communication protocol uses TCP/IP to communicate between systems
– Standard is maintained by National Electrical Manufacturers Association (NEMA)
 Enables the integration between PACS, workstations and modalities
– PACS stands for Picture Archiving and Communication Systems
– A modality is the source machine type (CT, MRI, Ultrasound, X-Ray etc)
 Medical imaging has traditionally been a separate function in hospitals
– This is quickly changing as hospital systems become more integrated
– IHE is also active in this space – for example scheduled workflow (SWF) scenarios
– Scheduled workflows require close integration between HL7 and DICOM systems
13

External Expert / Second Opinion
14
 In many geographies radiology skills are in critically short supply
– IBM Integration Bus can be used to route DICOM images to external experts
– Routing based on data in the DICOM image (for example, a SNOMED code)
– Solves the larger integration picture such as email notification to physicians

Pre-Fetch on Admission
15
 Preparing studies in advance when patients are admitted to hospital
– Flexible routing options to retrieve studies and send them to the right specialists
– Routing based on data in the DICOM image (for example, a SNOMED code)
– Requires a mixture of DICOM commands including C-FIND, C-MOVE and C-STORE

DICOM Nodes
16
 Core set of DICOM nodes provide flexibility in building solutions
– Requires a mixture of DICOM commands including MOVE, FIND and STORE
– IBM Integration Bus can act as both a client (SCU) and server (SCP)
– DICOM images are propagated through IBM Integration Bus as XML messages

DICOM Data Analysis
 The DICOM Data Analysis profile understands DICOM messages
– Data Analysis Profile includes a glossary with 2K+ standard DICOM tags
– Vendor specific DICOM tags are common and are handled by the profile
– Search for DICOM attributes and understand what modalities are actually sending
Search for particular pieces of
information across all DICOM
messages using the display
names
The Navigator shows you
the meaning of the
DICOM attributes – the
Data Filter allows you to
search using these display
names
This is an example DICOM message
which flows through IBM Integration
Bus - the message contains codes
that specify the meaning of each
element

Target Model
 Creating the target model is the same sequence of steps as before!
– Simply drag-and-drop your DICOM attributes onto the target model
– Generate the IBM Integration Bus artefacts including map, subflow and library
The tooling generates an IBM
Integration Bus subflow which extracts
the information from DICOM
messages into the target model – the
extraction is implemented as a
graphical map
XPATH predicates are automatically
added to the map to locate the
required data from the DICOM
messages

HL7 v2

HL7 v2 Introduction
 Messaging standard for the exchange of healthcare information
– Health Level-7 refers to the application (top) layer in the ISO OSI Reference Model
– Version 2.2 of the standard was ANSI accredited in 1996
– HL7 is the key connectivity standard in the provider space
 Deployment specific message segments are supported (Z-segments) n
– Supports variety of character encodings (ASCII, ISO-8859 and Unicode)
 Latest version (v2.7) was approved by ANSI in December 2012
– Compliance as always lags behind the standardisation process
– HL7 in IBM Integration Bus is up to date for everything up to and including v2.7
 There are quite a few things that the HL7 v.2x standard does not cover!
 The standard is not a complete systems integration solution
– Lack of process conformity within healthcare delivery environments
– This effectively leads to a unique use of the standard at each site
– Standard is really a common framework for integrating systems
– Standard builds on other coding systems such as LOINC and SNOMED
20

HL7 MLLP Nodes
21
 Nodes encapsulate the MLLP protocol and HL7 message parsing
– Nodes handle de-duplication, validation, acknowledgments and timeout handling
– Fully up to date including HL7 v2.7 and all the specific chapter messages
– Easy to use nodes enable new HL7 message processing scenarios
– Examples include HL7 to data warehouse and HL7 device aggregator integration
 Models defined in industry standard Data Format Description Language
– Outstanding tooling makes changing the HL7 models quick and easy to do!

HL7 v2 Data Analysis
 IBM Integration Bus is configured with an HL7 Data Analysis Profile
– Makes it quick and easy to locate information and extract it from HL7 v2.7 messages
– Backwards compatible with HL7 v2.x messages (for example, 2.3 and 2.5.1)
– The Data Analysis Profile works closely with the HL7 DFDL schemas
– DFDL schemas have very descriptive names so search and filtering is easy
– The HL7 patterns all provide a journal to publish HL7 DFDL messages as XML
DFDL makes it simple to convert the
HL7 ER format into XML ready for
processing by your Data Analysis
projects – the HL7 patterns have this
capability built in!

Target Model
 Creating the target model is the same sequence of steps as before!
– Simply drag-and-drop your HL7 elements onto the target model
– Generate the IBM Integration Bus artefacts including map, subflow and library
Redundant components in the HL7
message can be removed – element
names can be changed to make the
document easy to consume by
downstream applications

Healthcare Connectivity Pack
24

Clinical Terminology - Introduction
26
 Most scientific fields of endeavour have a well defined terminology
– Healthcare covers a huge breadth of scientific levels – radiologists work with subatomic
particles, haematologists study blood cells, physicians are concerned with abnormal
body functions, and public health doctors study the spread of disease in populations

Coding vs Classification
 Classification collects things into groups or classes
– It is the basis for the majority of statistical analysis, accountancy and much more
– By its very nature, the process of classifying things loses accuracy
 Coding is the allocation of identifiers to things – an alternative name
– No more interest to end users than a bar code on a cereal packet!
 Here is a skiing accident described by the trauma surgeon as a closed
spiral fracture of the shaft of the right tibia with fractured fibula:
In ICD-10 this injury is described by the following classification:
Chapter XIX: Injury, poisoning, and certain other consequences of external cause (S00-T98)
S82: Fracture of lower leg, including ankle
S82.2: Fracture of shaft of tibia (with or without mention of fracture of fibula)
S82.2.1: Closed fracture of shaft of tibia
 Note that ICD-10 does not specify whether the leg or left or right, whether
the fracture is simple, spiral or compound or if the fibula is also fractured
27

ICD-10
 International Statistical Classification of Diseases and Health Problems
 Enables the recording, analysis and interpretation for patient mortality
– ICD-10 contains more than 140K codes (ICD-9 contains 17K codes)
 In practice, it has become the standard classification for all general
epidemiological and many health management purposes
 ICD-10 is not suitable for coding distinct clinical entities
 Format XXX.XXX X [category.etiology/site/severity extension]:
K50.013 Crohn’s disease of small intestine with fistula
K71.51 Toxic liver disease with chronic active hepatitis with ascites
H02.835 Dermatochalasis of left lower eyelid
T81.530 Perforation due to foreign body accidently left in body following surgical operation
 ICD-10 widely used for medical reimbursements in the US (HIPPA)
28
Epidemiology is the study of patterns of health and illness and associated factors at the population
level

Read Codes
 Read Codes are widely used by GPs in the UK NHS and New Zealand
– Used by clinicians to record patient findings and procedures
– Read codes come in two versions – v2 and v3 (Clinical Terms v3)
– Codes are organised into chapters identified by the first character
 Codes are five characters long with missing letters replaced by a dot
– Letters are 0-9, A-Z and a-z (omitting O and I to reduce coding errors)
– Results in a very large potential code space > 750M codes (605
)
H Respiratory disease (H33zz Asthma NOS)
J Digestive system diseases (J20.. Acute appendicitis)
G Circulatory system diseases (G3z.. Ischaemic heart disease NOS)
 Framework is broken down into subchapters to give more precise detail
H.... Respiratory system disease
H3... Chronic Obstructive Pulmonary Disease
H33.. Asthma
H331. Intrinsic asthma
H3311 Intrinsic asthma with status asthmaticus
 Problems stem from the single hierachy provided by the codes
– Consider the clinically accurate code 8H2P (emergency admission asthma)
29

SNOMED CT - Overview
 SNOMED has a long history dating back more than 40 years
 Comprehensive (multi-lingual) clinical terminology for recording the health
and care of individual patients
– Codes can be indexed and retrieved for use at the clinical point-of-care
– SNOMED codes can also be re-used for management and research
 Latest evolution of the standard (SNOMED CT) was formed in 1999
– Merger of SNOMED with NHS Clinical Terms v3
– Every Read Code and existing SNOMED code is represented
 In 2007 the International Health Terminology Standards Development
Organisation (IHTSDO) acquired the SNOMED IPR
 SNOMED CT is sufficiently complex to only be useful in an IT context
– By January 2009, it contained over 350K active concepts, ~1M descriptions and 1.38M
relationships – the sheer size of the standard is an on-going maintenance issue
30

SNOMED CT – Building Blocks
31
 Building blocks of SNOMED are concepts, descriptions and relationships
– Each concept represents a single specific clinical meaning
– Concepts have a fully specified name (FSN) which may not be the preferred term
 Every concept, relationship and description has an identifier (SCTID)
– SCTID contains the unique identifier, partition identifier and a trailing check digit

SNOMED CT and HL7
 SNOMED CT and HL7 do not always sit easily together
– Not surprising when message structure and terminology have evolved separately
 For example consider the transport of Taurine deficiency
– No pre-coordinated term exists in SNOMED CT for this disorder
 Transmit the data as a post coordinated term in OBX.5:
70241007 | Nutritional deficiency |: 47429007 | Associated with |= 10944007 | Taurine |
 Alternatively use observation sub IDs in HL7 messages:
OBX|1|CE|29308-4|1|70241007^Nutritional deficiency^SCT|...
OBX|2|CE|29308-4|1.1|47429007 ^Associated with^SCT|...
OBX|3|CE|29308-4|1.1.1| 10944007^Taurine^SCT|...
 Impossible to draw a clean dividing line between the two!
– Guidelines exist to provide some clarity – for example use HL7 message structure to
transmit dates, times, people and places - use SNOMED CT for semantic relationships
such as laterality and other post coordinated information
33

LOINC
 Logical Observation Identifiers Names and Codes (LOINC)
– Coding system for medical and laboratory observations
– Relatively new standard (inception dates back to 1994)
– Identified by HL7 as the preferred code set for laboratory test names
 Each test or observation has a unique six digit code containing:
– Component - what is measured, evaluated, or observed (for example, urea)
– Property - characteristics of what is measured, such as length, mass and volume
– Time - interval of time over which the observation or measurement was made
– System - specimen type within which the observation was made (for example, blood)
– Scale - the scale of measure for the measurement or observation
– Method - procedure used to make the measurement or observation
 Observation code and value transmitted in OBX-3 and OBX-5 (ORU)
34

Healthcare Analytics with WebSphere Message Broker

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Healthcare Analytics with WebSphere Message Broker

Ähnlich wie Healthcare Analytics with WebSphere Message Broker (20)

Mehr von Ant Phillips

Mehr von Ant Phillips (7)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Healthcare Analytics with WebSphere Message Broker