Download Incorporating Data Mining Applications into Clinical Guidelines

Interoperability of Data and
Knowledge in Healthcare
Systems
A CAS-747 presentation by:
Reza Sherafat
[email protected]
March 28, 2006
Dept. Computing and Software
McMaster University
CAS 747: Software Architecture and Reverse Engineering
Agenda








Current trends in Healthcare
Clinical decision support systems
Data Interoperability problem
Data mining results as the source of knowledge
Knowledge interoperability
Integration of data mining results with clinical
guidelines (plus some case studies)
Conclusion
References
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Current trends in Healthcare

The Healthcare professionals are overwhelmed with information.

Preventable medical errors cause thousands of deaths each year
and loss of billions of dollars.

Healthcare information systems are deployed for various
purposes, telemedicine, patient care, Electronic Health Records
and decision support.

A good start by many standards organizations to define and
maintain healthcare standards.
 HL-7 (most popular healthcare data standard)
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Clinical decision support systems (CDSS)

Effectiveness of clinical decision support systems (a question to
be answered)

Even a recommendation system should NOT to flood the
practitioner with so many [irrelevant] cases and also should NOT
ignore possible important cases.

Many different approaches to provide decision making support.

We focus on guideline-based CDSS that try to support “clinical
best practices” at the point of care decision making.
 Arden Syntax by HL-7
 Guideline Interchange Format (GLIF)
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Arden Syntax

The idea behind Arden Syntax is to have a simple, yet powerful enough
procedural language that can encode the necessary logic for deciding
upon a single problem.

Decision making knowledge is encoded as IF-THEN rules in separate
Medical Logic Modules (MLM).

Each module is responsible for making a single decision and is run on
an engine that can access the EHR systems. Based on the result of
evaluation of the rules an action (an alert or reminder) is taken.

A library of modules

Modules have data sections that should be mapped to institution
specific data repositories; the rest of the module is already ready to
use.
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Arden Syntax (Cont’d)
knowledge:
type:
data_driven;;
data:
last_creat := read last {"Creatinine level"};
last_BUN := read last {"BUN level"};
;;
evoke: ct_contrast_order;;
logic:
if last_creat is null and last_BUN is null then
alert_text := "No recent serum creatinine available. Consider
patient's kidney function before ordering contrast studies.";
conclude true;
elseif last_creat > 1.5 or last_BUN > 30 then
alert_text := "Consider impaired kidney function when
ordering contrast studies for this patient." ;
conclude true;
else conclude false;
endif;
;;
action:
write alert_text || "\nLast creatinine: "||last_creat||" on: "||time of
last_creat|| "\nLast BUN: "||last_BUN||" on: "||time of last_BUN ;
;;
urgency: 50;;
end:
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Guideline Interchange Format (GLIF)

Three different types are models are mentioned:
A guidelines specification standard
1. Guideline Models
2. Data models

Flowchart-like
diagrams (Guideline Models)
3. Data mining models

3 levels of abstraction [3] :



Conceptual modeling
Computable level
Implementation details
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Conceptual Modeling (Level 1)

The conceptual models have
simple building elements (steps):
 action step,
 patient state step,
 decision step,
 branch step and
 synchronization step

It is easy to build and understand models

Some steps may involve user interaction,
access to a data source or triggering
an event.
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Second and third levels in GLIF

Computable level deals with encoding the
decision making logic (expressions)

Implementation level is concerned with how
to map and bind the variable to local
(institution specific) medical records.
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Data Interoperability
The semantics of the communication
The semantics convey the actual "meaning" of the message. The
semantics is conveyed via a set of symbols contained within the
communication. An external "dictionary", thesaurus, or terminology
A syntax for communication
explains the meaning of the symbols as they occur.
The syntax defines the structure and layout of the communication. Common
syntax representations include ASN.1, XML, X.12, HL7, IDL, etc.
Services to accomplish the communication
Examples include the post office, a telephone switchboard, SMTP, FTP, Telnet,
RPC, ORB services, etc.
A channel to carry the communication
Examples of channels include written documents, telephones, network connections,
satellite links, etc.
Source: [7]
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Data Interoperability (Cont’d)

