Transcript INFO ENGR PPT - University of Connecticut

Informatics and Information Engineering
CSE
5810
Prof. Steven A. Demurjian, Sr.
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-255
Storrs, CT 06269-2155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
Copyright © 2008 by S. Demurjian, Storrs, CT.
Portions of these slides are being used with the permission
of Dr. Ling Lui, Associate Professor,
College of Computing, Georgia Tech.
IIE-1
Overview

CSE
5810

Information Engineering
 Data vs. Information vs. Knowledge
 What is Science? What is Engineering?
 What is Information Consistency?
Information Usage and Repositories
 How do we Store and Utilize Information?
 Sharing, Collaboration, and Security
IIE-2
Information Engineering

CSE
5810


Data vs. Information vs. Knowledge
 How do we Differentiate Between them?
 Where are they used in BMI?
Science vs. Engineering
 What is each of their Roles in Informatics?
 How can we Engineer Information?
 What is their Role in BMI?
What is Information Engineering?
 What are the Unique Challenges and
Opportunities?
 What is Available Today and Tomorrow?
IIE-3
From American Heritage

CSE
5810


Data
 Information, esp. information organized for
analysis or used as the basis for a decision.
 Numerical information in a form suitable for
processing by computer.
Information
 The act of informing or the condition of being
informed; communication of knowledge.
 A non-accidental signal used as an input to a
computer or communications system.
Knowledge
 The state or fact of knowing.
 The sum or range of what has been perceived,
discovered, or learned.
 Specific information about something.
IIE-4
From Webster’s 9th Collegiate

CSE
5810


Data
 Factual information (e.g. statistics) used as a basis
for reasoning, discussion, or calculation.
Information
 The communication of knowledge or intelligence
 Something (as a message, experimental data, or a
picture) which justifies change in a construct (as a
plan or theory) that represents physical or mental
experience or another construct
 quantitative measure of the content of information
Knowledge
 The fact or condition of having information or of
being learned.
 The sum of what is known: the body of truth,
information, and principles acquired by mankind.
IIE-5
Data vs. Information vs. Knowledge

CSE

5810



Overlapping Definitions
Conflicting Definitions
Agreement on Data
Knowledge and Information - Synonyms
Discussion Questions:
 Equivalence of Knowledge/Information?
 How can we Distinguish them?
 Do these Three Terms Cover Possibilities?
IIE-6
Data, Information, and Knowledge in BMI

CSE
5810


Data – Basic Level
 BP, Pulse, Temperature
 Peak Flow, Glucose Level, Biopsy Result
 X-Ray, MRI, Cat Scan
Information - First level of Interpretation
 BPs, Peak Flow, Glucose over Time
 Interpreting Scan (Radiologist) or Biopsy Result
(Oncologist)
Knowledge – Applying Experience towards Diagnosis
 What can Low Peak Flows over Time lead to?
 What Next Step after Positive Scan or Biopsy?
 What if Glucose Level is Yo-yoing?
IIE-7
From American Heritage

CSE
5810

Science
 The observation, identification, description,
experimental investigation, and theoretical
explanation of natural phenomena.
 Methodologoical activity, discipline, or study.
 An activity that appears to require study & method.
 Knowledge, esp. gained through experience.
Engineering
 The application of scientific and mathematical
principles to practical ends such as the design,
construction, and operation of efficient and
economical structures, equipment, and systems.
IIE-8
From Webster’s 9th Collegiate

CSE
5810

Science
 The state of knowing: knowledge as distinguished
from ignorance or misunderstanding
 A department of systemized knowledge as an
object of study
 A system or method reconciling practical ends
with scientific laws.
Engineering
 The application of science and mathematics by
which the properties of matter and the sources of
energy in nature are made useful to people in
structures, machines, products, systems, and
processes.
IIE-9
Science and Engineering in BMI

CSE
5810

Science
 Data/Information Collection & Analysis to Reach
Hypothesis
 Patients with CHF and Lipitor have Less Heart
Attacks than CHF and Baby Aspirin
 Verify in Clinical Research/Epidemiological Study
Engineering
 Usage of Information in Practice
 Apply Scientific Results to Medical Practice
 Image Processing used to Identify Tumors in CT
and MRI Scans
 Transfer of Radiologists Knowledge into
Computer Based (Assisted) Solution
 An Engineering Solution to Scientific Result
IIE-10
What is Information Engineering?

CSE
5810


Incorporation of an Engineering Approach and
Discipline to the Generation of Information and the
Promotion of the Better Use of Information and
Resources Information Engineering Unifies and
Combines:
 Software Engineering
 Database Engineering
 Security Engineering
 Performance Engineering
 Etc...
Moral: Systems Cannot and Must Not be Engineered
in a Vacuum!
Particularly true in BMI (T1, T2, Clinical Research,
and Clinical Practice)
IIE-11
Information Engineering is Motivated by:

CSE
5810


Realization that Management/Control of Information
will be a Primary Concern as we Continue through the
1990s and into the 21st Century
Currently in an Age of Information - Volume and
Complexity Dependencies
Critical Systems Heavily Depend on Information:
 Airline/Hotel/Auto Reservations
 Telecommunications
 Banking/ATMs
 ATM/Credit Cards at Gas Stations/Supermarkets
 Credit Bureaus Electronically Collect Information
from Many Diverse Sources
 E-Tailing
 Medical Care/All Aspects of BMI
IIE-12
Info. Engrg. - Challenge for 21st Century

CSE
5810


Timely and Efficient Utilization of Information
 Significantly Impacts on Productivity
 Supports and Promotes Collaboration for
Competitive Advantage
 Use Information in New and Different Ways
Collection, Synthesis, Analyses of Information
 Better Understanding of Processes, Sales,
Productivity, etc.
 Dissemination of Only Relevant/Significant
Information - Reduce Overload
Implications for BMI?
 Sharing of Results – Benefit Mankind
 Ability to Research on Rare Diseases
 Are there Unknown Isolated “Cures”?
IIE-13
How is Information Engineered?

CSE
5810





Careful Thought to its Definition/Purpose & Thorough
Understanding of its Intended Usage/Potential Impact
Insure and Maintain its Consistency
 Quality, Correctness, and Relevance
Protect and Control its Availability (Secure Access)
 Who can Access What Information in Which
Location and at What Time?
Long-Term Persistent Storage/Recoverability
 Cost, Reusability, Longitudinal, and Cumulative
Experience
Integration of Past, Present and Future Information via
Intranet and Internet Access
What are Implications/Challenges for BMI?
 Let’s Discuss Briefly…
IIE-14
Towards Information Consistency

CSE

5810
Consistency of Information is Key!
Consistency Gauged with respect to:
 Usage of Information
 Persistency of Information
 Integrity/Security of Information
 Allowable Values and Protection from Misuse

Validity (Relevance) of Information
 Means Something to Someone in a Postive Way

Discussion Questions:
 Why is Consistency Important for BMI?
 How is Consistency Attained for BMI?
 What Else Impacts Consistency BMI?
IIE-15
What's Available to Support IE?

CSE
5810

What Can be Provided to Make the Advanced
Application Design Process:
 More Complete?
 More Robust?
 More Responsive?
 Less Error Prone?
Current Choices to Support Information Engineering:
 Conventional Programming Languages and Data
Models
 Object-Oriented Programming Languages
 Object-Oriented DBS
 XML and XML Databases
 Middleware and SOA (Web), Cloud Computing
 Data Mining/Warehouses
IIE-16
What are Key Questions?

CSE
5810

Focus on Information and its Behavior
 What are Different Kinds of Information?
 How is Information Manipulated?
 Is Same Information Stored in Different Ways?
 What are Information Interdependencies?
 Will Information Persist? Long-Term DB?
Versions of Information?
 What Past Info. is Needed from Legacy DBs or
Applications?
 Who Needs Access to What Info. When?
 What Information is Available Across WWW?
All of these Questions Apply to BMI!
IIE-17
Information Usage and Repositories

CSE
5810

How do we Store and Utilize Information?
 Databases
 Data Mining
What are Key Issues?
 Information Sharing/Data Correctness
 Collaboration
1. Among Providers and Researchers
2. Among Providers and Patients
3. Among Patients (Support Groups)

Security
1. Control of Patient Information (De-identified)
2. Secure Exchange/Patient Ownership
3. Establish Custom Patient Controlled Groups

What is the Role of Web in Informatics?
IIE-18
The Role of a Database

CSE
5810






Database is a Norm in Today's and Tomorrow's
Applications
Usage Information Tightly Linked to its Storage
Integration of Database - Key Component
Support Many Representations of ``Same'' Information
Promotes Retrieval of Information Geared Towards
User Needs and Responsibilities
Gap Exists Between Standalone Programming
Applications and Database Systems
For BMI:
 Database (Data Warehouse) is a Key Feature
 Need for Access to Data (De-identified)
 Need to Share and Interact among Stakeholders