Three different types are models are mentioned:
THE KEY IDEA: Through standardization
1. Guideline Models

2. Data
HL-7
has models
built a standard Reference Information
3. Data
mining models
Model
(RIM)

RIM is in the form of a large class diagram that
model the healthcare domain.

Some other XML based standards like Clinical
Document Architecture (CDA) use RIM as their main
data model.
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Data Interoperability (Cont’d)
RIM
Stakeholder_identifier
id : ST
identifier_type_cd : ID
Service_intent_or_order
0..*
filler_order_id : IID
has_as_participant filler_txt : TX
is_entered_at
order_id
0..1 order_placed_dttm : DTM
order_quantitytiming_qt : TQ
placer_order_id : IID
placer_txt : TX
is_an_instance_of
has_as_target
report_results_to_phone : XTN
0..*
intent_or_order_cd : ID
0..1
participates_in
Active_participation
participation_type_cd : ID 0..*
0..*
is_assigned_to
is_assigned
1
0..1
Stakeholder participates_in
addr : XAD
1
phon : XTN
collects
Stake holder
Organization
organization_name_type_cd : CNE
organization_nm : ST
1 standard_industry_class_cd
0..*
Organization
takes_on_role_of
0..*
has_as_participant
0..*
is_collected_by
Person
birth_dttm : DTM
gender_cd : CNE
marital_status_cd : CNE
is_a_subdivision_of primary_name_representation_cd : CNE
0..1
primary_name_type_cd : CNE
has_as_a_subdivision
primary_prsnm : PN
race_cd : CNE
Person
0..*
participates_in
Collected_specimen_sample
body_site_cd : CE
collection_end_dttm : DTM
collection_start_dttm : DTM
collection_volume_amt : CQ
handling_cd : ID
id : IID
method_of_collection_desc : TX
specimen_additive_txt : ST
specimen_danger_cd : ID
specimen_source_cd : CE
0..*
is_sourced_from
is_source_for
0..1
0..1
is_fulfilled_by
Observation_intent_or_order
patient_hazard_code
reason_for_study_cd
relevant_clinical_information_txt
reporting_priority_cd
specimen_action_cd
0..1
Services
has_as_active_participant
is_target_of
is_target_of
0..1
1
takes_on_role_of
Patient
1..*
fulfills
0..*
delivers
0..1
Service_event
has_as_target
0..*
service_desc : ST
0..*
Tar get_par ticipation
is_instantiated_as
0..1 ambulatory_status_cd
service_event_desc
0..*
birth_order_number
has_as_targetparticipation_type_cd : CE
specimen_received_dttm
:
DTM
is_delivered_during
Healthcare_service_provider
is_a_role_ofliving_arrangement_cd 0..1
1
1
is_target_of
name : CE
specialty_cd : CNE
Master_service
living_dependency_cd
0..*
0..*
is_target_of
multiple_birth_ind
method_cd : CE
has_as_target
is_performed_at
newborn_baby_ind
method_desc : TX
has_a_primary_providerorgan_donor_ind
service_desc : TX
Assessm ent
preferred_pharmacy_id
target_anatomic_site_cd : CE
0..*
universal_service_id : CE
is_the_primary_provider_for
is_a_role_of
is_a_role_of
0..*
0..1
0..1
0..1
has_as_primary_facility
Individual_healthcare_practitioner
Healthcare_provider_organization
Clinical_observation
desc : TX
abnormal_result_ind : ID
practitioner_type_cd
:
CNE
1..*
last_observed_normal_values_dttm : DTM
nature_of_abnormal_testing_cd : CE
is_primary_facility_for
clinically_relevant_begin_dttm : DTM
0..1
clinically_relevant_end_dttm : DTM
provides_patient_services_at
Master_patient_service_location 0..1 is_target_for
0..*
0
..*
provides_services_on_behalf_of
observation_value_txt : NM
addr : XAD
probability_number : NM
0..1
email_address
:
XTN
references_range_text : ST
0..*
id : ID
value_units_code : CE
is_location_for
is_included_in
nm : ST
phon : XTN
is_entry_location_for
1
takes_on_role_of
has_as_target
0..*
Patient
Clinical
Observation
includes 0..1
CAS 747: Software Architecture and Reverse 1Engineering
Winter 2006
Data mining results as the source of
knowledge