IIE-19
DBMS Architecture

CSE
5810
DBMS Languages
 Data Definition Language (DDL)
 Data Manipulation Language (DML)
 From Embedded Queries or DB Commands Within a
Program
 “Stand-alone” Query Language


Host Language:
 DML Specification (e.g., SQL) is Embedded in a
“Host” Programming Language (e.g., Java, C++)
DBMS Interfaces
 Menu-Based Interface
 Graphical Interface
 Forms-Based Interface
 Interface for DBA (DB Administrator)
IIE-20
ANSI/SPARC - Three Schema Architecture

CSE

5810

External Data Schema (Users’ view)
Conceptual Data Schema (Logical Schema)
Internal Data Schema (Physical Schema)
IIE-21
How are these Used for BMI?

CSE
5810


Internal Data Schema (Physical Schema)
 Hidden Data Representation for Storage of BMI
Data in Proprietary Format
 Under the Control of DB System
Conceptual Data Schema (Logical Schema)
 The Data Model for the BMI Application
 Access to Schema Controllable via SQL
External Data Schema (Users’ view)
 Subsets of the Data Model for Different Users
 External View for Patients
 External View for Providers
 Need Ability for a Patient to Control Access to
his/her Own External View
 Aggregate View for Population Researches
IIE-22
Data Independence

CSE
5810


Ability that Allows Application Programs Not Being
Affected by Changes in Irrelevant Parts of the
Conceptual Data Representation, Data Storage
Structure and Data Access Methods
Invisibility (Transparency) of the Details of Entire
Database Organization, Storage Structure and Access
Strategy to the Users
 Both Logical and Physical
Recall Software Engineering Concepts:
 Abstraction the Details of an Application's
Components Can Be Hidden, Providing a Broad
Perspective on the Design
 Representation Independence: Changes Can Be
Made to the Implementation that have No Impact
on the Interface and Its Users
IIE-23
Physical Data Independence

CSE
5810


The Ability to Modify the Physical Data
Representation Without Causing Application
Programs to Be Rewritten
Examples:
 Transparency of the Physical Storage Organization
 Transparency of Physical Access Paths
 Numeric Data Representation and Units
 Character Data Representation
 Data Coding
 Physical Data Structure
All of these are Vital for BMI – Particularly if we Use
Standard to Achieve Application Independence
IIE-24
Physical Data Independence

CSE
5810

Physical Data Independence is a Measure of How
Much the Internal Schema Can Change Without
Affecting the Application Programs
In BMI – Allows us to Plug and Play Different DBMS
Platforms – Extensible and Versatile Integration
Physical
IIE-25
Logical Data Independence

CSE
5810


Transparency of the Entire Database Conceptual
Organization
As a Result:
 Transparency of Logical Access Strategy
 Addition of New Entities
 Removal of Entities
 Virtual (Derived) Data Items
 Union of Records
Views
 Common Mechanism for Logical Data
Dependency
 Provide Different Logical Data Contexts to
Different Users Based on Their Needs
 Update Views vs. Read-Only Views
IIE-26
Logical Data Independence

CSE
5810

Logical Data Independence is a Measure of How
Much the Conceptual Schema Can Change Without
Affecting the Application Programs
For BMI – Allows us to Separate End User
Applications (Patients, Providers, etc.) from DB
Logical
IIE-27
Classic Information System Design
CSE
5810
IIE-28
Data vs. Information
CSE
5810
IIE-29
Programming Language Systems vs. DBS

CSE
5810

Similarities and Differences Exist At System Level:
 Shared Resources vs. Shared Data
 Execution Granularity - Programs vs. Transactions
 Granularity Difference - Files vs. Instances
Classic Problem of “Impedance Mismatch”
 Thin Layer of Overlap between PLS (C++, Java,
etc.) and Relational Database System
 What will Future Bring?
 SQL3 with Object-Oriented Extensions
 XML Databases (Apached Xindice, Sendra, etc.)
Today
Tomorrow?
PLS
PLS
RDBS
XML DBS
IIE-30
What is Today’s Impedance Mismatch?

CSE
5810

Relational Data Organizes Information into Flat Files
 Relational Tables with Primary Key
 High Number of Tuples per Table (1000s & more)
 Limited Number of Tables (10-50) for Even Large
Size Application
 Limited Linkages Among Tables (Foreign Keys)
What Does BMI/PHR/EMR Require?
 For Each Patient, Track Multiple Dependencies
 Visits per Patient
 Tests per Patient
 Prescriptions per Patient


Data Inherently Complex and Interdependent
Flattened into Relational Format
IIE-31
The Health Care Application - Classes
CSE
5810
IIE-32
The Health Care Application - Classes
CSE
5810
IIE-33
The Health Care Application - Classes
CSE
5810
IIE-34
The Health Care Application - Relationships
CSE
5810
IIE-35
How Does Mismatch Occur?

CSE
5810

On Left – OO Classes
 Inheritance
 Dependencies
Programmatic View
 C++ or Java Usage
 Staging from DB to OO
Item(Phy_Name*, Date*,
Visit_Flag, Symptom, Diagnosis, Treatment,
Presc_Flag, Pre_No, Pharm_Name, Medication,
Test_Flag, Test_Code, Spec_No, Status, Tech)

Above – Relational Tables
 Stage Data from Tables into OO (e.g. Java) format
 Utilize JDBC
 What are the Implications/Impacts?
IIE-36
Implications and Impact

CSE
5810

Three Copies of “Same” Information in Different
 Database Table (Item)
 OO Representation – Server Side (Classes)
 GUI Display Client Side (html/xml) Visualization
What can this Lead to?
Dr. D, Jan 01, 08
Fever, Flu, Bed
Rest
No Scripts
No Tests
Item(Phy_Name*, Date*,
Visit_Flag, Symptom, Diagnosis, Treatment,
Presc_Flag, Pre_No, Pharm_Name, Medication,
Test_Flag, Test_Code, Spec_No, Status, Tech)
IIE-37
Information Sharing/Access: Potential Pitfalls

CSE
5810




Another Critical Issue is Information Sharing
 Perception: How do I see/understand Data/Info?
 Differences: What is the Reality?
Dealing with Information at Different Levels
 Syntax – Format of Information
 Semantics – Meaning of Information
 Pragmatics – Usage of Information
When Unifying Databases/Information Repositories,
Must Address all Three!
Data Integrity and Data Security
 Correct and Consistent Values
 Assurance in All Secure Accesses
For BMI – All of the Above are Critical for Correct
Usage and Interpretation in All Contexts (T1, T2, …)
IIE-38
Information Syntactic Considerations

CSE
5810



Syntax is Structure and Format of the Information
That is Needed to Support a Coalition
Incorrect Structure or Format Could Result in Simple
Error Message to Catastrophic Event
For Sharing, Strict Formats Need to be Maintained
Health Care Data Suffers from Lack of Standards
 Standards for Diagnosis (Insurance Industry)
 Emerging Standards Include:
 Health Level 7 (HL7)
 Based on XML

Formats Non-Standard for Different Health
Organizations, Insurers, Pharmacy Networks, etc.
 N*N Translations Prone to Errors!
IIE-39
Information Semantics Concerns

CSE
5810
Semantics (Meaning and Interpretation)
 NATO and US - Different Message Formats
 Distances (Miles vs. Kilometers)
 Grid Coordinates (Mils, Degrees)
 Maps (Grid, True, and Magnetic North)

What Can Happen in Health Care Data?
 Possible to Confuse Dosages of Medications?
 Weight of Patients (Pounds vs. Kilos)?
 Measurement of Vital Signs?
 Dana Farber Chemo Death – Checks/Balances
 What Others are Possible?
IIE-40
Syntactic & Semantic Considerations

CSE

5810





What’s Available to Support Information Sharing?
How do we Insure that Information can be Accurately
and Precisely Exchanged?
How do we Associate Semantics with the Information
to be Exchanged?
What Can we Do to Verify the Syntactic Exchange
and that Semantics are Maintained?
Can Information Exchange Facilitate Federation?
Can this be Handled Dynamically?
Or, Must we Statically Solve Information Sharing in
Advance?
IIE-41
Information Pragmatics Considerations

CSE
5810


Pragmatics Require that we Totally Understand
Information Usage and Information Meaning
 What are the Critical Information Sources?
 How will Information Flow Among Them?
 What Systems Need Access to these Sources?
 How will that Access be Delivered?
 Who (People/Roles) will Need to See What When?
 How will What a Person Sees Impact Other