Three different types are models are mentioned:
Data mining research has been active in
1. Guideline Models
building models that can describe or predict.
2. Data models
3. Data mining models

Applications of data mining studies:





Likelihood of coincidence of particular diseases
Adverse drug usage
Diagnosis
Patient clustering based on risk factors
Verification of known medical knowledge
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Knowledge interoperability

THE KEY IDEA: Through standards

Use standards for knowledge sharing and exchange

The mined knowledge should be incorporated into
the guideline model to be used for decision making
at the decision steps.

PMML: data mining knowledge is encoded using the PMML
standard.

GLIF3: Medical knowledge is encoded in guideline models
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Framework for interoperability of mined
knowledge
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Framework for interoperability of mined
knowledge (Cont’d)

Three phases:

Knowledge preparation


Interoperation


Mining the patients data
To make both data and mined knowledge available at
the point of care through use of standard
Interpretation

Access the knowledge base with the patient data that
needs decision making
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Integration of data mining results with
clinical guidelines
Guideline Execution
Guideline modeling
Knowledge Extraction
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Integration of data mining results with
clinical guidelines (Cont’d)











Knowledge extraction
Building data mining models on [usually] large data warehouses
Guideline modeling
Building guideline models
PMML encoding
Institution specific data bounding
Guideline Execution
Execution engine will follow the flow defined in the guideline
model
Accessing patient data from EMR systems
Interact with the healthcare personnel
Alert, recommend or remind
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Integration of data mining results with
clinical guidelines (Cont’d)
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Implementation

Extending Guideline Interchange Format3 (GLIF3)
constructs


Guideline Execution Environment (GEE)


To support the new functionality needed for the data mining
models
To execute the guideline models, and access/interpret the
data mining models
Provision of the mined knowledge as webservices
when the knowledge base is not available locally

Very helpful for small devices; e.g. handheld computers
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Case study


A decision tree classifier
For melanoma skin cancer diagnosis [6]
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Case study (Cont’d)
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Guideline Execution Environment
The guideline execution environment widget
Guideline selection
list
Different flows within a
guideline in execution
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Guideline’s Meta Model
Data mining decision nodes
as an ontology class
Data mining decision nodes
slots
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Guideline modeling
Slot widget to
specify the new
attributes of a
data mining
decision node
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Conclusion

We described:




A knowledge management framework to for data
mining results;
The environment in which the framework can be
deployed;
How to integrate data mining results in clinical
guidelines;
How knowledge interoperability is achieved.
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
References
Incorporating Data Mining Applications into Clinical Guidelines, R.
1.
Sherafat, K. Sartipi, The 19th IEEE International Symposium on ComputerBased Medical Systems, 2006
2.
Data and Knowledge Interoperability in Distributed Healthcare Systems, R.
Sherafat, K. Sartipi, The 13th Annual International Workshop on Software
Technology and Engineering Practice, 2005
3.
Guideline Interchange Format 3 (GLIF3), www.glif.org
4.
Health Level-7 (HL-7), www.hl7.org
5.
Arden Syntax, http://hl7.org/library/standards_non1.htm#Arden%20Syntax
6.
Data Management Group (DMG), www.dmg.org
7.
Rules for melanoma skin cancer diagnosis,
http://www.phys.uni.torun.pl/publications/kmk/
8.
Version 3 Intermediate Tutorial - Working the HL7 Version 3 Methodology,
George W. Beeler, http://hl7.org/library/datamodel/V3_Tutorials/V3_Intermediate_May00.ppt
CAS 747: Software Architecture and Reverse Engineering
Winter 2006
Questions
?
CAS 747: Software Architecture and Reverse Engineering
Winter 2006