Sources?
Focus on: Way that Information is Utilized and
Understood in its Specific Context
Can Medical Info be Misused even if Understood?
IIE-42
Information Pragmatics Considerations

CSE
5810

What are Pragmatics Issues re. Underinsured and
Uninsured Populations in Event?
 How Can we Use Info Effectively if we Don’t
Know if it is Complete?
 Has Info from All Sources Been Collected?
 What Happens if Same Patient in Different
Repositories Can’t be Reconciled?
 What if Patient in Unresponsive and Can’t Supply
any Info?
 Is Usage of Info Complicated due to
Incompleteness? Multiple Locations?
Or, if the Event is Major – will all Patient
Populations Suffer Same Substandard Care?
IIE-43
Collaboration and Security

CSE

5810
Two Concepts go Hand in Hand
Strong Parallels
 Collaboration
 Among Providers
 Among Providers and Patients
 Among Patients (Support Groups)

Security
 Control of Patient Information (De-identified)
 Secure Exchange/Patient Ownership
 Establish Custom Patient Controlled Groups


Let’s Explore them Both via our Semester Project
Also Consider Emergent and Policy Issues
IIE-44
Collaboration: Providers and Researchers

CSE
5810


Providers
 Seeking new Treatment Plans
 Looking for Clinical Research Studies for Patients
 Looking to Communicate with Clinical
Researchers
Researchers
 Publish Evidence-Based Guidelines
 New Treatments
 Collect Data on Provider Visits
 Provide Forum to Discuss with Provider
 Allow Provider to Upload Anonymous Outcomes
Also – Need to Collaborate Among Researchers of All
Types (Sharepoint, WIKIs, etc.)
IIE-45
Collaboration: Providers and Patients

CSE
5810
Patients
 Open Personal Health Record to Providers
 Patients have
 Data Entry Facility for Chronic Conditions
 Ability to Graph and Track their Disease
Education Materials also Available
Providers
 Securely Communicate (email) with Patients (see
https://www.relayhealth.com/rh/specific/patients/default.aspx)
 Access to Authorized Patient Data
 Tracking of Patients (to Reduce Office Visits)
 Proactive Intervention to Head off Potential
Hospitalizations/Problems via Treatment
Algorithms to Auto-Notify Based on Data Values


IIE-46
Collaboration: Among Patients

CSE
5810
Patients
 Provide Each with a List of Support Groups
 Allow them to Join Groups or Form New Groups
 Secure Communication via:
 Email
 Chatting Environment
 Link to Actual (Physical Meetings)
Repository of Available Support Groups
Overall:
 Patients can Meet other Patients with Same Issues
 Vital for Patients with Rare Diseases
 Form On-Line Communities


IIE-47
Why is Collaboration Needed?

CSE
5810


Emergent Need for Collaboration in Health Care:
 Patient Centered Medical Home (PCMH)
 Accountable Care Organizations (ACO)
Need Coordination of Care Across Settings
Recent Article Highlights Today’s Problem:
“With every visit to a Boston hospital emergency room,
she would meet an unfamiliar doctor and answer the same
routine questions. Then, she would be whisked to another
room and another doctor, and have to re-explain her situation.”1
1[http://www.boston.com/news/local/massachusetts/articles/2010/09/13/community_clinics_could_be_key_to_new_health_care_system/]
IIE-48
Why is Collaboration Needed?

CSE
5810

Current Situation in Health Care (IOM 2005):

Limited collaboration and coordination among health care
providers.

Limited obligation mechanism to access to medical data and
to collaborate.

Limited obligation mechanism for medical treatment.

Limited temporal requirements for collaboration/
coordination.
Outcome (IOM 2007):

High costs and inefficient patient treatment.

Medical errors and increased adverse drug events.

Redundancy of clinical data and medical actions.
IOM = Institute of Medicine
IIE-49
Why is Collaboration Needed?

CSE
5810 

Physician-Pharmacist Collaboration in the Management of
Patients With Diabetes Resistant to Usual Care [Ramser, 2008]
Team-Based Care With a Pharmacist Linked to Better Blood
Pressure Control [Barclay, 2009]
Physician and Pharmacist Collaboration to Improve Blood
Pressure Control [Carter, 2009]
The objective of each study was to evaluate if a collaborative model in
community-based medical offices could improve the quality of patient
treatment. The outcome was positive in each study.
50
IIE-50
Dimensions of Collaboration in PCMH
CSE
5810
Coordinated
Collaboration
Obligated
Collaboration
Team-based
Collaboration
Collaboration
Requirements in
Health Care
Adaptable/Dynamic
Collaboration
Secure
Collaboration
1. How can we leverage software engineering strategies and
existing models in order to address all five requirements?
2. How can we define a model that integrates all requirements?
IIE-51
Dimensions of Collaboration in Health Care
CSE
5810
Public Health
Department
Patients’ privacy preserving via restricted
access to the virtual chart.
Active collaboration via obligated and
timely access to the virtual chart.
Local EMR
Access to the virtual patient chart
via Health Information Exchange (HIE).
Blood
Tests
X Ray
Results
Social
History
Scan
Results
Health
History
Med.
History
Coordinated collaboration via inter/intra
workflow collaboration graph.
Virtual Patient Chart
Hospital
Centers for
Disease Control
Medical collaboration role teams:
1.Technician Role
2.Specialist Role
3.Physician Role
4.Nurse Role
5.ER Nurse
6.ER Physician
7.Patient Role
8.Office Staff Role
Legend
Coordinated Collaboration in Health Care.
IIE-52
Example Collaboration
CSE
5810
IIE-53
Security: General Concepts

CSE
5810


Authentication
 Proving you are who you are
 Signing a Message
 Is the Client who S/he Says they are?
Authorization
 Granting/Denying Access
 Revoking Access
 Does the Client have Permission to do what S/he
Wants?
Encryption
 Establishing Communications Such that No One
but Receiver will Get the Content of the Message
 Symmetric Encryption
 Public Key Encryption
IIE-54
Key Security Issues

CSE
5810



Legal and Ethical Issues
 Information that Must be Protected
 Information that Must be Accessible
Policy Issues
 Who Can See What Information When?
 Applications Limits w.r.t. Data vs. Users?
System Level Enforcement
 What is Provided by the DBMS? Programming
Language? OS? Application?
 How Do All of the Pieces Interact?
Multiple Security Levels/Organizational Enforcement
 Mapping Security to Organizational Hierarchy
 Protecting Information in Organization
IIE-55
What are Key Access Control Concepts?

CSE
5810

Assurance
 Are the Security Privileges for Each User
Adequate to Support their Activities?
 Do the Security Privileges for Each User Meet but
Not Exceed their Capabilities?
Consistency
 Are the Defined Security Privileges for Each User
Internally Consistent?
 Least-Privilege Principle: Just Enough Access

Are the Defined Security Privileges for Related
Users Globally Consistent?
 Mutual-Exclusion: Read for Some-Write for Others
IIE-56
Available Security Approaches

CSE
5810


Mandatory Access Control (MAC)
 Bell/Lapadula Security Model
 Security Classification Levels for Data Items
 Access Based on Security Clearance of User
Role Based Access Control (RBAC)
 Govern Access to Information based on Role
 Users can Play Different Roles at Different Times
Responsibilities of Users Guiding Factor
 Facilitate User Interactions while Simultaneously
Protecting Sensitive Data
Discretionary Access Control (DAC)
 Richer Set of Access Modes - Govern Access to
Information based on User Id
 Discretionary Rules on Access Privileges
 Focused on Application Needs/Requirements
IIE-57
Mandatory Security Mechanism

CSE
5810

Typical Security Classification Levels for
Subjects/programs and Objects/resources
 Top Secret (TS) and Secret (S)
 Confidential (C) and Unclassified (U)
Rules:
 TS is the Highest and U is the Lowest Level
 TS > S > C > U
 Security Levels:





C1 is Security Clearance Given to User U1
C2 is Security Classification Given to Object O1
U1 can Access O1 iff C1  C2
This is Referred to as the Domination of U1 Over O1
Not Prevalent in BMI – But May have Relevance
IIE-58
Role Based Access Control (RBAC)

CSE
5810

Focuses on Defining Roles of Typical Behavior
 Nurse, Nurse-Manager, Education-RN
 Physician, Attending-MD, Specialist
 Student, Faculty-Advisor, Head
 Focus on Duties that are Shared
During Authorization of Roles to Users
 Establish Boundaries of Access
 User Steve with Role Faculty-Advisor
 Limited to Faculty Capabilities on Peoplesoft
 Only Can Manipulate His Advisees

User Steve with Role Associate Head
 Possible Overlap in Responsibilities w/ Faculty-Advisor
 Other Activities not given to Faculty-Advisor Role
IIE-59
Why is RBAC Needed?

CSE
5810


In Health Care, different professionals (e.g., Nurses
vs. Physicians vs. Administrators, etc.) Require Select
Access to Sensitive Patient Data
Suppose we have a Patient Access Client
 Lois playing the Nurse Role would be Allowed to
Enter Patient History, Record Vital Signs, etc.
 Steve playing M.D. Role would be Allowed to do
all of a Nurse plus Write Orders, Enter Scripts, etc.
 Vicky playing Admin Role would be Allowed to
Enter Demographic/Insurance Info.
Role Dictates Client Behavior
 Physician’s Write Scripts
 Nurses Enter Patient Data (Vitals + History)
 All Access Shared Medical Record
 Access is Limited Based on Role
IIE-60
Discretionary Access Control

CSE
5810



Discretionary
 Grant Privileges to Users, Including Capabilities to
Access Specific Data Items in a Specific Mode
 Available in Most Commercial DBMSs
Aspects of DAC
 User’s Identity
 Predefined Discretionary “Rules” Defined by the
Security Administrator
 Allows User to “Delegate” Capabilities to Another
User
 Delegate Capabilities and Ability to Delegate
Role Delegation and Delegation Authority
DAC Available in SQL2
IIE-61
What is Role Delegation?

CSE
5810


Role Delegation, a User-to-User Relationship, Allows
an Original User (OU) to Transfer Responsibility for a
Particular Role to a Delegated User (DU)
Two Major Types of Delegation
 Administratively-directed Delegation has an
Administrative Infrastructure Outside the Direct
Control of a User Mediates Delegation
 User-directed Delegation has an User (Playing a
Role) Determining If and When to Delegate a Role
to Another User
In Both, Security Administrators Still Oversee Who
Can Do What When w.r.t. Delegation
IIE-62
Why is Role Delegation Important?

CSE
5810
Many Different Scenarios Under Which Privileges
May Want to be Passed to Other Individuals
 Large organizations often require delegation to
meet demands on individuals in specific roles for
certain periods of time
 True in Many Different Sectors
 Health Care and Financial Services
 Engineering and Academic Setting

Example:
 Reda Delegates Head Role to Steve when Traveling

Key Issues:
 Who Controls Delegation to Whom?
 How are Delegation Requirements Enforced?
IIE-63
Coalitions for Clinical/Translational Science
CSE
5810
Pfizer
Bayer
UConn
Storrs
UConn
Health
Center Saint
DCF,
Francis,
DSS, etc.
CCMC, …
Info. Sharing - Joint R&D
Support T1, T2, and Clinical Research
Company and University Partnerships
Collaborative Funding Opportunities
Cohesive and Trusted Environment
Existing Systems/Databases
and New Applications
How do you Protect Commercial Interests?
Promote Research Advancement?
Free Read for Some Data/Limited for Other?
Commercialization vs. Intellectual Property?
NIH
FDA
NSF
Balancing Cooperation with Propriety
IIE-64
Emergent Public Policy Issues

CSE
5810

How do we Protect a Person’s DNA?
 Who Owns a Person’s DNA?
 Who Can Profit from Person’s DNA?
 Can Person’s DNA be Used to Deny Insurance?
Employment? Etc.
 How do you Define Security Limitations/Access?
What about i2b2 – Informatics for Integrating Biology
and the Bedside (see https://www.i2b2.org/)
 Scalable Informatics Framework to Bridge
 Clinical Research Data
 Vast Data Banks for Basic Science Research

Goal: Understand Genetic Bases of Diseases
IIE-65
Emergent Public Policy Issues

CSE
5810
Can DNA Repositories be Anonymously Available for
Medical Research?
 Do Societal Needs Trump Individual Rights?
 Can DNA be Made Available Anonymously for
Medical Research?
 De-identified Data Repositories
 Privacy Protecting Data Mining
International Repository Might Allow Medical
Researchers Access to Large Enough Data Set for
Rare Conditions (e.g., Orphan Drug Act)
Individual Rights vs. Medical Advances


IIE-66
Concluding Remarks

CSE
5810


We’ve looked at:
 Informatics
 Information Engineering
 Information Usage and Repositories
Focused on Their Applicability and Relevance for
BMI
Likely Generated More Questions than Answers
IIE-67