Rule Based Inference Model for Exchange of Medical

Rule Based Inference Model for Exchange of MedicalInformation in Context of Pakistan’s Medical Laws

Ph.D Thesis

By

Imran Khan62-FBAS/PHDCS/F10

Supervisor

Prof. Dr. Muahmmad Sher

Co-Supervisor

Prof. Dr. Javed Iqbal KhanChairman, DCS, Kent State University, Ohio, USA

Department of Computer Science & Software EngineeringInternational Islamic University, Islamabad

April 2017

A dissertation submitted to theDepartment of Computer Science & Software Engineering,

International Islamic University, Islamabadas a partial fulfillment of the requirements

for the award of the degree ofDoctor of Philosophy in Computer Science.

Imran Khan: 62-FBAS/PHDCS/F10 Page i of 121

Department of Computer Science & Software EngineeringInternational Islamic University Islamabad

Date: April 20, 2017

Final ApprovalIt is certified that we have examined the thesis report submitted by Mr. Imran Khan, RegistrationNo. 62-FBAS/PhD(CS)/F10, and it is our judgment that this thesis is of sufficient standard to war-rant its acceptance by the International Islamic University, Islamabad for the Doctor of Philosophyin Computer Science.

Committee:

External Examiners

Dr. Sikandar Hayat KhiyalProfessorFaculty of Computer SciencePreston University Islamabad

Dr. Arif-ur-RehmanAssistant ProfessorDepartment of Computer ScienceBahria University, Islamabad

Internal Examiner

Dr. Husnain Abbas NaqviAssistant ProfessorDepartment of Computer Science & Software EngineeringInternational Islamic University Islamabad

Supervisor

Dr. Muhammad SherProfessorDepartment of Computer Science & Software EngineeringInternational Islamic University Islamabad

Co-Supervisor

Dr. Javed Iqbal KhanProfessor/ChairmanDepartment of Computer ScienceKent State University, Kent Ohio, USA

Imran Khan: 62-FBAS/PHDCS/F10 Page ii of 121

Declaration

I hereby declare that this thesis, neither as a whole nor any part thereof has been copied out fromany source. It is further declared that no portion of the work presented in this report has beensubmitted in support of any application for any other degree or qualification of this or any otheruniversity or institute of learning.

Imran Khan

Imran Khan: 62-FBAS/PHDCS/F10 Page iii of 121

Dedication

This thesis is dedicated to my family, especially to my father, my mother, my wife and especiallyto my sons Muhammad Ibrahim, Muhammad Ismail and my daughter Hadia Khan.

Imran Khan

Imran Khan: 62-FBAS/PHDCS/F10 Page iv of 121

AcknowledgmentsThis thesis and all my efforts are fruitful only due to ALLAH Almighty, the Most Merciful andBeneficent, Who gave me strength to complete this task to the best of my abilities and knowledge.

I would like to thank my supervisor Prof. Dr. Muhammad Sher and Co-Supervisor Dr. Javed Iqbal

Khan, who gave all their knowledge, guidance and support to boost my confidence and learning. Iwould also like to thank my wife who has supported me patiently and firmly during completion ofmy task.

I would also like to acknowledge my brothers, friends, students and colleagues especially Mr. Syed

Muhammad Saqlain, Dr. Syed Husnain Abbas Naqvi, Mr. Anwar Ghani, Mr. Muhammad Usman

Ashraf, Mr. Shehzad Ashraf Ch., Mr. Muhammad Khaliq, Mr. Tawab Khan, Mr. Atif Shabbir,

Mr. Jawwad Shakir, Mr. Eid-ur-Rehman and Mr. Zahid Mahmood. All of them encouraged andprovided logistic and technical help during this research.

I would like to admit that I owe all my achievements to my truly, sincere and most loving parentsand friends who mean the most to me, and whose prayers have always been a source of determina-tion for me.

Imran Khan: 62-FBAS/PHDCS/F10 Page v of 121

Abstract

National Health Information Exchange (NHIX) is a rapidly evolving cyber-infrastructure techno-logy. The concept enables the sharing of electronic healthcare-related data within a geographic re-gion. Information can be exchanged between autonomous healthcare related entities such as phy-sicians, hospitals, test laboratories, insurers, emerging Health Information Organizations (HIO).Non-healthcare organizations can also become privy to such information, including governmentsand non-governmental authorities.

During a human being’s lifetime, a person may visit numerous doctors, hospitals, and medicalfacilities. From birth through adulthood, the information trail from these visits can be usefulboth to the individual and in the aggregate. If the information from each visits can be collectedand made easily available and organized, it can be used to improve the quality of healthcare. Infact, data organized properly can be lifesaving. Many duplicate tests can be avoided. Doctorsmay make more informed medical decisions and prescribe more accurate treatments with betterinformation. The right data in the right context can allow an individual to better monitor theirown health. A good nationwide medical information system can go above and beyond what iscommonly termed “big data” information derived from a long term database containing a largenumber of individuals can be used for better capacity planning, minimizing the overall cost ofhealthcare for an entire country. It can be a treasure trove of data for analysis and discovery ofdisease trends and treatments.

An infrastructure to contain and manage medical information is therefore vital for the well-beingof any country in the twenty-first century. Unfortunately, much of the world still utilizes nineteenthcentury medical documentation practices. Personal medical information is often poorly recordedand eventually lost due to a lack of appropriate information technology. We propose a national ini-tiative to produce a cyber-infrastructure for the secure and private exchange of healthcare informa-tion (hospital records, MRI images, medical history, insurance information, pathological reports,etc.) among the nations healthcare industry stakeholders, and also throughout the world (with allindividual rights, privacy rules and regulations in proper standard formats of medical documents).

The goal of this research is to explore a National Health Information Exchange (NHIX) for Pakistanand for developing countries in general. However, due to the enormity of this problem, we inparticular propose to demonstrate a concept application, Medical Drop Box (MDB) with the keytechnological components of a future NHIX. With MDB, a person will be able to collect his/herhealthcare data and share it with doctors in a seamless way, in conformance with a regulatory

Imran Khan: 62-FBAS/PHDCS/F10 Page vi of 121

framework. In addition to providing the basic infrastructure for handling numerous types of healthcare data, the main challenge of NHIX is to allow individuals and associated parties to manageand share their medical information while maintaining personal control and preferences affordedto citizens by medical laws, information rights and privacy rules.

The development of a comprehensive National Health Information Exchange (NHIX) is paramount.The research propose such a framework for Pakistan that will allow all medical entities (hospital,insurance, employers, doctors, labs, individual themselves, emergency rooms, and perhaps futurehome monitoring systems) to be involved in treating a person during their lifetime and to exchangeinformation efficiently without violating the individual’s privacy concerns. This will dramaticallyimprove the healthcare rights of every citizen of Pakistan.

Imran Khan: 62-FBAS/PHDCS/F10 Page vii of 121

Contents

List of Figures xi

List of Tables xiii

1 Introduction 11.1 Objectives and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Literature Review 72.1 Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 HIPAA Privacy Rules Formalization 163.0.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.0.2 Overview of Our Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Synthesis of HIPAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.2 Two Pass Modeling of HIPAA . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Request/Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Comparison of Formalization Approaches . . . . . . . . . . . . . . . . . . . . . . 233.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Complexity Reduction Through Actor Based Approach 274.0.1 Actors in HIPAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

viii

Contents

4.1 Request Flow Procedure in HIPAA . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1.1 Rules in HIPAA Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.2 Referenced and Unreferenced Rules for an Actor . . . . . . . . . . . . . . 34

4.2 Complexity of HIPAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.1 Time complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Rules Filtration through HIPAA World Rules Model . . . . . . . . . . . . . . . . . 384.3.1 Time Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.2 Complexity Comparison of Actor base Approach . . . . . . . . . . . . . . 384.3.3 Actor Based Queries Example . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Legal Text to Logical Rules using Medical Relational Model 425.1 System Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.1 Concept Space of HIPAA . . . . . . . . . . . . . . . . . . . . . . . . . . 445.1.2 Tags Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.3 Rule Set Formation from HIPAA . . . . . . . . . . . . . . . . . . . . . . . 465.1.4 HIPAA Rules Filtration through World Rule Model (WRM) . . . . . . . . 47

5.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.1 Rule Set for Researcher from HIPAA . . . . . . . . . . . . . . . . . . . . 505.2.2 Query and Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6 Construction of Clinical Documents using HL7 556.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1.1 Security Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.1.2 Medical Rules in MDB with Example . . . . . . . . . . . . . . . . . . . . 586.1.3 Individual Preferences in MDB . . . . . . . . . . . . . . . . . . . . . . . 626.1.4 Decisions Functions in MDB . . . . . . . . . . . . . . . . . . . . . . . . . 626.1.5 Clinical Document with HL7 Standard in MDB . . . . . . . . . . . . . . . 62

6.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7 Medical Drop Box (MDB): For Exchange of Medical Data 68

Imran Khan: 62-FBAS/PHDCS/F10 Page ix of 121

Contents

7.1 Material and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.1.1 Individual Preferences in MDB . . . . . . . . . . . . . . . . . . . . . . . 717.1.2 MDB Deployment and Dynamic Architecture . . . . . . . . . . . . . . . . 717.1.3 MDB Security Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.1.4 Clinical Document Generation in MDB . . . . . . . . . . . . . . . . . . . 737.1.5 Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.4 Potential Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8 Medical Law Engine (MLE) for Privacy and Access Control 808.1 System Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.1.1 Mathematical Model for Rules Extraction . . . . . . . . . . . . . . . . . . 828.1.2 Request Processing through MLE . . . . . . . . . . . . . . . . . . . . . . 87

8.2 Algorithm’s Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 918.2.1 Decoding Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.2.2 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.2.3 Part-of-Speech Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.2.4 Tagging of Unknown Words . . . . . . . . . . . . . . . . . . . . . . . . . 928.2.5 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.3 MLE Deployment with Medical Application . . . . . . . . . . . . . . . . . . . . . 948.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9 Conclusions and Future Directions 979.1 Potential Impact of Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Appendix A Decision Tree Data, A Clinical Document and Logical Rules Samples 100A.1 Decision Tree and Rules Flow: Examples . . . . . . . . . . . . . . . . . . . . . . 100A.2 A Clinical Document Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106A.3 Snapshots of Medical Drop Box Application . . . . . . . . . . . . . . . . . . . . . 111A.4 Samples of Logical Rules for Medical Entities . . . . . . . . . . . . . . . . . . . . 113

Bibliography 115

Imran Khan: 62-FBAS/PHDCS/F10 Page x of 121

List of Figures

1.1 Human life cycle with medical treatments data overview . . . . . . . . . . . . . . 2

2.1 Overview of translation activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Production Rule Modeling Methodology Overview . . . . . . . . . . . . . . . . . 102.3 Concept diagram of upper-level directory structure . . . . . . . . . . . . . . . . . 112.4 Flow chart of legal text formalization . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Overview of HIPAA Formalization Process . . . . . . . . . . . . . . . . . . . . . 183.2 HIPPA Decision Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Request Flow process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Details of Processing of Record . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 HTAG Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Information flow in the healthcare system . . . . . . . . . . . . . . . . . . . . . . 294.2 Actor base rules information flow . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Request flow for verification with HIPAA rules . . . . . . . . . . . . . . . . . . . 324.4 Evaluation of Requests between different sections . . . . . . . . . . . . . . . . . . 344.5 Filtering Rules based on Requester through HIPAA World Formalization Model . . 404.6 Rules Generated for Researcher . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Concept Classes Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 Medical Relational Model (MRM) . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3 World Rule Model using MRM for Decision Support System . . . . . . . . . . . . 475.4 XML Rules Filtering Algorithm Model . . . . . . . . . . . . . . . . . . . . . . . 485.5 Generated Rules for Researcher . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.6 Researcher Query Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.7 Patients Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

xi

List of Figures

5.8 Output result of the query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1 Medical Drop Box Conceptual Design . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Request Parsing and Medical Data Processing Algorithm Flow for Request . . . . 586.3 Medical Rules Extraction Algorithm for Medical Entities . . . . . . . . . . . . . . 596.4 No. of Doctor’s Registration in Different Cities Yearly . . . . . . . . . . . . . . . 646.5 No. of Patient’s Registration in Different Cities Yearly . . . . . . . . . . . . . . . 656.6 No. of Medicine Used by Patients in Different Cities Yearly . . . . . . . . . . . . 656.7 Top Ten Doctor’s, Medicines and Diseases in Pakistan . . . . . . . . . . . . . . . 66

7.1 Medical Drop Box Conceptual Design . . . . . . . . . . . . . . . . . . . . . . . . 707.2 NHIX Application Access with Medical Drop . . . . . . . . . . . . . . . . . . . . 717.3 NHIX Deployment with Medical Drop . . . . . . . . . . . . . . . . . . . . . . . . 727.4 No. of Doctor’s Registration and Patient’s visits Yearly . . . . . . . . . . . . . . . 757.5 No. of Patient’s and Doctor’s Registration in Different Cities Yearly . . . . . . . . 767.6 Most Common Diseases and Medicine in Pakistan . . . . . . . . . . . . . . . . . . 76

8.1 HIPAA rule with class representation . . . . . . . . . . . . . . . . . . . . . . . . . 818.2 HIPAA (WRM) Rules Filtering Process Model with Law Engine Component . . . 828.3 Medical Rules Extraction and Request Processing Algorithm Model . . . . . . . . 878.4 Access Levels from Action Class in XML Logical Rules . . . . . . . . . . . . . . 898.5 Request Processing for Researcher with MLE Model . . . . . . . . . . . . . . . . 908.6 Open and Close Vocabulary Test for Algorithms 4 & 5 . . . . . . . . . . . . . . . 938.7 Medical Law Engine Deployment Design . . . . . . . . . . . . . . . . . . . . . . 94

A.1 Medical Drop Box View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111A.2 Clinical Document Representation in Medical Drop Box for Patient’s Data . . . . . 112A.3 Hospital logical rules generated by MLE . . . . . . . . . . . . . . . . . . . . . . . 113A.4 User logical rules Information with privacy preferences . . . . . . . . . . . . . . . 114A.5 Lab logical rules generated by MLE . . . . . . . . . . . . . . . . . . . . . . . . . 114

Imran Khan: 62-FBAS/PHDCS/F10 Page xii of 121

List of Tables

4.1 Actors in HIPAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 No. of Rules in HIPAA Privacy Section 164.502 to 164.534 . . . . . . . . . . . . . 33

5.1 HIPAA- Comparison of Result with other Approaches . . . . . . . . . . . . . . . . 53

8.1 Sample of AccessLevel (AL) Dictionary . . . . . . . . . . . . . . . . . . . . . . . 838.2 Details of Tags Representation with example . . . . . . . . . . . . . . . . . . . . . 848.3 A comparison between De-identifiable and Limited Data . . . . . . . . . . . . . . 89

xiii

Acronyms

CCD Continuity of Care Document.

CCR Continuity Care Record.

CDA Clinical Document Architecture.

CTL Computation Tree Logic.

DDT Disambiguated Decision Tree.

EHR Electronic Health Record.

EMR Electronic Medical Records.

ERAM Entity Relationship Action Model.

ERA Entity Relation Action.

HHS Health and Human Services.

HIPAA Health Information Portability Accountability Act.

HIS Health Information System.

HIT Health Information Technology.

HIX Health Information Exchange.

HL7 Health Level 7.

HoIS Hospitals Information System.

MDB Medical Drop Box.

MDSS Medical Decision Support System.

xiv

Acronyms

MLE Medical Law Engine.

MRM Medical Relational Model.

NHIN National Health Information Network.

NHIX National Health Information Exchange.

PHI Protected Health Information.

POS Part-Of-Speech.

VPN Virtual Private Network.

WRM World Rule Model.

Imran Khan: 62-FBAS/PHDCS/F10 Page xv of 121

Acronyms

List of Publications

1. Published Article(s)

(a) Khan, I., Sher M, Aslam S, Saqlain SM, Ashraf MU, Khan JI, Rauf M, Ghani A. Medi-cal drop box (MDB); A national health information exchange and management systemfor medical industry. Professional Med J 2016;23(4):489-498. DOI: 10.17957/TP-MJ/16.3279

(b) Khan, I., Chaudhry, S. A., Sher, M., Khan, J. I., Khan, M. K. An anonymous and pro-vably secure biometric-based authentication scheme using chaotic maps for accessingmedical drop box data. The Journal of Supercomputing, (2016) 1-19.

(c) Khan, I., Sher, M., Khan, J. I., Saqlain, S. M., Ghani, A., Naqvi, H. A., & Ashraf,M. U. “Conversion of Legal Text to a Logical Rules Set from Medical Law Using theMedical Relational Model and the World Rule Model for a Medical Decision SupportSystem”. In Informatics (Vol. 3, No. 1, p. 2), 2016.

(d) I. Khan, M. Sher, J. I. Khan, S. M. Saqlain, A. Ghani, M. U. Ashraf, Clinical docu-ment construction using HL7 with medical drop box for exchange of electronic healthrecords under country medical law, International Journal of Computer Science and In-formation Security 14 (10) (2016) 559576

(e) I. Khan, M. Sher, S. M. Saqlain, H. A. Naqvi, A. Ghani, M. U. Ashraf, J. I. Khan,Role-based efcient information extraction using rule-based decision tree, InternationalJournal of Advanced and Applied Sciences 4 (1) (2017) 7483.

2. Conference publication(s)

(a) Khan, I., Alwarsh, M., Khan, J.I. A comprehension approach for formalizing privacyrules of HIPAA for decision support. In Proceedings of the 12th International Confe-rence on Machine Learning and Applications (ICMLA), Miami, FL, USA, 47 Decem-ber 2013; Volume 2, pp. 390395.

3. Technical Report(s)

(a) Khan, I., Alwarsh, M., & Khan, J. I. A Comprehension Approach for FormalizingLegal Text: A Decision Tree Model Approach for Privacy Rules of HIPAA. media-net.kent.edu

Imran Khan: 62-FBAS/PHDCS/F10 Page xvi of 121

Acronyms

(b) Khan, I., Alwarsh, M., & Khan, J. I. Quantitative Charting of HIPAA Section 164sLegal Universe Privacy Rules of HIPAA. medianet.kent.edu

Imran Khan: 62-FBAS/PHDCS/F10 Page xvii of 121

Chapter 1

Introduction

A modern healthcare system is highly important for the well-being of any country, and especiallyso for Pakistan. Unfortunately, the mainstream of the healthcare industry in Pakistan is working ata sub-optimal level. Use of a Health Information System (HIS) even at the individual hospital/in-stitution level, is nearly non-existent [1]. There is a great need to improve the current system withInformation Technology.

Organized information can radically improve healthcare just as much as the discovery of a newdrug or the invention of a new operational procedure. In the course of the human life cycle, ifcollected properly, the size of the medical and healthcare data related to even one individual canbe humongous, often reaching gigabytes. This volume of information can provide extraordinaryinsight in planning the correct treatment. Ones medical information begins even before a personis born. In developed countries, when a baby is born, its information is stored in the HospitalsInformation System (HoIS). The volume of information grows as the baby grows and keeps ongrowing until the individual’s death. The individual faces various illnesses, hospital visits, doctor’sappointments, undergoes different treatments, takes various laboratory tests, undergoes proceduresand takes medicines to cure or manage disease. All of these activities and many others generatea wealth of information. An individual’s health data remains useful even after their death forhis/her close relatives. While it may not become obvious from family stories that a condition isinherited, the medical data can make the connection clear. Various hospitals in developed countriesare already recording and archiving patient information in their HoIS. However, when we considerthe millions of patients and hundreds of thousands of healthcare providers, the task of archiving,integrating and constructing intelligent and and meaningful use of this data is formidable. Figure

1

Chapter 1. Introduction

Medical Servicesprovider

Birth / Baby

Child

Teenager

Adult

Old Age

Death

Doctor V

isitEmergency

Medical Test

Hospital A

dmit

Lab

Repo

rt

Immunizatio

nDeath Report. . . .

. . .

.

. . .

.

. . . .

. . . .

. . .Treatm

ents in life

data

data

data

data

data

data

data

data

datadata

Figure 1.1: Human life cycle with medical treatments data overview

1.1 shows the whole cycle.

One of the first problems faced by a HoIS is a lack of standardization in the type and format ofhealth related data. Health Level 7 (HL7) is an international organization which has taken on theresponsibility for developing the standards governing the exchange of variety of electronic healthinformation [2].

However, there are substantial complexities from multiple angles. A healthcare system invol-ves numerous types of entities ranging from patients, physicians, hospitals, insurers, employers,regulators and researchers. Because these people all have different perspectives and needs, theframework (by standards, protocols and information architecture) must be constructed to allow in-formation exchange. A full-fledged framework addresses many issues such as ease of exchange,privacy of the individual, timeliness of treatment, data access and delivery, availability, portabilityand security issues. Since Pakistan is at an infancy stage in this proposal, our particular focus is onan experimental framework focusing on the exchange of individual identifiable information whichis the most critical type of information for improving the quality of treatment from an individual’spoint of view. Healthcare information is also one of the most sensitive types of information to

Imran Khan: 62-FBAS/PHDCS/F10 Page 2 of 121


exchange because of the rights, risks, and responsibilities associated with it.

In Pakistan there exists a medical law for the protection of medical information. This law providesa complete code of ethics. It also empowers the patients with rights regarding their health care andinformation exchange for purposes like medical research, patient treatment and health managementservices [3, 4]. “The Medical and Dental Council Ordinance XXXII” started in 1962 to providethe basics rights and guidance to the health care industry in Pakistan. In 2012 and 2013 there weresome amendments [3, 5]. There is also an act called “Health Management Service Rule 2008”for the management of health services [6]. Some other laws related to the health industry existin the constitutions of Pakistan, but those acts are outside of our scope for the health informationprotection and privacy management [7, 8].

Because now-a days people travels in different part of the world more frequently ever before, thedemand for medical data exchange between different countries is becoming much greater. Accor-ding to some statistics, about 348 million people visited the China in 2009, including 43.73 millionforeigners [9]. As large numbers of people travel abroad they sometimes need to visit a hospital.In such cases, doctors in the hospitals may need to have access to the previous history of the pa-tient to form proper treatment plans. To facilitate this process, clinical data must be exchangedinternationally [10]. In this way, the integrity and permanence of patients’ health information canbe maintained [11].

The above discussions help us understand how much importance has been given to healthcare in-formation exchange by developed countries and how complex it is. The benefits are limitless. Asfor the point of view of a doctor, availability of comprehensive clinical information can tremen-dously raise the scientific quality of diagnosis and treatment. Clinical data analytic and researchcan lead to new discoveries benefiting us all on a larger scale. Providers can use healthcare dataanalytics and do research to learn about patient populations, enhance preventive care, and makedecisions by accessing key data such as demographics and chronic conditions. A nationwide com-prehensive exchange infrastructure would improve the quality of the overall health care system andreduce waste.

In Pakistan, like many other developing countries, there is a great awareness of the need to moder-nize their healthcare system, though there is as of yet no concerted plan like can be found in theUS. Hardly any of the major healthcare facilities in Pakistan, particularly in government sectors,has a HIS in place. In the absence of any required standards and rules framework, there are only afew sporadic efforts to develop a local HIS in a few private institutions. But without the portability



standards, these systems are not going to be interoperable and will not serve patient’s long terminterest.

The development of a comprehensive National Health Information Exchange (NHIX) is paramount.The research proposed such a framework for Pakistan that allow all entities (hospital, insurance,employers, doctors, labs, individual themselves, emergency rooms, and perhaps future home moni-toring systems) to be involved in treating a person during their lifetime and to exchange informationefficiently without violating the individual’s privacy concerns. This will dramatically improve thehealthcare rights of every citizen of Pakistan. In the era of globalization, when most of the deve-loped countries are building such an infrastructure, it is also important that the citizens of Pakistanto be able to connect to the world’s medical infrastructure.

1.1 Objectives and Scope

A. Design of Pakistan’s Medical Health Framework for Exchange of Information One of themost exciting tasks of this research was to outline the first medical information sharing frameworkfor Pakistan. This will be used to chart the patient rights, define key actors, and establish the pro-cess flow required for proper release of personally identifiable healthcare information in the contextof Pakistan’s healthcare system. This may seem like a daunting task. We expect this componenton its merits, which should be the landmark in the modernization of Pakistan’s healthcare system.

B. Design of NHIX International Peering Framework Identifying the issues (international trade,privacy and other rules) involved in the electronic exchange of individually identifiable medical in-formation for a patient between Health Care Entity. It will open up new opportunities to interactwith other National Health Information Network (NHIN) systems for cross-border medical infor-mation sharing. This component will be new for health care industry as well as potentially openingus up to a new international exchange of medical services.

C. Design of Medical Drop Box Based on the two frameworks developed above, we have thencreated a prototype application called Medical Drop Box (MDB) . MDB uses a drag-and-dropinterface and covers all the key functions such as access, transmission, security, privacy, inter-portability, documents viewing, documents conversion and standardization. Internally, the MDB

implemented Continuity of Care Document (CCD) technology (conformant to HL7 Clinical Do-cument Architecture (CDA) release 2.0 also known as ISO/HL7 27932:2009).



D. Conceptual Framework of HIX Pakistan The broader goal of the research is to pave the roadtowards a high performance national health information exchange cyber infrastructure for Pakistanwith interoperability between the different countries and Pakistan NHIX or NHIN opening up ameans of a more peaceful healthcare cooperation between the countries.

1.2 Contributions

The main emphasis of the thesis was to establish a medical framework that follows the medicallaws of the country to manage the privacy issues of individuals. The contributions of the thesis are(1) Formalization of Legal Text, (2)Standardized Clinical Document generation, (3) Medical DropBox Application for the generation of Clinical Documents by following the HL7 standards and (4)Exchange of Medical Data among medical entities, observing all patients privacy rules. A lot ofbenefits will be taken after fully implementing the application in the medical industry.

• One of the first health frameworks for Pakistan will identify the issues and process flowrequirements for automated exchange of electronic health care records in the context ofPakistan.

• It will also identify issues, requirements and process flow level solutions and suggest a noveltechnology so medical information can flow electronically between World NHIX and a futurePAK-NHIX.

• The technology will be demonstrated with an implementation of Medical Drop Box- (a per-sonal scale implementation of NHIX) including a Mobile App which will allow an individualto receive, store, port, and share personal medical information and records (HL7/CCD com-pliant) without any paper instantaneously and reliably, even through a mobile phone.

• In the long run we expect this will put Pakistan’s healthcare system in a confident footingtowards its modernization worthy of the twenty first century

Since there are not established laws to protect privacy of medical entities in Pakistan, the HealthInsurance Portability and Accountability Acts (HIPAA) is used as the basis for testing and verifyingresults. HIPAA was started in 1996 by the United States government to provide comprehensiveguidance to the healthcare industry. The act protects and restricts the ways in which medicalentities can use medical information in accordance to their defined laws [12, 13]. This researchthesis only focused on the privacy issues in HIPAA.



1.3 Thesis Organization

The rest of the thesis is organized into 8 chapters as follows:

• Chapter 2 explains the state of the art literature available for formalization of logical rulesfrom legal text, medical document standardization and exchange of medical data amongmedical entities. It also discuss about the open issues found in literature and contains theproblem statement defined for this thesis.

• Chapter 3 explains the formalizations of HIPAA privacy rules. It explains the HIPAA EntityRelationship Action Model (ERAM) that captures and precisely defines the semantics of theHIPAA domain and framework that is used in formalization process.

• Chapter 4 explains the Actors involved in Medical Industry. As rules are made about handingof information, the process can be simplified, if used the Actor based approach.

• Chapter 5 discusses about the conversion of legal text to logical rules using Medical Relati-onal Model and World Rule Model.

• Chapter 6 discusses the Clinical Document generation using Medical Drop Box in the lightof HL7 standards for medical data defined in Clinical Document Architecture (CDA).

• Chapter 7 explains about the Medical Drop Box(MDB) architecture, functions, deploymentin Medical Industry and Medical data management.

• Chapter 8 is devoted to developing a Medical Law Engine (MLE) for the Medical Industry.MLE is used to control the access and privacy on medical data during exchange of medicalinformation according to medical law of that country.


Chapter 2

Literature Review

Conversion to logical rules set from legal text document remains an important and difficult task[14]due to the complex structure of legal text document. The legal text document consists of differentsections, subsections, clauses, sub clauses and sub of sub clauses. So it’s a complex job for soft-ware engineer who do not understand the exact meaning of these clauses, and has been given thetask of building a Medical Decision Support System (MDSS), which supports the exchange of pri-vate health information according to the medical law of that country. But it will make it easier forthe software engineer to design and build the MDSS if we provide him with a logical rules set.Informatics assisted compliance verification with laws and regulations are however highly challen-ging [15, 16]. Legal drafts often contain ambiguities and have incomplete contingencies. There arefrequent cross-references to different subsections of the same or other sections [17]. Also, thereare implied cross referenced meanings of its provisions associated with the intent of the law, pos-sibly conflicting definitions and domain-specific terminology [18]. Implementation of laws alsogets refined gradually as various provisions are tested in contests and courts provide case specificclarifications [19]. In addition, laws and regulations undergo updates and amendments that wouldrequire the software engineer to manage and track these changes [20].

So, the first step in building the MDSS is to formalize the medical law into logical rules. Theselogical rules can further be used for taking decisions to release or denial of certain medical re-cords in compliance with law, when requested by any entity of the medical system. The users ofthe medical system are almost the same all over the world: doctors, nurses, hospitals, labs, andresearchers. But the medical laws for those entities may differ from country to country.

Healthcare information is one of the most sensitive types of information to exchange where sensiti-

7

Chapter 2. Literature Review

vity arises from the rights, risks, and responsibilities associated with it [11]. The U.S. Departmentof Health and Human Services (HHS) in 1996 created the Health Insurance Portability and Accoun-tability Acts HIPAA as a means of providing a mechanism to protect broad civil rights includingprivacy of medical information [21, 22]. Failure to conform to the HIPAA Act may result in a fineof up to $25,000 per year and 1 to 5 years imprisonment [23]. HIPAA Administrative Simplifi-cation, Regulation Text: 45 CFR Parts 160, 162, and 164 specifically regulate the disclosure ofpersonal health information [13].

The complexity of HIPAA, combined with potentially stiff penalties for violators, has lead physi-cians and hospitals to withhold information from those who may have a right to it [24]. A reviewof the implementation of the HIPAA privacy rules by the U.S. Government Accountability Of-fice found that health care providers worry “ about their legal privacy responsibilities and oftenresponded with an overly guarded approach to disclosing information than necessary to ensurecompliance with the privacy rules” [25].

Several studies proposed solutions to formalize HIPAA legal text into some form of logic rule set.In the last decades, general attempts have been made to convert legal text into logic rules [1, 26].More recently there is renewed interest to tackle HIPAA.

Lam et al. [27] examined sections of HIPAA and investigated if a Datalog like stratified first ordersystem of logic can be instituted to verify compliance of medical information release request mes-sages sent by providers. In the process of interpreting the legal text they also observed extensive“conflicts” as well as “anomalies” regarding lack of regulation in HIPAA. They proposed a strati-fied Datalog with limited use of negation technique for ensuring termination and efficiency. Theirproposed mechanism combines associated rules in the form of “permitted by” and “forbidden by”where the later has precedence for making a decision. In the cases of perceived ambiguity the sy-stem has been biased where prohibition takes precedence over permission. The resolution processseems flawed, as the use of negation seems to inject additional semantics not explicit in HIPAA.We found that this method doesn’t produce precise results in all cases.

DeYoung et al. [28] presented the concept of positive and negative norms to take a decision. Thefirst means a transmission that might occur, where the second means a transition that must occur.All negative norms must be satisfied to release protected health information but precision of thissolution is not accurate because we found cases that contradict this theory.

Maxwell and Anton [29] use a production rule model to verify HIPAA compliance. They haveclassified rules to four types: rights, obligations, permissions and definition. The problem with this



Figure 2.1: Overview of translation activities

approach is its deficiencies in resolving overlapping conditions between two obligations shown infigure 2.1.

Massey et al. [19] focus on software requirements for the compliance checking and validating withlaw using their production rule model for HIPAA. For that purpose they applied their approachwith iTrust Medical Record System for HIPAA Compliance. They adopt a three step approach forsoftware requirements for regulatory compliance. These steps are as follows:

• Map Terminology. Map with requirements document terminology to the regulation termino-logy they used in their production rule model.

• Precondition Identification Sets. Sets of Preconditions for queries are identified and thengrouped.

• Requirement Analysis. Identify conflicts; find the gaps in requirements concerns.

There is a problem in their model because it does not fully focus on the legal rules types that theyused for their production rule model.

Maxwell and Anton [20] refined the production rule model according to the software requirementfor compliance checking and they introduced or added some new categories of concepts to modelthe law, using the legal concepts of rights, obligations, privileges, no-rights, powers, liabilities,immunities, and disabilities shown in figure 2.2. The problem is still there as the authors said theapproach does not cover verifying the cross-references, and they check manually all those crossreferenced areas.

Takemura et al. [30] verified by testing and provide a mechanism for local EHR systems to integratemedical data across multiple regions. They have constructed a super site using an upper-leveldirectory structure with data mapping functions for the purposes of matching patient IDs from



Figure 2.2: Production Rule Modeling Methodology Overview

different regions, and of compatibility between different data structures shown in figure 2.3.

Tello-Leal et al. [31] presents a methodology based on a Model-Driven Architecture that followsa top-down approach for integrating healthcare services through cross-organizational processes.The methodology provides a modeling language and designs cross organizational process models.These models are used for the automatic generation of private view of processes and each or-ganization should perform to fulfill its role in cross organizational processes. Colored Petri Netspecifications are to implement these processes.

Lang et al. [32] introduced a method based on Computation Tree Logic (CTL) which were providedto obtain formal legal text. It can formalize legal texts and reason automatically. In this approachshown in figure 2.4, they did three scan to finish the formalization: the first one is to distinguishstructures inside sections; the second is to extract the slot-key-words between sentences based onword-joint judgment; the last scan is to merge and remove duplicates.

Hashmi [33] introduced the methodology to extract legal norms and requirements from legal docu-ments. Using a natural “IF...THEN” structure to analyze the contents of a legal document, actions,types of obligations and the effects on interactions amongst those actions were extracted. Afterstructuring they can then be used for compliance checking. O. Neill [34] presented the Gover-nance, Risk and Compliance (GRC) framework only for improving the governance capabilities



Figure 2.3: Concept diagram of upper-level directory structure

Figure 2.4: Flow chart of legal text formalization



and compliance results among organizations for data privacy risk. Alshugran and Dichter [35, 36]also introduced access modeling techniques for extracting the privacy requirements from HIPAAin order for it to be used in medical applications. But due to the limitations in those modelingtechniques the authors reviewed their rules extraction model [37] for expressing the HIPAA rulesin a service oriented architecture in order for it to become a web service.

There are numerous varieties and formats of healthcare data. Health Level 7 (HL7) has taken theresponsibility [38] for developing the standards for the variety in electronic health information.The “7” with the HL7 refers to the Layer 7 in the OSI reference model. HL7 standards addresshow myriad forms of healthcare related information, including messaging data exchange, decisionsupport, rules syntax, visual integration of applications, insurance claims, clinical documents suchas discharge summaries, product labels for prescription medication, etc. are defined and interchan-ged [39]. HL7 version 2 started with the aim of defining schemes for the interchange of recordsinside a hospital. HL Version 3.0 now aims at all aspects of health care data exchange [40, 41].

The Continuity Care Record (CCR) is another standard initiative to create the electronic summaryof patient health [42]. Its purpose is to improve the quality of healthcare by reducing medical errorsand ensuring that a patient’s full information profile is available to physicians. It’s a snapshot oftheir critical health data which can be potentially lifesaving, if available, at the time of clinicalencounter. It has been designed to permit easy creation by a physician using an Electronic HealthRecord (EHR) system at the end of an encounter. Another similar standard is the Continuityof Care Document (CCD), a con-formant to HL7/Clinical Document Architecture (CDA release2.0) also known as ISO/HL7 27932:2009. CCD uses XML-based markup standard intended tospecify the encoding, structure, and semantics of clinical documents for machine exchange [11,43]. Therefore, the patient’s summary information can also be shared by all computer applications,including web browsers, Electronic Medical Records (EMR) and EHR software systems.

In the United States Health Information Technology (HIT) is also under development [44–46].It’s the initiative and foundation for theNational Health Information Network which will createa National Health Information Exchange (NHIX) System for the United States [46, 47]. HealthInformation Exchange (HIX) System is the main goal to achieve for the transmission of healthcareinformation electronically among different organizations within a region, community or hospitalsystem [48]. The US HITECH provides funds to establish a national healthcare IT setup, wherepatient’s data is to be fired across a national health information highway [10, 12, 49].

The development of HIPAA came from the results of long research, testing and analysis efforts



and now serves as the guiding framework for the orderly exchange of healthcare information inthe US. However, not all covered entities (US hospitals) comply with the HIPAA due to a lack ofknowledge of its privacy rules. For example, an individual might want to access his previous labresults. He should be able get the results from the hospital, as it is part of his Protected HealthInformation (PHI). The hospital however, out of fear of violating the HIPAA privacy rules, refusesto release the records. The computerization of records at all levels in hospitals, clinics and othermedical institutes will be the progress in Electronic Medical Records (EMR) to create medicalInformation system.[30]. In order to improve compliance to the HIPAA and similar frameworksand laws in other countries, it is important that additional universal healthcare applications aredeveloped to solve the gap between the covered entities/hospitals knowledge and the actual policiesand laws.

Hospitals and Clinics [30] now involves in computerization of Electronic Medical Records (EMR)to create a complete medical information system. Mostly in the developed countries, differentkinds of projects have been carried out worldwide for this purpose. For example, the US, Canadaand England have invested at least 1.6 billion U.S. dollars and 20 billion U.S. dollars [50] respecti-vely. The United States alone will invest 20 billion U.S. dollars for switching from manual toelectronic medical documents. For EHR, a number of projects have been carried out in Japan aswell [30].

However, people in modern society are extremely active. They travel to different geographicalregions frequently. In the US alone, 35 million people change their residence each year, and inJapan an average a person moves five times in his or her life [51].

The demand for medical data exchange among different countries is increasing at an alarming rate.As large numbers of people travel abroad, they sometimes need to visit hospitals. In such cases,doctors may need to access the history of the patient for proper treatment. To facilitate this pro-cess, clinical data must be exchanged internationally [10, 52]. Because of this, all countries haveMedical Laws in some form. In most Western countries, healthcare frameworks are used to ensurethat health information is protected for privacy and confidentiality but is available when needed.Healthcare service providers must comply with these guidelines to ensure orderly exchange ofinformation that satisfies every ones concerns and needs.

A wealth of research had been produced in the field of software engineering over the past years[53]. To ensure that the exchange of healthcare information amongst medical entities complieswith the law, significant efforts have been made to research and develop privacy enhancing software



engineering tools [54]. Currently there are four different perspectives are covered in these privacyenhancing tools: (i) Privacy in compliance with the law, (ii) Privacy in Access Control, (iii) Privacyin Verification and (iv) Privacy from Usability Point of View.

2.1 Open Issues

There are a number of research issues in this research area. The first issue is ensuring to be ableto formalize the legal text into automated rule sets for the compliance checking with the law. Ifwe are able to formalize legal text properly, that means the automation of medical law will helpus implement and document according to medical law. This will help to exchange health relatedinformation between different actors/stakeholders according to law. Then the big research issue isto exchange medical information at the national level between different health-related stakeholderslike hospitals, clinics, medical laboratories, medical researchers, government agencies and medicalinstitutions. Other research issues in this area are the portability of medical documents, availability,secure data-flow, authentications of stakeholders, privacy management, patients preferences, dataand document standardization and enforcing policies and rules according to medical law for thedocument and decision generations to share information.

2.2 Problem Statement

We investigated three interesting problems of a NHIX. First, was the automatic verification ofprivacy and regulatory requirements. In the USA and other developed countries, there exists acomplete Act (HIPAA) for the health industry. Can it be automated to verify conformance andprocess flow guidance for every electronic transaction? It is a research challenge to formalize thelegal text into a machine processable form (logical rule set) that will work for compliance checking.This is a novel problem and we will address this. Our main task in this is how to formalize thelegal text into logical rules for the compliance checking, and to conform the rules that are to beused for further exchange of medical information according to the act of Pakistan. We will outlinea possible way to set the ground for Pakistan’s NHIX.

The second component was the advancing the NHIX network itself. A group of participating agentsprototyped for select medical providers will participate in a rule-based federated authentication and



credential scheme to meet the legally conformant medical information exchange in a NHIX likeframework.

The third component was the implementation of portal standards for the NHIX Medical Drop Boxaccording to HL7 and HIT standards, so the information can be exchanged between the healthservice providers and health related industry stakeholders at the national and international level.

The drop box is a small scale exploration focused on one individual’s information. However, thesethree elements will provide a critical road-map on how to build a healthcare application coveringthe necessities of the healthcare industry in Pakistan, allowing them to communicate clinical datainternally as well as exchange of medical information with other parts of the world.

2.3 Proposed Solution

The goal of the research was to seed a National Health Information Exchange for Pakistan. Howe-ver, as we have stated, the challenges are multifaceted and are extremely complex. In this proposal,we have suggested and implemented a small scale experimental system called Medical Drop Box.This was a personal scale testbed for the national scale NHIX. The box can be envisioned as aportable folder which will enable any person in Pakistan to carry all of his/her electronic medicalinformation and share it with his/her medical service provider. The beauty of this experiment isthat it will enable us, the researchers, to look into some of the most critical elements needed forPakistan NHIX from the perspective of a patient.

In an effort to advance health care privacy and exchange of protected health information, we pro-posed a road map of how we could formalize the legal rules of the Pakistan Medical Act “PakistanMedical and Dental Council Code of Ethics” into logical rules in order to facilitate the implemen-tation of exchanging protected health information between different stakeholders. The first part ofthis process requires human pre-processing of legal text where the second part requires computerbased processing.


Chapter 3

HIPAA Privacy Rules Formalization

Computer assisted intelligent verification based on the Portability and Accountability Act (HI-PAA) compliance can greatly improve the efficiency of US healthcare systems. Today HIPAAcompliance checks requires experts with deep familiarity with its intricate provisions to verifycompliance. Often, compliance is managed by grossly simplified administrative work flows forset cases. Unfortunately, these practices are not scalable. They sheer scale of electronic transacti-ons calls for increased automation. However, informatics assisted legal compliance verificationremains fundamentally challenging. Legal drafts often contains ambiguities and have incompletecontingencies. There are also frequent and implied cross-references to sections of the same or dif-ferent legal texts. Also there are implied cross-references to provisions associated with the intentof the law. Domain specific terminologies and the existence of conflicting definitions are inherentissues associated with any practical legal draft [18]. In addition, laws and regulations undergo up-dates, new interpretations and amendments that would require software engineers to manage andtrack these changes. The complexity of the legal texts often make it very difficult for practitionersto determine whether they are in compliance or not [25]. Out of fear of heavy penalty, the practiceis to resort to few preset cases which are often overly restrictive, rather than to the actual HIPAA[55]. Often practitioners require patients to sign-off (and waive) broader rights than required fortheir treatment, essentially defeating the very purpose of HIPAA.

16

Chapter 3. HIPAA Privacy Rules Formalization

3.0.1 Challenges

Notably a common aspect of most of these early experiments is that all derive the rule set fromclause-by-clause translation of the legal text into corresponding logical expressions. The expec-tation is to drive the resolution process from one sentence to another and find the connectionsbetween constraints defined in various parts of the act by dint of shared predicating connections.In one sense, it is remarkable, without the explicit comprehension of the overall HIPAA how muchsuccess such approaches claim to have achieved. However, the approaches demonstrate brittle-ness in the sense that, in some cases, they produce inaccurate results and get quickly clogged byapparent ambiguities. Indeed, to resolve the conflict approaches perhaps some form of forced pre-ference/precedence meta rules could be induced, not necessarily as part of HIPAA. But one mustlook carefully to discover if many of these ambiguities are real or artifacts of the rule set generationprocess. Indeed, for several cases of “conflict” cited, a human expert can yet connect the contextand may not see these cases as a conflict. Yet, another major drawback of these early approachesis that the HIPAA act includes many other notions beyond just allow/deny actions. Indeed, a largepart of the HIPAA text specifies various processes to be followed for legally meaningful confor-mance. These process notions are not accounted for at all in these early explorations. Legal expertseven may take a view that the exact semantics of actions specified such as “forbidden”, “permit-ted”, “positive norm”, “negative norm” are manufactured and in the absence of process work flowelements referenced in actual HIPAA may not be aligned with the HIPAA semantics in any legallystrict sense.

3.0.2 Overview of Our Approach

In this research we have undertaken an alternate approach. Unlike others we have constructed anHIPAA Entity Relationship Action (ERAM) Model that captures and precisely defines the seman-tics of the HIPAA domain, which we call HIPAA World. On this foundation we proceed to convertthe corpus of legal texts into a set of logical constraints and required actions. These rules are thenintegrated into a Disambiguated Decision Tree (DDT) precisely identifying the allowed and pres-cribed actions. Given any EMR query the DDT then enables one not only to verify the compliancemore precisely but also to extract complete release guidance as prescribed by HIPAA, and evengenerates coherent explanation and audit.

To demonstrate the approach, we have modeled the provision space of section 164 of HIPAA [56]



Logical Rule Set

TRANSPONDER

Explanation(List of Rules

Executed)

Decision

SepecialInstruction (How

to Release)

Privacy Rulesof HIPAA Act

Legal Text

Concept Class Generation Process

ReqT

TFT

PRI

CT

AT IPT

PPT

Human Based Process

Computer BasedProcess

Req

uest

Query

List ofDeliverables

(What to Release)

Audit(Steps of Rules

Trigers)

ActionTaken

Informationand RecordProcedure Complaince Checking

ID SSN DOB AGE

PatientsMedical Data

RRT

ER

D

Figure 3.1: Overview of HIPAA Formalization Process

which covers most of the security and privacy related standards for exchanging PHI. It consistsof 683 non repeated clauses and we covered all clauses starting from 164.502 up to 164.530,according to HIPAA Administrative 45 CFR [57]. We present the overall process of extraction andverification with specific examples.

3.1 Synthesis of HIPAA

3.1.1 Framework

It is important to note that the HIPAA is more than a yes or no decision. The top box in Figure 3.1shows the rule set extraction process. These rules are deeply integrated with the work flow invol-ved EMR transaction scenarios (bottom box). We propose a modular approach which is based onwork flow categorized on the requester class. Each class is handled by the work flow transponder.An administrative request originates from the requester. It includes but is not limited to, identity,



purpose, specifications of information requested and a set of associated credentials (such as autho-rization, waiver, etc.). The transponder runs the resolution process as per the HIPAA rule subsetconnected to the case. Besides verification of conformance of a request, HIPAA and real editsalso generates items: namely (i) a list of deliverable (patients PHI, fees, time to fulfill a requestetc.), (ii) special instructions (format choices raw record, summary, etc.), special processing (likede-identification required) as specified in HIPAA, (iii) an explanation identifying rules triggeredand (iv) audit specifying who, when, and what has been requested, created, released, etc. In thissample we only focus on the first item the generation of the decision. The system pre-resolvesthe semantic long connections, and thus generates much precise resolutions. Given an EMR tran-saction request thus the decision trees more precisely resolves it. Also, the resulting system canmuch better articulate other intents of HIPAA, such as specifying how to release a particular pieceof information; if denied, what are the alternate options; generate logically coherent explanationssupporting the decisions conformance to the original expectations of HIPAA.

3.1.2 Two Pass Modeling of HIPAA

By analyzing HIPAA text [57], we have first developed an Entity Relation Action (ERA) model ofthe HIPAA world. The world has ten fundamental entity classes respectively Requester (ReqT ∗),Covered Entity (CE∗), Purpose (PPT ∗), Patient Record Item (PRI∗), Condition (CT ∗), Action(AT ∗), Information Procedure (IPT ∗), Record Release (RRT ∗), Time Schedule (TT ∗) and FeeSchedule (FT ∗). Consider clause 164.506.c.1 (1):

“A covered entity may use or disclose protected health information for its own treatment, payment,

or health care operations”.

This clause 164.506.c.1 (1) text has reference to a requester (i.e. “covered entity”), three purposes(i.e. “treatment”, “payment” and “health care operations”), one condition (“disclose only if thePHI is used by self”), all patient record items and two action items (i.e. “use” and “disclose”).Figure 3.5 compiles the entities (called HTAG) extracted by semantic analysis of section 164 ofHIPAA pertaining to this paper. The entities are then assimilated into an ERA model.

Next a second pass is made to identify the constraints on actions imposed by the edicts. Thisis a more complex process. Experts normally have the ability to interpret and analyze complexscenarios to provide a decision for denying or disclosing the use of PHI by full knowledge of thework flow semantics. No single clause can be taken verbatim and be used directly in at its face



value without the context. For illustration purposes, we focus on the portion of the HIPAA edictsspecific to the use of PHI by researchers.

Covered clauses were selected from section 164.508, 164.512, 164.514 and 164.532. Figure 3.2shows the rules that are applicable for Requester=researcher, Purpose=research, and PRI=*. Forcomputational efficiency the verification of the tests (trial) is however implemented as a decisiontree with a sequence of smaller tests organized in an optimized order. The full decision tree isfurther disambiguated so that all combinations of test results are guaranteed to lead to a definitiveverdict. We call it disambiguated decision tree (DDT). The third column shows the verdict cor-responding to the test set for each rule. Each rule, also has procedures or orders attached (forthcolumn). A prescribed order provides how, what and when (a time frame) information should bereleased along with the rights (if one can appeal) and responsibilities (such as the need to pay) ofboth the CE and the requester. Note that, even if the verdict is “deny” a denial document still needsto be released explaining the reason for denial, etc.

The HIPAA edit related to release of PRI to researchers is encoded into four logical rules definedon the HTAGs as shown in Figure 3.2. The rule set of this table is one possible aggregate of all theconditions related requester, purpose and PRI. Collected conditions are evaluated with the providedinformation by the requester.

Rule 1 indicates that if there is no waiver from CE or authorization presented by the requester,thi swill lead to denial of request (AT1). However, the requester is informed about these requirementsin the information release procedure phase. Rule 2 shows a typical example where all the requiredconditions to disclose PHI are satisfied. As a result, a release decision (AT4) is issued and PHI isevaluated for what to release (RRT1, RRT2) and how to release IPT1∧IPT2∧IPT3∧IPT4” theinformation. Rule 3 indicates that the researcher didn’t provide consent (CT12) to the CE whichprevents him from disclosing PHI. Rule 4 is an example of a researcher who wants to conductresearch about decedents and hasn’t provided enough information (CT9) which will affect theverdict by denying the release of PHI. The meaning of these rules can be understood by takinginto account the semantics of corresponding HTAGS given in Figure 3.5. Notice that rule 2 isan example of a disambiguated rule that connects two disconnected HIPAA clauses. Whereasone part of HIPAA says “deny if there is no authorization”, another part of the HIPAA text says“release if there is a waiver”. Rule 2 connects these clauses and says “if there is either waiver orauthorization”, then release which is the correct interpretation of the act. If clause-by-clause ruletranslation approach is taken then the fact that our request satisfies both the conditions will eitherlead to ambiguity, or if one follows a more cautious approach, will provide the priority of negative



norms leading to the denial of the request, which is exactly the opposite of the intent.

3.2 Request/Result

In this section we now illustrate a practical example of the request and decision process. In thisexample a researcher wants to obtain all HIV patients records with their psychotherapy notes foradmitted patients during year 2011 from a hospital (i.e. covered entity). The researcher provideda Summary of Data Usage (SDU) which is a brief description about how the information will beused in his/her research often required in HIPAA. His/her purpose is to use it for public healthresearch (i.e. research). We also assume he/she doesn’t have pre-authorization (often researchersmight themselves collect consent from the patient to access PHI). Figure 3.3b, shows the fields ofthe request.

On the hospital side, we assume it has a sample data set with three records (Figure 3.3b). Furt-hermore, as a research hospital, standard operating procedure requires a waiver from each patientwhere the patient can indicate of he/she would like to grant research access permission to his/herPHI. Figure 3.3a has a summary of the researcher example request. It will be important to clarifyfew items of HIPAA legalese to appreciate this example. Authorization is defined as an expresslegal permission obtained from an individual permitting the use or disclosure of PHI, informedconsent of the individual to participate in research, or a waiver of informed consent by an Institu-tional Review Board (IRB). Waiver (or a waiver of authorization) is another document that is usedto disclose PHI but it “must be signed by the chair or other member, as designated by the chair” ofCE. Consent is different than authorization and it can’t be used to disclose PHI for research. CE“may obtain consent of the individual to use or disclose protected health information to carry outtreatment, payment, or health care operations” [57]. Preference (it is different from Consent) maybe specified where there is a range of options all legal in HIPAA (normally indicated by clausaltext “might”). CE or PHI owner might or might not disclose PHI based on their preference as bothrights are protected by HIPAA law.

At the very start the request is routed to the researcher work flow. All the conditions for this workflow are shown in Figure 3.5. Related conditions are grouped together to facilitate processingrequests, see the second tuple of Figure 3.2, “[“( CT1 ∧ CT2 ∧ CT3 ∧ CT4)” ‖ “ CT5 (CT6 ∧CT7)”] & “∼CT8 (CT9∧CT10∧CT11)” & “CT12 (CT13∧CT14∧CT15)”. Figure 3.4 explainshow the conditions are checked in several steps till the final decision to deny or disclose PHI. The



Generated Rules

Requester = Researcher, Purpose = PPT1 and PRI=*

Conditions (Trial) Verdict Information Release Procedure

1 !["CT1 ^ CT2 ^ CT3 ^ CT4 " || " CT5 (CT6 ^

CT7)"] & "~ CT8 (CT9 ^ CT10 ^ CT11)" & "CT12

(CT13 ^ CT14 ^ CT15)"

AT1 Authorization or waiver is not

present (CT1, CT5)

2 [“ ( CT1 ^ CT2 ^ CT3 ^ CT4) " || " CT5 (CT6 ^

CT7)"] & "~CT8 (CT9 ^ CT10 ^ CT11)" & "CT12

(CT13 ^ CT14 ^ CT15)"

AT4 " RRT1 || RRT2 " & "~IPT1 ^ IPT2

^ IPT3 ÎPT4"

3 [" CT1 ^ CT2 ^ CT3 ^ CT4 " || " CT5 (CT6 ^

CT7)"] & "~ CT8 (CT9 ^ CT10 ^ CT11)" & "!CT12

(CT13 ^ CT14 ^ CT15)"

AT1 Researcher Consent is not

available (CT12)

4 [" CT1 ^ CT2 ^ CT3 ^ CT4 " || " CT5 (CT6 ^

CT7)] & "~ CT8 (!CT9 ^ CT10 ^ CT11)" & "CT12

(CT13 ^ CT14 ^ CT15)"

AT1 The request is about Decedent

and no information is provided

(CT9)

Figure 3.2: HIPPA Decision Table

first step is to admit a request by verifying presence of certain fields. In this example authorization“(CT1∧CT2∧CT3∧CT4)” wasn’t submitted with the request. However, due to OR relationshipa pending flag is imposed. As per the rule, alternately, CE Waiver “CT5 (CT6∧CT7)” is checked,and this is available. So the verification proceeds to remaining checks. The next sets of conditionsare record specific.

The first record (Figure 3.3) has HIV and psychotherapy notes (PRI2). But this patient’s preferenceis not to disclose psychotherapy notes. On the other hand, the CE doesn’t mind disclosing his PRI.Thus the pending mark is then cleared by the CE waiver “CT5:164.512.i.1.i (CT6:164.512.i.2.iii∧ CT7: 164.514.d.iii.D)”. Since the request is not about descendent information “ CT8 (CT9 ∧CT10 ∧ CT11)” this check is marked as not required or “n”. The last set of conditions “CT12(CT13∧CT14∧CT15)” is about consent (to abide by various restrictions) by the researcher. Thisis satisfied in this example. Now we have a case where all conditions until now are satisfied towardsdisclosing the PHI but the problem is with the conflict of patient preferences that denies disclosureof his PHI and it conflicts with the CE preference. Step 4 checks that individual patient preference(IPT2) has precedence over missing authorization from the patient (IPT4) (clause 164.508.a.2) orCE preference (Clause 164.514.e.3.i). In this record since patient preferences is not to disclosethe PHI despite the covered entity having a preference to disclose PHI, no PHI will be disclosed.There will be no further evaluation (for 5 for this record). The deliverable will be the reason fordenial (Figure 3.3b, Row 1). Record#2 has preferences to disclose PHI but on the other hand CEprefers not disclosing. A decision to disclose PHI will be positive by evaluating the conditions inStep 2 and since patient preferences has precedence, PHI will be disclosed and pending in Step 4will be cleared. However, reaching this step doesn’t mean disclosing all record information. Step5 has additional screening instructions (RRT1 and RRT2). As a result, only de identified record#2



(a) REQUEST

Identification & Authetication Info

Search Criteria: PRI = “HIV" &

PRI="Psychotherapy notes" & year=2011

Requester= “Researcher”

Purpose = “Research”

Authorization = “NONE”

Attachments= SDU, Researcher Consents.

ID Name PRI Date

Patient

Preferences

for research

Covered Entity

Preferences for

research

1 Raja HIV,PRI2 13/10/11 Don't allow allow

2 Mao HIV, PRI2 1/9/2011 allow Don't allow

3 Tina HIV,PRI2 22/02/11 allow

(b) CE DATA SET

Patient ID Decision DeliverablesSpecial

Instructions

1 DENYNOT

APPLICABLE

2 RELEASE

PRI3(HIV),

PRI2,

01/09/2011

DE-IDENTIFY

RECORDS,

TIME&FEE=N/

A3 DENY

NOT

APPLICABLE

(c) Decision Table for Records

ID PRI Date

2 PRI3(HIV), PRI2 1/9/2011

(d) OUTPUT RECORD

Figure 3.3: Request Flow process

is released with the HIV notes, psychotherapy notes (PRI2) as a final result as shown in Figure3.3d, Row 2. Record#3 doesn’t have any preference from the patient but the CE has preference todisclose it. Like the other two records, this satisfies the conditions until step 3. But, the requestwill be denied in Step 4 where IPT4 requires a consent or authorization from patient because it isa psychotherapy note. Thus, this will not be disclosed.

3.3 Comparison of Formalization Approaches

In this section we will provide a comparison of our method with three other methods [20, 27–29]using the previous example from section 3.

The main concept behind formalizing privacy rules of HIPAA Act in [27] is the process of combi-ning related clauses together from different parts of legal text expressed by combining associated



Step 1 Request

Valid ReqT1 Y

Valid purpose PPT1 Y

Valid PRI1 Y

( CT1 CT2 CT3 CT4) N P

"CT5 (CT6 CT7)" Y C

~CT8 (CT9 CT10 CT11) N n

CT12 (CT13 CT14 CT15) Y

Step 3 Decision

According to waiver Disclose

Individual

preferences

Disclose (IPT 2 has

precedence over IPT4 &

IPT5)

Individual

restrictionNo

Individual

Consents for

Psychotherapy

Notes

Not available

Covered Entity

PreferenceDeny

Time

Fee

RRT

1

RRT

2

Released Record PRI3(HIV), PRI2, 01/09/11

NOTE Record released based on Patient preferences

Step 5 Restrictions

Limited Data to disclose De-identified Data

Data delivery method Not specified

IPT5 P

N/A

N/A

Step 4

Special Instruction

IPT1

IPT2 C

IPT3 n

IPT4 P

Extract & Retrieve information from the request

Step 2 Conditions

["( CT1 CT2 CT3 CT4)" || "CT5

(CT6 CT7)"] & ~CT8 (CT9 CT10

CT11)" & "CT12 (CT13 CT14

CT15)"

AT4 Disclose

Figure 3.4: Details of Processing of Record

clauses in the form of permitted by and forbidden by rules. A researcher without authoriza-tion “164.508.b.3.i” triggers a forbidden by rule which has precedence over permitted by rulegenerated by the waiver. In this case, if the covered entity provided a waiver “164.512.i.1.i” forresearcher to disclose PHI for research purpose, researcher would not be able to obtain it. This isdue to the conflict between the forbidden by and permitted by to resolve overlapping problembetween clauses. In such an approach, the formalization process becomes quite unreliable in pre-cision and becomes error prone. On the other hand, implementation of this approach requires lessanalysis and faster deployment compared to our approach.

In [29] and [20], legal text is translated to prolog using several steps to produce production rulesthat are based on Hohfeldian Concepts. These concepts consist of 8 different categories and theyare: right, obligation, privilege, no right, power, liability, immunity and disability. The authorimplemented direct formalization of HIPAA legal text (clause by clause). HIPAA clauses containreferences to internal and external clauses which have not been considered in this approach. Thiscould create overlapping of rules. By using the researcher’s example, he/she will not be able



to disclose PHI because there is no proposed mechanism in this study to resolve this overlap.However, this approach also lacks external and internal references and is unreliable, similar to theprevious studies, though would require less effort for rule formation.

In [28], authors proposed Least Fixed Point (LFP) Logic for assigning a particular semantic modaland signature. Privacy LFP is used to formalize legal text and information which is processedby predicate send (p1, p2, m) and maysend(p1,p2, m). P1 principal sends message m to p2. Sothe result will be true when p1 sends m to p2 in the send predicate. On the other hand, predicatemaysend(p1,p2, m) shows that the transmission of message m is according to the law from p1to p2. Positive norm is explained as a transmission that might occur if at least one condition ofpositive norm is satisfied. Negative norms are the rules that are defined as information that will bereleased only if it satisfies all negative norms. By referring to the previous example, a researcherwithout authorization is a negative norm and no PHI will be disclosed.

Besides the precision issues, none of these other approaches considers patient’s and covered enti-ties’s preferences, which are equally important legal requirements, in the decision. How informa-tion will be released and what will be released is also another important legal requirement and alsoremains unaddressed.

3.4 Chapter Summary

Formalizing legal text is a complex process that consumes time and efforts but human based valida-tion could consume even more of both [18]. The distinguishing aspect of our methodology is thatwe propose analyzing legal text with respect to a formal and clean Entity Relation Action (ERA)model of the underlying medical record exchange world of HIPAA. We also note a secondary chal-lenge it is extremely difficult to test a complex system like this. We only discuss few pathologicalcases and show how systems with and without an ERA model will interpret them differently whileformer makes the correct decision. However, this is by no means a comprehensive testing. Indeed,future legal edicts possibly should be defined with respect to a well defined and formally codifiedERA model from the very start by the drafters. Such an approach can enormously benefit ma-chine interpretation. The proposed methodology can be used to formalize future legal texts andpotentially open up a new area of computer/machine assisted jurisprudence.



Semantic Text for Requester Clause Ref. # HTAG

Is the request from a researcher? 164.512.i.1 ReqT1

Sematic Text for Condition Tags Clause Ref. # HTAG

Is there an authorization for this researcher? 164.508.b.3.i CT1

Is the authorization not expired. 164.508.c.1.v CT2

Is there any condition placed by CE on this research? 164.508 b.4.i CT3

Does the research meet conditions in CT3? 164.508.b.4.i CT4

Is waiver available? 164.512.i.1.i CT5

Is there a brief description from the researcher about

this research?

164.512.i. 2.iii CT6

Are the minimum no of required documents in the

waiver satisfied?

164.514.d.iii.D CT7

Is this research on decedent information? 164.512.i. 1.iii CT8

Is there a representation that restricts the use or

disclose of decedent information for research purpose

only?

164.512.i.1.iii.A CT9

Does the Researcher agree to provide documentation

of the decedent’s death if requested by CE?

164.512.i. 1.iii.B CT10

Is the PHI necessary for the research purposes? 164.512.i.1.iii.C CT11

Did the CE obtain consents for CT13, CT14 and CT15? 164.512.i.1.ii CT12

Is the use or disclosure sought solely to review PHI as

necessary to prepare a research protocol or for similar

purposes preparatory to research?

164.512.i.1.ii.A CT13

Does the research intend to remove PHI from the CE? 164.512.i.1.ii.B CT14

Is the use of PHI necessary for the research purposes? 164.512.i.1.ii.C CT15

Semantic Text for Record Release Clause Ref. # HTAG

Limited data for the purposes of research, public

health, or health care operations are released

164.514.e.3.i RRT1

PHI needs to be delivered in a media based on request RRT2

HIPAA Referenced Patient Record Items – PRI Clause Ref. # HTAG

Billing Information 164.501.a.1.i PRI1

Psychotherapy Notes 164.524.a.1.i PRI2

User Preferences PRI3

Actions Tags Clause Ref. # HTAG

Denial 164.524.a.2 AT1

Unreviewable Denial 164.524.a.2 AT2

Reviewable Denial 164.524.a.3 AT3

Release 164.524.a.1 AT4

Review on Denial 164.524.a.3 AT5

Update/amend 164.526.a.1 AT6

Temporarily Suspend 164.528.a.2.c AT7

Semantic Text for IPT Clause Ref. #3 HTAG

Release PHI as mentioned in the waiver 164.512.i.2 IPT1

Disclose PHI based on patient preferences 164.532.a IPT2

Restrict disclosure for patients who specifically

restricted disclosing PHI for research.

164.532.b IPT3

Release psychotherapy PRI only if there is an

authorization from the patient.

164.508.a.2 IPT4

A CE may use or disclose limited data set for the

purpose of research.

164.514.e.3.i IPT5

Fee Tags Clause Ref. # HTAG

Cost of document preparation Fee 164.524.c.4 FT1

Copying of Document 164.524.c.4.i FT2

Postage Fee 164.524.c.4.ii FT3

No Fee 164.524.c.4 FT4

Within 30 days 164.524.b.2.a TT1

Within 60 days 164.524.b.2.a TT2

Extension of Time up to 30 days 164.524.b.2.a TT3

Time Extension Reason in Written 164.526.b.2.ii.A TT4

Prior of 6 year 164.528.a.3 TT5

Semantic Text for Purpose Tags Clause Ref. # HTAG

Disclose PHI for research purpose only. 164.512.i.1 PPT1

Figure 3.5: HTAG Set


Chapter 4

Complexity Reduction Through ActorBased Approach

An individual’s health information is personal information that cannot be disclosed without consentfrom the individual except in certain cases. As a result, the U.S. Department of Health and HumanServices (HHS) proposed Privacy Rules to be implemented in (HIPAA). These rules govern theuse and disclosure of an individual’s health information, which is also referred to protected healthinformation. This information is managed by covered entities which include the health plan, healthcare provider, or a clearinghouse, and are enforced by the Office for Civil Rights (OCR). Creatingthe appropriate flow of protected health information within or between covered entities and othersis one of the prime goals of HIPAA privacy rules. These rules allow the use and disclosure ofprotected health information to further advance quality health care or maintain public health whileprotecting privacy of individuals [14, 58]. HIPAA privacy rules are composed of legal texts andthis makes these rules complex in nature. Enforcing these rules would require substantial efforts ifno form of information system were used.

The current implementation of HIPAA privacy rules by covered entities doesn’t fully comply withthese rules. For example, Individuals do not have the opportunity to disclose only certain parts oftheir protected health information like lab results. They can only disclose or deny the use of theirprotected health information as an unified object. This might impose some violations of HIPAAprivacy rules and could result in a fine of up to $25,000 per year for civil rights, criminal penaltiesthat could range from $50,000 to $250,000 and prison between 1 to 10 years in jail [23]. However,using a systematic way to formalize HIPAA privacy rules to logic forms in order to conform them

27

Chapter 4. Complexity Reduction Through Actor Based Approach

has been considered as a solution by several research papers like [27, 59] but the problems ofintegrating these rules and tying them together haven’t been solved the complexity of getting theright decision as to whether to disclose or deny access to protected health information remains apuzzle.

It’s difficult for users to understand security and privacy policies and too complex for software en-gineers to design and implement a comprehensive system. Analysts have to define mechanisms todisambiguate the regulations so those can be clearly specified as software requirements, to ensurethat these systems comply with the policy [24].

From the developer’s point of view, the main challenge is to understand and define system requi-rements, given HIPAA’s legal language [20]. The need for such understanding is not unique toHIPAA, but it is particularly difficult in this case because organizations are performing their ownHIPAA interpretations. It is expected that healthcare firms will pay out $17.6 billion in the nextfew years to bring their systems and procedures in compliance with HIPAA [19].

The figure 4.1 shows the flow of information in the usual healthcare system. Patient medicalrecords could be used for various purposes, not only for the diagnosis and treatment facility. Theycan be used for the efficiency and improvement of the healthcare system, for making related publicpolicies and to conduct survey and research for the advancement in medical science [22]. Patientrecords can also be shared between the payers, such as Insurance companies, Medicaid or Medicarefor the justifications of payment related services, which are done by the physicians. Healthcareproviders may also use the records to manage their operations, for service quality. Healthcareproviders share information with the regional health information organization. Medical relatedinformation also used by the government for public health management, medical research, hospitalcertification and for social and welfare systems management. Actors in HIPAA are involved in thisflow of information.

4.0.1 Actors in HIPAA

There are number of actors in HIPAA that participate in different kinds of activities, and each actorhas a distinct role and purpose according to the regulations of HIPAA. These actors play a specificrole in HIPAA as they are connected directly and indirectly. If we see this world we find that thereare different kinds of laws, so why we need these laws? To answer this question we can say that allthe participants in that specific law have to do their work to some kind of purpose under specific



PersonalHealthRecord

Records

Patients

Primary Provider

PhysiciansClinicsHospitalsHome Healthcare &HospiceNursing homesInstitutional services(Military, prisons, schools)

BusinessAssociate

Payers

Health PlansPrivate InsuranceMedicareMedicaid

Regional HealthInformation

Organizations

Pharmacists

Employers

SecondaryProvider

PhysiciansClinicsLabs

Social Uses of HealthData

Public Policy

Disaster response,Disease control,Fraud Control,Law enforcement & Investigation,Medical & Social ResearchNational Health Information Network

Credential & EvaluativeDecisions

Insurance,Employment,Licensing,Education, etc.

Figure 4.1: Information flow in the healthcare system

conditions. These participants are may be organizations or individuals. So if we look in depth atHIPAA rules, we find that there are three different categories for actors as shown in table 4.1.

Table 4.1: Actors in HIPAA

S.No Covered Entities Organizations Government Authorities Persons

1 Hospital Plan Sponsor State Authority Administrator2 Business Associate Health Insurance Issuer Federal Authority Doctors3 Health Care Clearing House Correctional Institution Foreign Govt. Authority Nurses4 Health Plan Public Health Authority Law Enforcement Official5 Health Care Provider Health Oversight Agency Individual6 Covered Health Care Provider Department of Defense Funeral Director7 Health Plan Law Enforcement Medical Examiner8 Group Health Plan Dept. of Transportation Personal Representative9 Health Maintenance Organizations Foreign Military Authority Researcher10 Coroner11 Inmate

If we see the HIPAA rules all are related to these actors having to do their work with some purposesand conditions, these actors are communicating with each other according to some conditions forsome purpose.



The definition of actors/stakeholders can be observed from HIPAA in 160.103, 164.500 and 164.501.The role related to these Actors can be observed from HIPAA in 164.502 to 164.532 [58]. Detailof actors/stakeholders that are involved in HIPAA are explained in [56] . The rules related to theseactors are present in different parts of sections of HIPAA and all the actors are connected with eachother directly or indirectly.

The purpose for which data may be required for action is very important, because these purposeshave ever more issues which are very important for the information security [60–62]. Usuallyin the Role Based Access Control System [63], actors/stakeholders are allowed or denied to getinformation which is related to their job function that they perform (called their role). These rolesare basically assigned to the Users/Actors where purposes are related to the data that is used fordifferent kinds of transactions. For example, if an Actor wants to access the data he/she mustspecify the data’s purpose (data used for what), so purposes act as the constraints, with actorssubject and the target objective. If one actor wants to request some kind of information fromanother, after checking the purpose and conditions that actor will take an action and send theresponse as output to the requesting actor. The high level flow of information according to HIPAArules for actor is shown in figure 4.2.

HIPAA Rules

Actors Purpose

Action

PurposeConditions

ActorConditions Have

fulf

ill

fulfill

ProducceOutput

Respond

Figure 4.2: Actor base rules information flow

4.1 Request Flow Procedure in HIPAA

The rules that are defined in HIPAA explain the actor’s responsibilities, purposes, conditions andactions [25]. All the rules are placed in different sections of HIPAA. If we want to find the rulesrelated to one actor, we have to check all the sections of HIPAA. For example, there are many rulesin one section of HIPAA that refer to other sections of HIPAA for the same actor. In this case it’s



easy to relate that rule with that particular actor. But there are some rules that are not referred bythe rule, but these rules are important and they are in different sections for that particular actor.

HIPAA complexity increases very much as there are many types of purposes for the data, and thesepurposes are constrained with the Actor’s request. Each purpose has to classify that the specificactor is eligible for that purpose or not. The example of purposes in HIPAA include Treatment,Pay-ment, Health care operations, Health care fraud, Abuse detection, Compliance, Billing, Accessand Amendment etc. All these purposes are related to different Actors. For normal requests in HI-PAA according to [64] one has to follow the different steps for the response.

Step 1: Check from the list of Actor/Requester who is requesting. i.e. ReqTStep 2: Check what are the purposes of the Actor from the list of Purposes. i.e. PPTStep 3: Check for the requested Patient Record Item (PRI) from the list of PRI. i.e. PRIAfter step 3 for further processing we need to process the request according to given information,first of all verify that the requester is eligible of that purpose for which data is requested, thenfor that purpose the requested PRI are needed or not, then to verify between Actor and PRI areaccessible. To verify any of PRI conditional and the actor is fulfilling that condition. For processingwe have the no. of comparisons required. i.e. ReqT * PPT * PRIStep 4: Check from the list of Conditions that are applied on actor who is requesting. i.e. CT sothe complexity increases as i.e. ReqT * PPT * PRI * CTStep 5: Check what the possible action is taken according to fee and time constraint for thosePurposes. i.e. AT * TFT so ReqT * PPT * PRI * CT + (AT * TFT)Step 6: Check for the Special Instruction how to Release the record from the list of InformationProcedure. i.e. IPTStep 7: Check for the Record Release what to Release from the list of Record Release Procedure.i.e. RRT. Finally the complexity of comparison for generating the response can be presented asbelow in equation and flow chart in figure 4.3.(ReqT * PPT * PRI * CT + (AT * TFT)) * IPT * RRT

4.1.1 Rules in HIPAA Sections

Section 164 of HIPAA covers most of the security and privacy related standards for exchangingPHI. It consists of 683 non-repeated clauses starting from 164.502 up to 164.530, according toHIPAA Administrative 45 CFR [58]. The total number of clauses and sub clauses that are used as



if n

ot

Sati

sfie

d

ACTION

Step 5

Request FromResearcher

Process

Check Conditions Rule

Step 1 Step 2 Step 3

Actors List Purpose List Patient Record Items

Patient Billing HIV

Doctor Payment Physiotherapy

Nurse Treatment ENT

.... .... ....

Step 4

Conditions

ReqT Requester Rules Yes / No

PPT Purpose Rules Yes / No

PRI Patient Record Rules Yes / No

CTConditions for Reqt,

PPT, PRIYes / No

Step 5 TFT Time and Fee Rules Yes / No

Step 6 IPTInformation

Procedure to ReleaseSpecial

Instruction

Step 7 RRTWhat Information to

ReleaseList of

Deliverable

if all satisfied

Output:Information Released Procedure According to Rules - Denied

Output:Information Released Procedure According to Rules - Released

Outp

ut

Figure 4.3: Request flow for verification with HIPAA rules

a rule of each section are shown in table 4.2.

But in a formalized process the rules will be increased dramatically. Sometimes, to explain the ruleaccording to [64] modal, the single rule has to be broken in to multiple rules for better understan-ding. For example, in [65] the authors generate 263 rules from sections 164.520 to 164.526 (i.e.from table 4.2: S. No. 8 to 11) according to their modal, while there are actually only 156 rules.

Similarly, we find that there are only 683 rules that are from Section 164.502 to 164.534 if we gothrough clause by clause, but we have more than the total number of rules in our case. For example,we have calculated the number of rules in 164.506 in Table 4.2: i.e.10 with clauses and sub clauseswhich are related to the treatment, payment and health care operation rules for disclosing the PHI,but the number of rules that can be generated from section 164.506 according to [64] i.e. 16. Inthis section there is a referenced section i.e 164.508, which is related to authorization.



S.No HIPAA Section No.of Rules1. 164.502 General rules –

2. 164.504 Organizational requirements 67

3. 164.506 To carry out treatment, payment, or healthcare operations

10

4. 164.508 For which an authorization is required 55

5. 164.510 Opportunity for the individual to agree or toobject

26

6. 164.512 Authorization or opportunity to agree or ob-ject is not required

160

7. 164.514 Other requirements relating to uses and dis-closures PHI

102

8. 164.520 Notice of privacy practices for PHI 67

9. 164.522 Rights to request privacy protection for PHI 21

10. 164.524 Access of individuals to PHI 37

11. 164.526 Amendment of PHI 31

12. 164.528 Accounting of disclosures of PHI 44

13. 164.530 Administrative requirements 45

14. 164.532 Transition provisions 13

15. 164.534 Compliance dates for initial implementation 5

Total 683

Table 4.2: No. of Rules in HIPAA Privacy Section 164.502 to 164.534



Requester

request

Response

(164.508) (164.514)(164.510) (164.512)

RulesExtracted

164.......164.502

Top Level Request Flow forReferenced and Un referenced Clauses

Figure 4.4: Evaluation of Requests between different sections

4.1.2 Referenced and Unreferenced Rules for an Actor

This is an important process of the approach which we adopt to link all rules which are related toactor that are referenced or unreferenced from the different sections of HIPAA. In this way its easyto take the decision for the actor as to which kind of information will be released. For example, anactor sends the request to another actor for information release; this request will be checked withinall the section of HIPAA even if no reference exists for that particular actor for such a request. SeeFigure 4.4.

For example, we have an actor Researcher who wants to get the protected health informationfrom another actor Covered Entity. For that purpose, all the rules related to Researcher will bechecked by Covered Entity and there are some rules for the Researcher in section 164.508, 164.512,164.514, that are referenced, but there are some rules in sections 164.532 which are not referredby any Researcher related rule. For that we have to collect all the rules related to Researcher fromall sections and then take the decision. By this approach we will covered all the unreferenced rulesfor a particular actor.

HIPAA World Formalization Model explains how the overall work will be done in [64]. HIPAAprivacy rules are formalized from legal text into eight different types of tags. Then, tags are ana-lyzed and converted to yes or no questions. Next, information retained in the transponder willlink the requester with related tags logically based on the requester. Whereas, the transponder willwork to perform compliance checking against the requested information, make decisions, about



how information is released by checking information procedures, and then respond to the reque-ster according to HIPAA privacy rules.

4.2 Complexity of HIPAA

In [64] we have developed the HIPAA World Formalization Model, which we are using for forma-lizing entire legal text of HIPAA. This requires tremendous effort, time and a lengthy process ofdata analysis. In addition, dedicating human power to implement this job is expensive and couldcost a lot of money. Meanwhile, if the entire legal text is formalized, the problem of querying dataproduces undesirable false hits. In other words, using the approach proposed in [64] would requireextensive comparisons with rules that might not produce a single successful hit and this wouldconsume resources in an inefficient way. The reason behind this is due to some different factors.First of all, there are number of actors involved in HIPAA; secondly, there are number of purposesto request the data in HIPAA by these actors from each other; similarly, for the request there area number of conditions applied on each request according to the purpose of request for that actor.Thirdly, there are number of patient related record items that are requested by these actors andsome of these record items need to be provided with some conditions, some of them are totallydenied and some of them may be disclosed without any conditions. So these extra conditions haveto be resolved before releasing the record internally from patient’s record. So there we can ima-gine that after formalization of HIPAA we have to resolve the high level of comparison of rules inone request between Actors, Patient Record Items (PRI), Purposes, Conditions, Conditional recordItems, Conditionals Purposes, etc.

Figure 4.4 explained about the reference and cross reference issues in HIPAA, but if the diagramis analyzed from the requester point of view, the information related to the sections are formalizedin [64] as shown in figure 4.5.

HIPAA have different number of Sections like (164.524), and each Section has the Clause (164.524.a),Super Sub Clause (164.524.a.1), Sub Clause (164.524.a.1.i) and sub of Sub Clause may exist(164.524.a.1.i.A). For each request we have to search in depth up to sub of sub clause, step by step,from the top level of each section extracting rules from HIPAA clause by clause from differentsections using algorithm 1. The complexity of HIPAA can be analyzed by this algorithm beforeformalization.

This algorithm only operates for the searching of rules from the HIPAA Sections, and after that



Data: Input: Section S ← 1toN ;Super subClause SSubC ← 1toP ;Sub Clause SubC ← 1toQ ;Sub of SubClause SofSub← 1toR ;Result: Generates Rules as clause by clausewhile S ≤ N do

i← 1;j ← 1;k ← 1;l← 1;while i ≤M do

Search Rule and save the Rule;if any C has SSubC then

while j ≤ P doSearch Rule and save the Rule;if any SSubC has SubC then

while k ≤ Q doSearch Rule and save the Rule;if any SubC has SofSub then

while l ≤ R doSearch Rule and save the Rule;

endend

endend

endend

endend

Algorithm 1: HIPAA Clause by Clause Rule Extraction Algorithm from Legal Text



each rule has to be compared with the purpose of request, conditions for that purpose, conditionsfor the requester and the patient’s record items (if that are required in request).

In [64] our first step is to formalize the legal text and make the separate classes for these rules andall the rules are under any one of the class. So with this approach we reduce the searching of rulecomplexity from each section, as we have assigned our own tag value to each clause and under thatsub clause on single level. So for each request we now only have to search from the eight classesfor the request one by one. So we have reduced the search spaces but complexity is still therefor the comparison of related purpose, conditions and PRI. In next section 4.3 we discuss how wereduce this complexity of comparison and get more reliable results.

4.2.1 Time complexity

We present a brief analysis of the HIPPA rule extraction algorithm. Let T(n) be the total timetaken by the algorithm to extract a rule. We also assume each statement in the pseudo code takes aconstant time to execute therefore single statements outside loop’s bodies are not considered. Onlythe loops are taken into consideration for this analysis. So the total time can be expressed as

T (n) =N∑

S=1

NS(M∑i=1

Mi(P∑

j=1

Pj(

Q∑k=1

Qk(R∑l=1

Rl))))

• Worst Case:

In the worst case, if all statements get executed i.e. rules are completely extracted in sub ofsubClause. Since each term takes constant time in each loop therefore,N∑

S=1

NS = n,M∑i=1

Mi = n,P∑

j=1

Pj = n,

Q∑k=1

Qk = n,

R∑l=1

Rl = n

Then the total asymptotic time of this algorithm in worst case is T (n) = O(n5)

• Best Case:

Best case occurs when the desired rule completes in super subClause i.e. the first if statement insecond loop is false every time. In this case the time complexity T (n) = O(n2).



4.3 Rules Filtration through HIPAA World Rules Model

We basically have two problems. The first is related to the formalization process of the entireprivacy rules of HIPAA which we have resolved in [64], where the second is the number of com-parisons when querying data.

To solve the first problem, we propose partial formalization of legal text. Instead of formalizingthe entire text of privacy rules, only rules that are related to certain disciplines will be formalized.For example, if the main user who wants to disclose protected health information is a researcher,then clauses related to research will be extracted from HIPAA. Nevertheless, the researcher asa requester of data has the right to access any patient record items based on the authority andthe purpose of this access. This means all clauses that contain patient record items need to beformalized in this process. Having partial formalization would save time and money becausewe formalized portion of the entire legal text to build one block. Once more resources can beafforded, another block can be built, but this time only clauses related to a certain requester will beformalized and no more formalization will be required related to the patient record items (see rulesfiltering in Figure 4.5). Remaining steps of formalization will similar to the method discussed in[64].

As for the second problem, we have developed a new methodology to search the rules set based onrequester instead of making comparisons with all rules sets. Availability of more requesters willnot change the fact that only rules related to requester will be examined.

4.3.1 Time Complexity

Time complexity of the proposed algorithm 2 for extracting rules is O(n), since there is only oneloop running n times. Again here we do not consider any statements outside loop’s body since theirtime is constant. Also note that the worst and best case time complexity is same for this algorithm.Therefore we can express the asymptotic running time of the algorithm is T (n) = O(n)

4.3.2 Complexity Comparison of Actor base Approach

Due to the complexity of legal text of HIPAA, the proper formalization of HIPAA has not beendone but several interesting attempts have been made to convert general legal text into logic rules



Data: Input:arrule← 1 to N ;Result: Generates Rules as clause by clausewhile arrule do

if by rule = true thenSave the Rule ;if cond rule OR Ref rule exist then

if cond rule OR Ref rule = true thenSave the Rule ;repeat until all rules saved ;

endelse

Exit ;end

endelse

Exit ;end

endreturn all Saved Rules ;

endAlgorithm 2: Actor base Rule Extraction Algorithm from Legal Text through HIPAA World RuleModel



RulesFiltering

Explanation(List of Rules

Executed)

Decision

SepecialInstruction (How

to Release)

Privacy Rulesof HIPAA Act

Legal Text

Concept Class Generation Process

ReqT

RRT

CT

AT

IPT TFT

PPT

Human Based Process

Computer Based Process

Request

Query

List ofDeliverables

(What to Release)

Audit(Steps of Rules

Trigers)

ActionTaken

Informationand RecordProcedure Complaince Checking

ID SSN DOB AGE

PatientsMedical Data

PRI

ConditionalPatient Record

Items

Actor BasedRule

Logical Rule Set

ResearcherRelated

CoveredEntity

InsuranceProvider

PlanSponsor More---

TRANSPONDERSReearcher

CoveredEntity

InsuranceProvider

PlanSponsor

More --

ERD

Figure 4.5: Filtering Rules based on Requester through HIPAA World Formalization Model

[27, 29, 59]. The complexity of the HIPAA rules extraction clause by clause is very high i.eT (n) = O(n5) and that will grow exponentially if more subofSubClause are in HIPAA. But inan Actor based approach the running time of the algorithm is T (n) = O(n), which is in a lineartime to evaluate the request. Using this approach we will be able to get results more efficiently andaccurately.

4.3.3 Actor Based Queries Example

Query: “A researcher wants to disclose protected Health Information regarding HIV patients who

were admitted in current year to improve healthcare. He/she does not have authorization to access

protected health information but granted a waiver from the medical provider to fulfill this job”.

Symbols used in figure 4.6 are explained as follow; ’∧’ means “and within a rule”, ’&’ means“and between rules”, ’‖’ is used as “or”, ’!’ for “not”, ’∼’ means “may”. The resolution pro-cess reads rules as, If (Requester = “Researcher” & Purpose=”Purpose Tags”, & Items = “Patient



Generated Rules for Researcher From All Sections

Requestor Purpose PRI Conditions Action Information Release

Procedure

Researcher PPT1 Any PRI

" CT1 ^ CT2 ^ CT3 ^ CT4 " & " ~CT5 (CT6 ^ CT7) ^ ~CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"

AT4 " RRT1 || RRT2 " & "~IPT1 ^ IPT2 ^ IPT3

ÎPT4" Researcher PPT1

Any PRI

“ ! ( CT1 ^ CT2 ^ CT3 ^ CT4) " & " CT5 (CT6 ^ CT7) ^ ~CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"



Any PRI

"! CT1 ^ CT2 ^ CT3 ^ CT4 " & " ! CT5 (CT6 ^ CT7) ^ ~ CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"

AT1


" !CT1 ^ CT2 ^ CT3 ^ CT4 " & " CT5 (!CT6 ^ CT7) ^ ~ CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"

AT1


" !CT1 ^ CT2 ^ CT3 ^ CT4 " & " CT5 (CT6 ^ CT7) ^ ~ CT8 (CT9 ^ CT10 ^ CT11) ^ ! CT12

(CT13 ^ CT14 ^ CT15)"

AT1

!Researcher PPT1 Any PRI

AT1

Researcher !PPT1 Any PRI

AT1

!Researcher !PPT1 Any PRI

AT1

Figure 4.6: Rules Generated for Researcher

Record Items”; check Conditions (Condition = “Conditions Tags” & ReqT Condition = “Reque-ster Tags” then (Action= “Action Tags”, & Record Release= “Record Release Tags”& InformationProcedure= “Information Procedure Tags”, & Time and Fee = “Time and Fee Tags”))) ;

Figure 4.6 shows that how logical rules are extracted and represents constraint with instructionsthat expressed in HIPAA. For example, the first logical rule in Table.1 means, that if a requesteris of type researcher (ReqT1) with purpose (PPT1), that is for research and is requesting for thepatient record item (PRI). If he/she satisfies all the conditions “ CT1 ∧ CT2 ∧ CT3 ∧ CT4, thatmight satisfy CT5 (CT6 ∧ CT7), might satisfy CT8 (CT9 ∧ CT10 ∧ CT11) and have to mustsatisfy CT12 (CT13 ∧ CT14 ∧ CT15)” then an Action (AT4) for disclosing the information isissued as a result after satisfying all conditions. This decision will be related to deliverable thatindicates that how the information will be released “∼ IPT1 ∧ IPT2 ∧ IPT3” and filters will beapplied on released information “RRT1 ‖ RRT2”. Tags details are explained in [64].

4.4 Chapter Summary

Formalizing legal text is a complex process that consumes time and efforts but human based vali-dation could consume even more of both [18]. Precision is what differentiates our work from otherearly proposals. The methodology that we proposed requires analyzing legal text with respect to aformal and clean Entity Relation Action (ERA) model of the underlying record exchange world ofHIPAA. The proposed methodology can be used to formalize other legal text and potentially openup a new area of computer assisted jurisprudence.


Chapter 5

Legal Text to Logical Rules using MedicalRelational Model

This chapter presented a Medical Relational Model (MRM) for the extraction of logical rules fromMedical Law, required to design Medical Decision Support System (MDSS) that facilitates theprocess of exchanging data electronically with minimum human intervention. These logical rulescan further be used for taking decisions to release or deny the release of certain medical records incompliance with law, when requested by any entity of the medical system. Several attempts havebeen made to convert legal text into logic rules as discussed in Chapter 2 (Literature Review) witha special focus on HIPAA, given its importance to health care.

But one of the common peril in such approaches was the inability to capture the deep semanticconnections between various sections of the large HIPAA text. In close observation one wouldnotice that these first generation approaches (such as [27–29]) are attempts to translate the legaltext clause by clause, into corresponding logical expressions. The rules set reflect the clausalorganization and syntax of the legal text. It spares comprehension of the overall HIPAA semanticsexcept for the part by part attempt to model the semantics of the sentences. The inference process isexpected to drive from one “sentence” (presented in the form of logical expression) to another andfind the connections between constraints defined in various parts of the act by shared predicates.In one sense it is remarkable, without the explicit comprehension of the overall HIPAA, how muchsuccess they have achieved in making many decisions correctly. However, the resulting logicalsystem seems to miss many higher cognitive level connections hidden in the semantics of theoverarching HIPAA environment. Indeed, several cases of “conflict” cited are artifacts of missing

42

Chapter 5. Legal Text to Logical Rules using Medical Relational Model

deeper semantic/indirect cross references. A human expert can connect the context and may notsee these cases as a conflict. Indeed, to resolve the conflict artifacts all these approaches have to useextensively some form of preference/precedence meta rules, though these are not part of HIPAA.

Supporting programmable legal compliance and real life actions require a substantial understan-ding of the conceptual framework of Medical Law. For automatic verification of HIPAA privacycompliance, an understanding of the structure and interrelation of the privacy rules is needed. Forexample, why do we need a law to govern the release, exchange and use of information? Howto respond to requester or entities in Medical System? What conditions are applied for accessingspecific information? What kind of actions should be taken by the system in response to differentevents? It can be argued that every law has its reasons, purposes and there are some conditionsfor these purposes. Each request has a response and action. In other words, in order to build aneffective MDSS, all aspects beyond legal text must be covered.

5.1 System Methodology

This chapter captures and accommodates deeper underlying semantics of the complex aspects ofMedical Law. A Medical Relational Model (MRM) is used, which include the medical entities andtheir relationships that define the semantics of the domain, on which the Act and their provisionshave been laid and structured. Based on the MRM, a systematic Tag based approach is adoptedto convert the corpus of legal texts into a set of logical constraints and actions. It requires thedesigner to explicitly comprehend and extract the connections (with HIPAA experts) and summa-rize the overall behavior as a set of independently constructed rules. The system pre-resolves thesemantic connections, and thus generates much more precise resolutions. The MRM and the rulesonce generated, then can provide a transparent process in the form of decision trees to preciselyresolve information requests. Besides the decisions, the resulting system can much better articu-late other intents of HIPAA. It also specifies how to release a particular piece of information. Ifdenied what are the alternate options, that generate logically coherent explanation to support andconform the decisions. Conforming to the original expectations of HIPAA, the entire process canbe subsequently automated.



5.1.1 Concept Space of HIPAA

Figure 5.1 shows eight (8) elementary Concept classes named Requester, Purpose, Patient RecordItems, Condition, Action, Fee and Time, Information Procedure, and finally Record Release class.It is an internal structure of medical law, which is based on these Concept classes.

Tag Description of Concept Classes

ReqT Request Class: A designated class of the individual/entity making the release request. For example

“Researcher”, “Doctor”, etc.

PPT Purpose Class: Requires every request to have a valid purpose specifying the intended use of the

requested PHI. Example purposes are “research”, ”amendment”, “treatment”,”operation”.etc.

PRI Patient Record Item Marker: A marker attached to individual record items specifying their significance

of records. Example is “Billing Information, “Psychotherapy Notes”, etc.

CT

Condition Class: Conditions are triggered based on requester (ReqT) and submitted purposes (PPT) and

patient records items (PRI). Example, if the ReqT is a researcher does he/she have an authorization for

research?, If the PPT is for research, is the requester has the role of a researcher?, if the PRI requested is

psychotherapy notes, is there any requirements, like specific authorization for psychotherapy, available?,

etc.

AT Action Class: Action that is performed on each request as a result of evaluating rules’ sets. Examples

“Deny”, “Release”, “Update”, etc.

TFT Time & Fee Class: Fee and Time Required for processing a request. Example, more time is required to

de-identify patients information. Cost of preparing documents, postage fee, etc.

IPT Information Procedure Class: Rules that specify how information will be released. Example, information

will be released with a fee and time delay, Information will be de-identified before releasing it.

RRT Record Release Class: Actual information that will be released as a result of a request. Example, 5

patients record are released.

Figure 5.1: Concept Classes Description

Concept classes indeed have relations with each other. Some of these relations are Conceptual,whereas others are Compositional. However, making relationship between tags in Concept classesrequires MRM to understand the semantic of these connections.

Figure 5.2, represents the proposed MRM that governs the connection of Conceptual and Composi-tional relations between classes. Our MRM is based on eight conceptual relations between Conceptclasses and three Compositional relations that form three classes. These classes are; Request Flowclass, Evaluation class, and Release class.

The first conceptual relation is between a Requester (1) and Purposes (5) where a requester couldhave different purposes for a request. Furthermore, remaining conceptual relations are explainedas follow: a requester (1) requests records from a covered entity (2), covered entity managespatient’s information (3) which contains record types (4) and has information release procedure(10), covered entity takes an action (6) based on conditions (7) and takes the appropriate time andfee (9) for that action.

There are three compositional relation classes that are formed by several Concept classes. RequestFlow class is composed of Request (1), Purpose (5) and Patient Record Item (4) classes. Evaluation



class is composed of Request Flow class, Time & Fee (9), Action (6) and Condition (7) classes.Release class consists of Record Release class (8), Information Procedure class (10) and Evaluationclass

In figure 5.2 big ovals represent our Concept classes and small ovals with the Concept classesrepresent the tags associated with each class and rectangle shapes represent the processes that usesthose classes.

Path for a requester after initiating a request for retrieving protected health information. The

requester initiates a request with one or more purposes to medical provider who has patients’ data.

Covered entity evaluates the request by checking conditions, then takes an action by releasing or

denying the request with the appropriate fee and time if applicable

Covered Entity verifies information procedure about releasing protected health information and releases

the documents.

Figure 5.2: Medical Relational Model (MRM)

5.1.2 Tags Set

Related clauses are grouped under any one of the concept class and tags are assigned to these clau-ses. For example, the concept class related to Requester is searched for Requester’s informationclauses. Then, each requester is assigned a tag (ReqT1, ReqT2 etc.) and added under Requesterconcept class. Each tag refers to clause that contains the information related to the Requester con-cept Class. Conditions that need to be satisfied, are placed under the Conditions concept class and



each condition rule is assigned a (CT) tag. Time and Fee class indicates the time and fee neededto release PHI are referred to as (TFT). For example, the Covered Entity might place a preparationfee on disclosing documents. Some medical records may require human verification to make surethese records cannot be identified. This requires a processing time that might delay the releaseof these records. All purposes of requests, which are related to Requester, indicate reasons fordisclosing PHI listed under Purpose concept class and each rule is assigned a (PPT) tag. Actionneeds to be taken whether to deny or disclose PHI. We collect these actions under Actions conceptclass and each action is assigned an (AT) tag. Information Procedure concept class represents howinformation will be released and (IPT) tag is used in this class. Record Release concept class isrelated to the rules that indicate what type of information will be released.

For example, the psychotherapy notes (RRT) tag is used to distinguish among rules in its class. Allrecord items in each section need to be evaluated for dependencies. For example psychotherapynotes cannot be disclosed without an authorization from individual as stated in clause 164.508.a.2of HIPAA. This indicates that a condition needs to be satisfied for this type of record item. Wemark all patient’s record items that have dependencies and put them in one PRI class.

5.1.3 Rule Set Formation from HIPAA

For illustration in this article we focus only on the HIPAA edicts specific to use of PHI by re-searchers. HIPAA clauses in sections 164.508, 164.512, 164.514 and 164.532 respectively coverportion of this usage. There are multiple ways of organizing the logical rule expressions. In thissystem, logical rules are organized based on possible combinations of requester (ReqT), purpose(PPT) and patient record items types (PRI). Each rule also has associated condition tags (CT). Eachlogical rule then specifies a unique decision action (AT), and special instruction (IPT) on releaseprocess format choices (RRT), time & fee restrictions (TFT) are applied when applicable.

The resolution process reads those as, If (Requester = “Researcher” & Purpose =“Purpose Tags”,& Items =“Patient Record Items” then check conditions (Pre-Condition = “Pre-Conditions Tags”& ReqT Condition = “Requester Tags” & Purpose Condition =“Conditional Purpose Tags”) then(Action =“Action Tags”, & Record Release =“Record Release Tags” & Information Procedure=“Information Procedure Tags”, & Time Taken =“Time Tags”, & Fee =“Fee Tags”). As a result,extracted information from all HIPAA Act sections will be distributed among 8 concept classesand the decision will be based on combinations of tags from these concept classes. Note: fee classand time class might not be available in all privacy rules sections of HIPAA Act.



A three steps approach is undertaken in this article to address the challenge of HIPAA. In figure5.3 the first part of the modeling process consists of parsing the HIPAA text to identify the compo-sitional and functional model of HIPAA regimen in-terms of components and core processes. Thisinvolves identification and classification of the key concepts in terms of entities, actors, actions,and conditions including factors that build the conditions, and action modifiers described in variousparts of HIPAA. Once these concepts are extracted, they are further organized into classes, typesand their relations in second step. Thirdly the core processes involving these entities (functionalrelationship between the entities) are also ascribed. This process leads to an MRM model.

Figure 5.3: World Rule Model using MRM for Decision Support System

5.1.4 HIPAA Rules Filtration through World Rule Model (WRM)

We proposed partial formalization of legal text into logical rules in the first part of WRM. Instead offormalizing the comprehensive text of privacy rules, only rules that are related to certain disciplineswill be formalized. Logical rules from different sections of HIPAA are extracted using algorithm3 and flow of algorithm shown in figure 5.4.



Read File Extract Keywords

Extract Rules in XML

Categorization

Save Rules

XML LogicalRules

Read Next Rule (Yes)

No

Figure 5.4: XML Rules Filtering Algorithm Model

Tag rules are compiled for each medical entity as shown in figure 5.5 for Researcher. After that,Tag rules are compiled into XML based logical rules for each entity with algorithm 3. A sampleof XML logical rules generated through algorithm from HIPAA are shown below.

<rules>

<rule ruleid="164.512.b">

<Request>access</Request>

<Requester>patient</Requester>

<Entity>hospital</Entity>

<AccessLevel>permission</AccessLevel>

<Condition>hospital_Law_3</Condition>

<CrossReference>164.508.a.1</CrossReference>

</rule>

</rules>

The second part of the modeling process is the derivation of the actual constraints expressed inthe act. The constraints can be of logical, temporal or functional type. In this step the logicalconstraints, conditions and exemptions of the information release process as expressed in HIPAAare derived. Each rule or clause in these concept classes is identified (in terms of tag) and areconnected together based on how a request of disclosing PHI is processed in according to theprivacy rules of HIPAA Act. Different sections of privacy rules may consist of related information



Data: Input: Rule Pattern File RPF , POST Data File POStagF

Result: XML Based Logical RulesStep 1 Read RPF to Extract Rp (Rule Pattern);Read Rp and Placed in a List Rcl;Step 2 Create Lists Lm where 2 ≤ m ≤ n n is the no. of Component in Rule Pattern;forall Ruleid from POStagF do

Read Ruleid Ri;Read Words Wi Corrsponding to Rcl[p] 1 ≤ p ≤ n;Add it into its Revelent list Lp;rule =< Ruleid > Ri < Ruleid >;if length of each list Li is 1 then

use each list Li ;rule = rule+ < Rcl[i+ 1] > Li[1] < Rcl[i+ 1] >;

endelse

if Length of L2 > 1 thenlen = length(L2);Generate len many copies of Rule ;Rule1 = rule;Rule2 = rule;· · · ;· · · ;Rulelen = rule;

endwhile t = 1→ len do

Rulet = Rulet+ < Rcl[2] > L2[t] < Rcl[2] >end

forall Rulet where 1 ≤ t ≤ len doforall List Li where i > 2 do

while s = 1→ Lenght(Li) doRulet = Rulet+ < Rcl[i] > Li[s] < Rcl[i] > + newline;

endend

endend

endOutput: XML Logical Rules Generated

Algorithm 3: The XML Logical Rule Generation Algorithm



needs to be considered in this process. At the end, the HIPAA requirements are compiled togetheras a set of logical rules.

In the final part, requests for various administrative actions are processed. An administrative re-quest originates from the requester. It includes but is not limited to, identity, purpose, specificationsof information requested and a set of associated credentials (such as authorization, waiver, etc.).The Transponder (decision work flow specific to a particular type of administrative request) gene-rates the “decision” or “conformance verification” as per HIPAA.

Transponder acts as the mediator between the administrative requests on one side and the medicaldatabases with HIPAA tagging on the other side. Transponder runs the resolution process as perspecification in the HIPAA rule set. The transponder can also generate four other items: namely,(i) a list of deliverable, (ii) special instructions specifying format choices (raw record, summary,etc.), special processing (like de-identification required), fee, and time constraints, etc. as specifiedin HIPAA. On request, the system can also provide (iii) an explanation- identifying rules triggeredand (iv) audit- specifying who, when, and what has been requested, created, released, etc. Thispaper focuses only on the first item “generation of decision”.

5.2 Results

5.2.1 Rule Set for Researcher from HIPAA

For example, if requester is a researcher role (ReqT1) with a research purpose (PPT1), initiated arequest to disclose patient record item (PRI). He/she must have a non-expired authorization andif there are restrictions from the covered entity, requester must satisfy these restrictions “CT1 ∧CT2∧CT3∧CT4”. If waiver is provided “CT5 (CT6∧CT7)”, then the minimum requirementsof the waiver (CT7) must be satisfied and a brief description about the research “CT6” need tobe provided. If the researcher intends to do the research on decedent information “CT8”, thenhe/she must present a representation “CT9” indicating that the use or disclosure of this informationis only for research. In addition, the requester must agree to provide the covered entity withdocumentation of descendent “CT10” death if requested by covered entity. Nevertheless, providinga representation indicating the necessity of this type of PHI for the research “CT11” is a must.For any type of research, the Covered Entity must obtain consents “CT12” from the researcher.Consents must conform that the disclosure sought solely to review PHI as necessary to prepare



a research protocol or for similar purposes preparatory to research “CT13”. The researcher mustnot remove PHI from covered entity “CT14” and provide a representation indicating the necessityof this information for the research “CT15”. Figure 5.5 shows all the rules that are generated forresearcher. Tags detail are explained in [64].

Generated Rules for Researcher From All Sections

Requestor Purpose PRI Conditions Action Information Release

Procedure


" CT1 ^ CT2 ^ CT3 ^ CT4 " & " ~CT5 (CT6 ^ CT7) ^ ~CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"



Any PRI

“ ! ( CT1 ^ CT2 ^ CT3 ^ CT4) " & " CT5 (CT6 ^ CT7) ^ ~CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"



Any PRI

"! CT1 ^ CT2 ^ CT3 ^ CT4 " & " ! CT5 (CT6 ^ CT7) ^ ~ CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"

AT1


" !CT1 ^ CT2 ^ CT3 ^ CT4 " & " CT5 (!CT6 ^ CT7) ^ ~ CT8 (CT9 ^ CT10 ^ CT11) ^ CT12

(CT13 ^ CT14 ^ CT15)"

AT1


" !CT1 ^ CT2 ^ CT3 ^ CT4 " & " CT5 (CT6 ^ CT7) ^ ~ CT8 (CT9 ^ CT10 ^ CT11) ^ ! CT12

(CT13 ^ CT14 ^ CT15)"

AT1

!Researcher PPT1 Any PRI

AT1

Researcher !PPT1 Any PRI

AT1

!Researcher !PPT1 Any PRI

AT1

Figure 5.5: Generated Rules for Researcher

Symbols used in figure 5.5 are explained as follow; ’∧’ means “and within a rule”, ’&’ means “andbetween rules”, ’‖’ is used as “or”, ’!’ for “not”, ’∼’ means “may”.

5.2.2 Query and Result

In this section an example is presented to provide a practical explanation of how a request isprocessed with the proposed World Rule Model approach using MRM in Decision Support System.

5.2.2.1 Researcher Example

A researcher request in natural language: “A researcher wants to disclose Psychotherapy notes forpatients who were registered after the year 2013. The researcher has authorization to access PHIfor research purposes. The PHI is requested to be received via email”.

Query in SQL Format: Select Patient Data from Patients Records where PRI= Psychotherapyand Date > 2013 and Requester= Researcher and Purpose = Research group by Requester &&

Purpose having Waiver rule=None && Authorization = Patients Authorization



Requester Role: Researcher ID: 5678

Authorized By: Yes - Research Waiver Rule: No

Purpose 1: Research Single Record Items: Psychotherapy

Purpose 2: None Multi Record Items: None

Multi Purpose: None

Date From: 1/1/2014 Date To: 12/12/2014

Record Format: Default

Figure 5.6: Researcher Query Form

ID Name PRI Date

Patient

IPT = research

Covered Entity IPT

= research

Conditional

PRI Status

1 Abaad PRI1 05/02/2014 Deny Deny

2 Maria PRI1 04/10/2014 Disclose Deny

3 Raja PRI5 13/10/2014 Disclose Authorized

4 Tena PRI1 03/06/2014 Disclose Disclose

5 Nelo PRI5 15/08/2014 Disclose Authorized

6 Lala PRI2 02/12/2014 Disclose Deny

7 Mao PRI1 01/09/2014 Deny Disclose

8 Tina PRI5 22/02/2014 Deny Unauthorized

Figure 5.7: Patients Records

In this example when the query (Figure 5.6) is processed on Patient’s Record (Figure 5.7), Rulenumber 1 from Figure 5.5 will be triggered because the researcher has an authorization. In addition,regarding the list of instruction and deliverable for releasing information, will be released by emailbased on RR2. Figure 5.8 is the actual output. Note that personal information is presented in thistable because the researcher has authorization from patients to disclose PHI.

ID Name PRI Date

3 Raja PRI5 13/10/2014

5 Nelo PRI5 15/08/2014

Figure 5.8: Output result of the query

5.3 Discussion

We compare our methodology with three other methods [27–29] using the previous example fromsection 5.2.1. There are few exceptions like 164.508(a) (2) which indicates that a covered entity



Table 5.1: HIPAA- Comparison of Result with other Approaches

A: Medical Relational Model , B: 1st Approach [27] , C: 2nd Approach [29] , D: 3rd Approach [28]

Considered items in the study A B C D

1 Clauses are linked within the same section Y Y Y Y2 Direct cross references is considered Y Y Y Y3 Indicates applied rule as a result of a query Y Y Y Y4 Provide type of action taken as a result of a query Y N Y Y5 What information will be released is considered Y N Y Y6 Study cover all the privacy sections of HIPAA Y N N Y7 How information will be released is considered Y N N N8 Medical Relational Model for HIPAA Y N N N9 Unreferenced Information between sections is covered Y N N N

is obligated to obtain authorization for using or disclosing psychotherapy notes except in certainconditions. In [27–29] a researcher without authorization (164.508.b.3.i) would not be able toobtain PHI or psychotherapy notes due to “forbidden by” and Negative norm, even if the coveredentity provided a waiver (164.512.i.1.i) for researcher to disclose PHI for research purposes. This isdue to the conflict between the “forbidden by”, “permitted by” and Negative norm, Positive normsto resolve overlapping problem between clauses. In all the above methods, the denying clause istreated as a “forbidden by” or Negative norm that does not satisfy the only if condition. On onehand, Information should be permitted if at least one rule of the “ifs” positive norms satisfies acondition. On the other hand the information should be permitted if all the rules in the “only if”Negative norms are satisfied. We can conclude that if there is a negative norm, then informationwill not be released. More precedence is given to Negative norm as compared to Positive norm,because if any one of the Negative norm is not satisfied then it is treated as a denial of releasinginformation even if there are some Positive norms allowing the disclosure of PHI.

Remember the discussed example is about a researcher who, if he does not have an authorizationbut has a waiver, means that there is a negative norm because the research must have an authoriza-tion to disclose PHI. As a result, the researcher will not be able to disclose PHI because one of thenegative norms has not been satisfied. Nevertheless, a waiver has precedence over authorizationand the researcher should be able to access PHI. Moreover, nothing in [27–29] has been discussedregarding how the output will be generated and what will be the format of the output. Individualsand medical providers preferences were not considered in [27–29]. Cross referencing of clausesin different section has been handled manually. Table 5.1 shows the comparison results with otherapproaches.



5.4 Chapter Summary

A methodology to formalize legal text required to build and design MDSS to facilitate the processof exchanging data electronically with the lowest level of human intervention has been presen-ted. Precise rule generation and information release are what distinguish this work from others.Complex information has been divided into small manageable pieces (tags) to ease the integra-tion process based on information flow from requester, information owner and the law that governfor the exchange of the information. World Rule Model (WRM), which required understandingthe entire process of splitting complex information and generating the output, pre-processing ofthe legal text would generate a search-able table that assists in taking a more precise decision indisclosing or denying release of information. We found that missing important factors that mightproduce less precise decisions is caused by direct formalization of legal text without understan-ding the big picture. Following our model in formalizing legal text will prevent such approach andassure producing a more precise decision. There is no formal models existing in this domain tocompare or test result globally, but we have compared our methodology with the related work thathas been done on HIPAA, which is shown in table 5.1. HIPAA privacy rules are just an examplefor our experiment.


Chapter 6

Construction of Clinical Documents usingHL7

In this modern era, Healthcare Management Systems are playing an important role for the im-provement of society’s health in any country. Unfortunately, the health of healthcare industry indeveloping countries is very poor. The use of Health Management Systems (HMS) even at theindividual hospital level is nearly non-existent [31]. The current system requires a great impro-vement in the health industry with Information and Communication Technology. Various hospitalsin developed countries are already recording and archiving patient information in their Hospital’sInformation System (HoIS). However, when we consider the millions of patients and hundreds ofthousands of healthcare providers, the task of archiving, integration and meaningful use of thisdata is formidable.

Now-a-days, people travel in different parts of the world more than ever before. Therefore thedemand for medical data exchange among different countries is becoming much greater. As alarge number of people travel abroad, they sometimes need to visit a hospital. In such casesdoctors in the hospitals may need to have access to the previous history of the patient for propertreatment plans. To facilitate this process, clinical data must be exchanged internationally [10, 52].Proper analysis of the clinical data and targeted research can lead to new discoveries benefiting allstakeholders at larger scales. Yet, on the other hand, providers can use healthcare data analyticsand do research to learn about patient populations, enhanced preventive care, and make effectivedecisions by accessing key data such as demographics and chronic conditions.

Healthcare data is the most sensitive type of data to exchange, which has the risk of the violations

55

Chapter 6. Construction of Clinical Documents using HL7

of rights and responsibilities associated with it [11]. To protect the privacy of individual’s medicaldata there exist medical laws in each country. To ensure that medical information exchange amongmedical entities is according to the medical law, several studies propose solutions to formalizelegal text into some form of logical rule set.

6.1 Methodology

The first issue was how we can formalize the legal text in to automated rules set for the compli-ance checking with the medical law. Being able to formalize the legal test properly means theautomation of medical law, and will help us with the implementation and document generation inconformance with the medical law. It will further help us to exchange the medical informationamong different entities e.g. doctors, hospitals, clinics, medical laboratories, medical researchers,government agencies and medical institutions according medical law. Other issues that are con-sidered include Portability of medical documents, availability, secure data-flow, authentication ofstakeholders, privacy management, patient’s preferences, data and document standardization andenforcement of policies and rules according to medical law for document and decision generationsto share information.

These elements will provide a critical road-map on how to build a healthcare application coveringthe necessities of the healthcare industry and allowing stakeholders to communicate clinical datalocally as well as exchange of medical information with other parts of the world. The goal of thisstudy is to seed Health Information Exchange (HIX) System. However, as we have stated, thechallenges are multifaceted and are extremely complex. We have implemented a small scale expe-rimental system called “Medical Drop Box” (MDB) as shown in fig.6.1. MDB can be envisionedas a portable folder which will enable any person to carry all his/her electronic medical informationand share it with his/her medical service provider. The beauty of this experiment is being able tolook us to look into some of the most critical elements needed for HIX System.

All healthcare providers must use the MDB application interface for HIX System, which is in theform of application software or web interface. According to the standard architecture, each entitycan access information in accordance with the rules and policies of the relevant country. Eachindividual possesses its own MDB, which receives information from the cloud repository and isaccessible from any country in the world, but only in accordance with the privacy regulations ofits homeland. The MDB is not simply the synchronization/sharing of information, but it provides



MDB

Doctors Office

ACTION REQ (HI Records)

Request for Patient History (1)

MDB Security Checks

Functions & Decisions

Document FormatsHL7 Standards, CCD

Validated HI Records

MedicalReports

ReleasableRecords

Authorization

Medications

Authentication

Notes

Insurance

MRIProcessingRequired

More ...

PersonalInfo.

Submit New Medical Records (3)

IndividualPreferences

MedicalRules

REQProcessing

RECORDProcessing

Receive Patient History (2)

Figure 6.1: Medical Drop Box Conceptual Design

controlled access to an individual’s information according to medical privacy laws, and allowsexchange of information in portable standards of HITSP, HL7 and ISO. To request data throughMDB, no formal procedures have to be followed. Whenever a medical healthcare provider dragsand drops information from and to the MDB, it is considered a request for information access andupdate, triggering the following procedure where each update in the MDB carries timestamps toindicate changes.

Each time the patient visits a doctor with the small magic key of his/her MDB (which uses a twoway authentication procedure for individual), the doctor’s office picks up all pertinent medical datafrom the MDB with the individual’s preferences (steps 1 and 2). After the treatment, the new in-formation moves into the MDB (step 3). These steps repeat every time the patient visits a newmedical facility and the MDB gets richer. In fig.6.2 different functions are performed internallyin the MDB. These functions will activate as the request is generated from any medical entityto access the MDB. These functions like Security Check, Medical Rules, Individual Preferences,Functions and Decisions, HL7 Standard Documents CCD or CCR Conversion and Document Re-lease are performed according to the requirement of the requester.



6.1.1 Security Checks

In this application we assume that all the medical entities are authorized and authenticated. But wewill adopt two way authentication procedures for the access to individual’s MDB.

6.1.2 Medical Rules in MDB with Example

Information from a request is preprocessed with a parsing algorithm to extract the input. On theseinputs, different conditions are tested and decisions are made according to these conditions. Wehave developed our algorithm in Python which is used to apply on the logical rules when a requestis received from some entity as shown in fig 6.2.

Pre-Processing

Medical RulesExtraction Algorithm

Individual'sPreferences

Medical HistoryHL7 Standards

MRI - Medical ReportsMedication - Insurance

Policies & Rules

Portable FormatMedical Documents

No

Requested Data

SecurityChecks

yes

DataProcess

ForDocuments

Decision

yes

Decision

Decision

RequestingEntity

RequestingEntity

Send

Figure 6.2: Request Parsing and Medical Data Processing Algorithm Flow for Request

After the pre-processing and security checks the first part of process requires “Medical Rule Ex-traction Algo” for the formalization of legal text to logical rules set for the decision on request fromsome medical entity for the use of information from MDB. In [64] we have developed World RuleModel (WRM) for the formalization of legal text to logical rule. It begins by generating differentconcept classes from medical law, extracting information and distributing it among these conceptclasses. Each rule or clause in these concept classes is identified by a tag and they are connected



together based upon how a request for protected health information is processed in medical law.At the end, we assemble the information together in a rule set to create logical rules that govern theimplementation of input and output. Generated information in the logical rule is used to processrequests in the second part of WRM. The transponder evaluates information from the requester,which includes but is not limited to, identity, purpose, type of information and authorization withgenerated logical rules. The transponder also works as a compliance checker between requestedinformation from one side and available patient medical data from the other side. Outputs aregenerated as a result of the decision made by transponder. The first output is “decision” which isused first to decide if the request would be denied or not, then how information is disclosed. Inaddition, we are able to produce an audit which indicates which rules triggered and explanation ofhow these are evaluated.



Categorization

Save Rules

No

XML Logical Rules

Read Next Rule (Yes)

Figure 6.3: Medical Rules Extraction Algorithm for Medical Entities

Rules from different sections of HIPAA are extracted using the algorithm in fig.6.3 of medicalrules processing function, which is implemented in Python. All the clauses in different sections ofLegal Text (HIPAA) are separated in XML “rule” tags. The information included in the “rule” tagsabout clauses for the decision are also added as XML tags. Each clause contains some keywordsfor logical rules. These keyword tags are possibly about a requester, the purpose of informationaccess, condition, action and cross referenced rules etc. These keywords tags may vary in the“rule” tag of each clause depending on the information in the specific rule or clause. These logical



rules are categorized into different medical entities for the fast retrieval of information. XMLlogical rules are separately stored into the transponder of the WRM modal for each entity in themedical drop box. Sample of rules that are generated in XML from HIPAA are shown below.

<rules>

<rule ruleid="164.1">






<CrossReference>164.5</CrossReference>


</rule>







</rule>

</rules>

The conditions related to different actors are marked separately as references to check the “rule”for that condition. For example the conditions tag in the above “rule” tag is hospital Law 2, whichis referring to some other rule for condition test. Different access level keywords are defined whichare used in the algorithm for the release or denial of information. These levels are considered underthe action for response to a request.

<AccessLevels>

<permission>

<word>may</word>

<word>might</word>

<word>can</word>

<word>could</word>

<word>would</word>



</permission>

<obligation>

<word>must</word>

</obligation>

</AccessLevels>

For example if the user who wants to disclose PHI as a researcher, then clauses related to researcherwill be extracted from HIPAA. Nevertheless, the researcher, as a requester of data, has the right toaccess any patient record items based on the authority and the purpose of this access. This meansall clauses that contain patient record items need to be formalized in this process. Having partialformalization would save time and money because we formalized a portion of the entire legal textto build one block. Once more resources are afforded, another block can be built, but currentlyonly clauses related to a certain requester are formalized and no more formalization to the patientrecord items. See rules filtering process in algorithm shown in fig.6.3.

<rule ruleid="164.10.a.3">


<Requester>researcher</Requester>

<Entity>lab</Entity>


<Condition>lab_Law_11</Condition>


</rule>

<rule ruleid="164.10.a.5">


<Requester>researcher</Requester>

<Entity>lab</Entity>


<Condition>lab_Law_12</Condition>


</rule>



6.1.3 Individual Preferences in MDB

An individual’s preferences are the privacy settings for medical data by individual. An individualcan manage his/her medical preferences about the data, electing whether to share with others ornot. In advanced countries like the USA, where the medical laws are properly implemented, theirlaws facilitate privacy rights. When a request is generated by any medical entity to access or releasemedical information, those medical preferences are also checked according to medical law. Thesepreferences are overlooked by the law in case of emergency or when data is required by the lawenforcement agencies.

6.1.4 Decisions Functions in MDB

To process a request there must be a response to release or deny, in other words, a decision isgenerated. So if the function takes the decision to release the information, then there will be aprocess that defines how to release and what to release. Similarly, if the decision is otherwise therewill also be the reason defined.

6.1.5 Clinical Document with HL7 Standard in MDB

As a Continuity of Care Record (CCR) is used to create the electronic summary of patient health.CCR contains information related to a patient such as demographics, insurance, healthcare providerinformation, medication lists, allergies, and any recent medical procedures.Continuity of Care Do-cument (CCD) is another similar standard for the Personal Health Information. It is conformant toHL7 standard/Clinical Document Architecture (CDA). We have developed and created the formatsof medical data into CCD, which uses the XML-based markup standard intended to specify theencoding, structure, and semantics of clinical documents for the exchange of medical information.That is why, the patient’s information can be shared by all computer applications, including webbrowsers, Electronic Medical Record (EMR) and Electronic Health Record (EHR) software sys-tems. The conversion of medical data into HL7 standard Clinical Document Architecture (CDA,CCD) has been adopted by advanced countries around the world.

In our research we have developed the Medical Drop Box that stores the personal information ofthe user and Medical related information in the form of CCD. To develop CCD we use the BaseXdatabase, which allows us to create the database information only in XML base. To exchange



the information among the medical entities, first we have create two XML files with the namesUsers.xml and Entities.xml. In the Medical Drop Box XML file for each user is created at registra-tion time that contains all the information related to the patient. This user file is updated accordingto the patient’s medical history. Similarly, an XML file for each medical entity is also created,which contains the history related to the medical entity. Logical rules related to medical entitiesare also in the form of XML and are placed in Medical Rules Engine used by the Medical RulesExtraction Algorithm. Below is the structure of the user profile stored in BaseX database in theform of XML.

<users>

<user MDB_ID="123" Password="123"/>

<user MDB_ID="15072014abc" Password="15072014abc">

<personalinfo>

<firstname>fname</firstname>

<lastname>lname</lastname>

<dob>15-07-2014</dob>

<maritalstatus>Single</maritalstatus>

<mothername>abc</mothername>

<fathername>abc</fathername>

<guardianname>abc</guardianname>

<gender>Female</gender>

</personalinfo>

<contactinfo/>

<employinfo/>

<preferences/>

<statistics/>

<miscellaneous/>

<insuranceinfo/>

<accounts/>

</user>

</users>

<admins>

<admin MDB_ID="admin" Password="admin"/>

</admins>



In this CCD all the history of the patient is added as different XML tags. On each visit thisdocument file is updated with a new time stamp and possibly a new disease tag, which also containsany prescriptions for medicine issued by the doctor. The user related CCD file also contains theinformation related to security and privacy to access user PHI.

6.2 Results

As the information stored in MDB is in the form of an XML Clinical document file with standardimplementation according to HL7, the data from XML files can be accessible through any webbased or desktop medical application so it can be easily exchangeable among different networks.As all the medical entities are using the MDB application in this research, the meaningful statis-tical information can be extracted by the medical entities for the future decision making in healthimprovement strategies. In addition, with the MDB there is a complete appointment and medicineprescription system internally to keep the complete record and to facilitate the patients.

(a) No. of Doctor’s Yearly Register in Pakistan (b) Doctor’s Registration in Different Cities

Figure 6.4: No. of Doctor’s Registration in Different Cities Yearly

In fig. 6.4a. the graph shows the number of doctors registered in the last ten years in Pakistan.Similarly, fig. 6.4b. shows the registration of doctors from five big cities of Pakistan. With thehelp of the MDB we can generate this information ranging from small cities to districts, provincesand the country level. We can separate any kind of information related to doctors, e.g accordingto specialty. The MDB helps us to make decisions for any situation in any part of the countrydepending upon doctor related data.

In fig. 6.5a. graph shows the number of patients visiting doctors in last five years in Pakistan.Similarly, fig. 6.5b. shows the number of patients visiting the doctors in different cities. We can



(a) No. of Patient’s Yearly Visited to Doctors (b) Patient Visit to Doctors in Different Cities

Figure 6.5: No. of Patient’s Registration in Different Cities Yearly

extract the information related to patients, (how many patients, which kind of diseases in patients,flow of patients in specific hospitals and more) from a small city, district, province up to countrylevel.

(a) No. of Medicine Yearly Used in Pakistan (b) Patient Used Medicine in Different Cities

Figure 6.6: No. of Medicine Used by Patients in Different Cities Yearly

In fig. 6.6a. graph shows that number of medicine consumed in the last five years in Pakistan.Similarly, fig. 6.6b. show the number of medicines used in different cities. From MDB we canextract the information related to medicine (which medicine is mostly used in which city, district,province and country level). The health department can make decisions about which medicinesare used in specific areas. Similarly, pharmaceutical companies can use this data for the purposesof analysis ( maintaining the demand and supply ratio, determining the success rate of a particularmedicine, analyzing the effect of a specific medicine in specific decease).

In fig. 6.7 a. graph shows the top ten doctors in Pakistan according to patient’s visits. Similarly,we can find the specialists in different areas of medical fields in different cities, districts, provinces



(a) Top Ten Doctors According to Patients’s Visit (b) Top Ten Diseases

(c) Top Ten Medicines Used (d) No. of Diseases Found in Patients

Figure 6.7: Top Ten Doctor’s, Medicines and Diseases in Pakistan

and at the country level. Fig 6.7 b. shows the top ten diseases in Pakistan. With the help of MDBwe can also extract the top diseases in any part of the word from city up to country level. This willhelp to find in which area which kind of disease is more active and can help in decisions to controldiseases and pre-cautions against shortages of medicines in that specific area. Fig 6.7 d. shows thediseases found in different cities. Similarly, fig. 6.7 c. shows the most used medicines in Pakistan.Any kind of information can be extracted using MDB by the health departments. This data can beanalyzed for future decision making.

6.3 Discussion

The main idea behind this research is to make the standard clinical document for medical data inexchangeable format according to HL7 standard and then share it among different medical entitiesfor their use according to the medical law. Each medical entity then uses this data for their purposesand to make future decisions.



The most important aspect of MDB is that the medical related information of an individual isavailable at all the times and everywhere in the world. The other aspect of MDB is for the useof statistical analysis of medical data for making decisions. Any kind of statistical informationcan be extracted and evaluated. For example, related to Doctors, Patients, Medicines , Diseases,Hospitals, Medical Labs, Lab Tests, Health Insurances, Medical Stores and more.

With the MDB “Statistical Analyzer” we can find doctors with their area of specialization or anyhospital in any city of the country. We can find the most used medicine in any specific area fromcity, district, province and country level.Pharmaceutical companies can extract this kind of data forthe purposes of analysis. For example, maintaining the demand and supply ratio in a specific area,observing the success rate of a particular medicine, analyzing the effect of a specific medicine inspecific decease and more. Most spreading diseases in any part of the world. With this kind ofanalysis helps to take decision for the control of specific disease, required medicines for specificdisease in that specific area. Similarly, the best hospitals, best insurance company, best labs formedical test providers and more success rates can be analyzed.

All the medical entities can analyze data related to their field and this data will help them to takefurther decisions and improve their facilities. Similarly, the health department of the country cananalyze all kinds of data to implement the government health policies.

6.4 Chapter Summary

All the data related to the patients are stored in the form of XML on the MDB cloud. So the data inthe form of XML can be presented to any type of medical application, i.e. a web based or a desktopapplication. As MDB is purely developed for medical data management and exchangeable withall concerns of individual’s privacy issues according to the medical law of the individual’s country.So the data are on the cloud and available all over the world all the time in some portable andexchangeable format defined in HL7 i.e. CCD or CDA.


Chapter 7

Medical Drop Box (MDB): For Exchange ofMedical Data

In this modern era of information and technology, the healthcare systems are extremely importantfor the well-being of any country, especially for developing countries like Pakistan [66]. The ma-jority of the healthcare industry in developing countries is working at a very poor level [67]. Thereis nearly non-existent use of Health Information Systems (HIS) even at the individual hospital le-vel [68, 69]. So, that’s why there is a need to improve the current healthcare system with latesttechnology.

Organized information can radically improve healthcare, just as much as the discovery of a newdrug or the invention of a new operational procedure. Tracing the human life cycle, if collected pro-perly, the size of medical and healthcare data, related to even one individual, can be humongous, of-ten reaching gigabytes, and provide extraordinary insight in planning the correct treatment. One’smedical information begins developing even before a person is born. In developed countries, whena baby is born, its information is stored in the Hospital’s Information System (HoIS). The volumeof information grows as the baby grows and keeps on growing until their death. The individualfaces various illnesses, hospital visits, doctors, undergoes different treatments, takes various labo-ratory tests, undergoes procedures, takes medicines all of which generate a wealth of information.An individual’s health data remains useful even after their death for his/her close relatives. A num-ber of hospitals in advanced countries are already archiving the patient’s information to their HoIS.Since there are billions of patients in this world and similarly thousands of healthcare providers,the task to archiving, integration and meaningful use and analysis of this data is difficult. Chapter

68

Chapter 7. Medical Drop Box (MDB): For Exchange of Medical Data

1 Figure 1.1 shows the whole cycle.

A healthcare system involves numerous types of entities ranging from patient, physicians, hospi-tals, insurers, employers, regulators, researchers etc. Thus, at the heart of it lies the framework(standards, protocols and information architecture) for information exchange. A full-fledged fra-mework addresses many issues such as ease of exchange, privacy of the individual, timeliness oftreatment, data access and delivery, availability, portability and security issues. In this research ourparticular focus is on an experimental framework focusing on exchange of individual identifiableinformation, which is the most critical type of information for improving the quality of treatmentfrom an individual’s point of view.

In Pakistan, like many other developing countries, there is a great awareness of the need to moder-nize the healthcare system, though there is yet no concrete plan like in the US. Hardly any of themajor healthcare facilities in Pakistan, particularly in government sectors, have an HIS in place. Inthe absence of any required standards and rules framework, there are only a few sporadic effortsto develop a local HIS in a few private institutions, but without the portability standards, thesesystems are not going to be interoperable and will not serve patient’s long term interest.

7.1 Material and Methods

The development of a comprehensive National Health Information Exchange (NHIX) is para-mount. In this research, we have proposed such a framework for Pakistan that will allow allentities (hospital, insurance, employers, doctors, labs, individual themselves, emergency room,and perhaps future home monitoring systems) to be involved in treating a person during his/herlifetime and to exchange information efficiently without violating the individual’s privacy con-cerns. This will dramatically improve the healthcare rights of every citizen of Pakistan. In the eraof globalization, when most of developed countries are building such an infrastructure, it is alsoimportant that the citizens of Pakistan are able to connect to the world’s medical infrastructure.

Due to the enormity in medical data management, we developed one of the most compelling ap-plication called “Medical Drop Box (MDB)”. This will involve the key technological componentsof a future NHIX system. The objective of this research is to develop a small scale experimen-tal system for the exchange of personally identifiable healthcare information between the patientand his/her service providers in the context of a future National Healthcare Information Exchange(NHIX) of Pakistan as shown in fig.7.1. MDB allows an individual to systematically receive all



MDB

Doctors Office

ACTION REQ (HI Records)

Request for Patient History (1)

MDB Security Checks

Functions & Decisions

Document FormatsHL7 Standards, CCD

Validated HI Records

Receive Patient Past History (2)

MedicalReports

ReleasableRecords

Authorization

Medications

Authentication

Notes

Insurance

MRIProcessingRequired

More ...

PersonalInfo.

Submit New Medical Records (3)

IndividualPreferences

MedicalRules

REQProcessing

RECORDProcessing

Figure 7.1: Medical Drop Box Conceptual Design

personal medical data, he/she has rights to (i) receive, irrespective of their type or format, (ii) ar-chive them indestructibly with security, privacy and individual control, and (iii) make it availableto other medical service providers through other relevant entities (such as through a close familymember in case of severe illness as ensured in patient’s rights).

Each time a patient visits a doctor or any other medical office which wants to access the patient’smedical data out of entity scope, the patient provides a small magic key of his/her MDB. The keywill be provided to the patient using two way authentication procedure. After the authenticationprocess, medical data from the MDB is accessible to the doctor/medical office with individual’spreferences (steps 1 and 2). The new information is updated into the MDB (step 3) after the tre-atment. These steps are repeated each time the patient visits any other new facility, the MBD getsricher. Different functions are performed internally in MDB as shown in fig.7.2. These functionsactivate automatically as the request will generate from any medical entity to access the MDB.These functions like Security Check, Medical Rules, Individual Preferences, HL7 Standard Docu-ments CCD or CCR Conversion, Lab Reports and Release of Documents, are performed accordingto the requirement of request.



National MedicalInformation Repository

Web InterfacesWeb Services

DevicesDrivers

NetworkInterface

SupportService

SoftwareApplicationInterface

Configure

Individual


Doctors

Govt. Agencies

HealthInstitution

1-FunctionsMessagingPolicies and RulesPreferencesImaging DocumentsCCR and CCD Format

2-SecurityAuthenticationData EncryptionSecure Data TransferPrivacy Management

3-PortabilityMetadataOntologiesData Standardization

Figure 7.2: NHIX Application Access with Medical Drop

7.1.1 Individual Preferences in MDB

Individual’s preferences are the privacy settings of medical data by individual. For privacy ma-nagement the individual can set his/her medical preferences about sharing data with the others ornot in MDB environment. When a request is generated by any medical entity to access or forthe release of medical information, those medical preferences are also checked. These preferen-ces for privacy settings are overlooked by law in case of emergency or data required by the lawenforcement agencies.

7.1.2 MDB Deployment and Dynamic Architecture

The patient’s medical data is updated in National Medical Information Repository through theRegional Health Information Exchange networks (RHIX). The regional networks are connectedto the NHIX for the exchange of information within the country as shown in fig 7.3. The NHIX(Pakistan) will be connected through international peering network with NHIX (World) which willmake the MDB information accessible from all over the world.




Doctors

GovtAgencies

Individual


Doctors

HealthInstitution

Doctors

Individual

NHIX DB

RHIX DBRHIX DB

RHIX DB

Figure 7.3: NHIX Deployment with Medical Drop

7.1.3 MDB Security Checks

In this application we assume that all the medical entities are authorized and authenticated. Butwe will adopt two way authentication procedure for the access of individuals MDB. Medical In-formation security is the most important part in MDB for data exchange.The information that isexchanged among medical entities should be considered trustworthy and secure. The securityrefers to three principles.

1. It must be ensured that the information is passed between participating NHIX organizations.

2. The information integrity passed across the NHIX must be ensured for every transaction.

3. Any information that is passed through NHIX can only be read and understood by participa-ting NHIX organizations.

The implementation of above mentioned qualities is possible through the creation of a trustworthyenvironment. Security of medical data at all levels must be ensured during access, transmission,and storage. Security gateways are implemented between the local area networks and internet thatseparate the MDB applications and database from the external networks of specific country, whichstops the visitors from directly accessing the country’s server. The servers are fully equipped withproxy, SSL and Virtual Private Network (VPN).

All medical information of patient is managed by MDB. Before an entity or a user executes afunction for access or to exchange the information, the access control list and authentication pro-



cess are executed to verify whether this entity has the permission to perform that operation. So theMDB makes sure that the entity is authenticated and legitimate to perform the particular operati-ons. Similarly when health information is exchanged and transmitted on the network, there is thechance of theft and decryption. Therefore the information is encrypted and transmitted on the SSLVPN. The privacy of individual/patient and authenticity of medical entity is very important.

7.1.4 Clinical Document Generation in MDB

Continuity of Care Record (CCR) is a standard defined by HL7, which is used to create the elec-tronic health summary of patient. It contains information of patient related to health, such ashealthcare provider information, allergies, medication lists, demographics, insurance and recentmedical procedures. Continuity of Care Document (CCD) is another similar standard which com-pletely satisfies HL7 standard i.e. Clinical Document Architecture (CDA). CCD format is used tocreate the medical data with MDB. CCD uses the XML-based standard to specify the structure,encoding and semantics of clinical document for the exchange of medical information. Due toXML based structure, patient’s information can be used by all computer applications, includingweb browsers and health software.

Medical Drop Box stores information in CCD format. MDB also uses a BaseX database that sto-res the information only in XML. In Medical Drop Box, the XML file for each entity is created atregistration,and contains all the information related to the entity, including the history of a medicalentity. Similarly, the patient’s file is updated after each medical checkup so that history is main-tained. Patient’s preferences and policies related to medical entities are also in the form of XML.The structure of the user/patient profile stored in BaseX database in the form of XML is shown asbelow.

<users>

<user MDB_ID="123" Password="123"/>

<user MDB_ID="15072014abc" Password="15072014abc">

<personalinfo>

<firstname>fname</firstname>

<lastname>lname</lastname>

<dob>15-07-2014</dob>

<maritalstatus>Single</maritalstatus>

<mothername>abc</mothername>



<fathername>abcd</fathername>

<guardianname>abcde</guardianname>

<gender>Female</gender>

</personalinfo>

<contactinfo/>

<employinfo/>

<preferences/>

<statistics/>

<miscellaneous/>

<insuranceinfo/>

<accounts/>

</user>

</users>

<admins>

<admin MDB_ID="admin" Password="admin"/>

</admins>

Clinical document is used by MDB to store medical data, which is created to follow the HL7standard shown in Appendix A.2. CCD contains all the history of the patient and each visit is addedas a different XML tag. On each visit, this document file is updated with a new time stamp andcontains information about diseases, doctors, prescriptions, medications, health service providertags, and the user/patient related CCD file also contains the information related to privacy andindividual preferences to access Health Information.

7.1.5 Duration

Duration can better be understood as data collection time and processing time.

7.1.5.1 Data Collection Time

The proposed system is not time bound in terms of data collection. Basically, the proposed systemcan handle data collected in any chunk of time in history. Currently the database of our system hasbeen populated for the purpose of testing and information generation with dummy data with realparameters that assures its capacity to deal the real data without any time constraints.



7.1.5.2 Processing Time

The proposed system has been built using the latest development tools to provide the best possibleprocessing speeds. Further improvements regarding hardware and software tools can be made asand when needed, depending upon the volume of data and the efficiency required.

7.2 Results

The Information stored in MDB is in the form of XML. The data from XML files can be accessiblein any web or desktop based medical application, so it can be easily exchanged among differentmedical networks. As all the medical entities use their own specific interface, each entity canonly access or share data in MDB through its interface. In this prototype, we have developed theinterface for Doctors, Patients, Labs, Medical Insurance Providers, Hospitals and Medical Stores.In Appendix A.2 Dashboard and Doctor’s interface snapshots are shown. In addition, there is acomplete appointment and medicine prescription system shown from the doctor’s and hospital’spoint of view that is implemented internally with MDB, which helps to facilitate patient recordmanagement. The graphs in fig 7.4,7.5 and 7.6 are just to show some statistical information fromMDB on test data. This statistical information shown in the form of graphs is just on simple data(as the test data is a database populated with dummy data for experimentation) as an example.More complex statistical information can be generated on live data through MDB.

(a) No. of Doctor’s Registered in Pakistan Yearly (b) No. of Patient’s Visits to Doctors Yearly

Figure 7.4: No. of Doctor’s Registration and Patient’s visits Yearly

In fig. 7.4a. the graph shows the total number of doctors registered in last ten years in Pakistan.In fig. 7.4b. the graph shows that number of patient’s visits to doctors in last five year in Pakistan.We can separate any kind of information related to doctors and patients. For example fig. 7.5a.



shows the registration of doctors from five big cities of Pakistan. Similarly fig. 7.5b. shows thenumber of patients’ visits to doctors in different cities. We can extract the information related topatients (how many patients, which kind of diseases in patients, the flow of patients in specifichospitals and more). Similarly, we can extract information related to doctors (related to medicalspecialization, availability of doctors, situations in remote areas and more) through MDB froma small city, district, province and up to the country level. This will help to make decisions onhealthcare situations in any part of the world.

(a) Doctor’s Registration in Different Cities (b) Patient Visit to Doctors in Different Cities

Figure 7.5: No. of Patient’s and Doctor’s Registration in Different Cities Yearly

(a) Most Common Diseases (b) Top Ten Medicine Used

Figure 7.6: Most Common Diseases and Medicine in Pakistan

Fig 7.6a. shows the most common diseases in Pakistan. We can extract the top diseases in any partof the word from city up to country level. This will help to find out in which areas which kindsof diseases are more active. We can take decisions to control those diseases and take precautionagainst the shortage of medicines in the affected area for specific diseases. Similarly, fig. 7.6b.shows the most widely used medicines in Pakistan. We can extract which of the medicines hasbeen most used in the last five years in Pakistan and which medicine has mostly been used in



different cities or in specific areas. Pharmaceutical companies have the advantage in analyzingthis kind of data for production (to control for shortage), the effectiveness of medicine on patients,comparisons against similar medicines in the market and more. Any kind of information can beextracted by the medical industry using the MDB and can be analyzed for future decisions.

7.3 Discussion

As the health of medical industry in the developing country is very poor, the idea behind this studyis to develop a prototype application for the medical industry of Pakistan. This application has theability to make standardized clinical documents for medical data in exchangeable format accordingto the HL7 standard. The MDB will be the first step to setup NHIX system. It is possible to sharethe clinical documents among different medical entities for their use according to the individual’sprivacy preferences settings within MDB. Each medical entity then uses the data, inputting datafor their purpose and analyzing the data to make future decisions.

The most important aspect of MDB is that the clinical documents of individuals are available inany part of the world. The other aspect of MDB is to be used for the statistical analysis on medicaldata for future decisions. All types of information can be extracted and evaluated for analysise.g. related to Doctors, Patients, Medicine , Diseases, Hospitals, Medical Labs, Lab Tests, HealthInsurances and Medical Stores.

With the help of the MDB “Statistical Analyzer” the health industry of the country can perform dif-ferent analysis related to doctors, medicine, hospitals, patients, birth rate, death rate, requirementof medicines, in any city, district, province and country level. The most used medicine in any cityto country level that can be used by pharmaceutical companies to analyze this kind of data. Mostspreading diseases can be pinpointed in any part of the world so as to be able to take decisions tocontrol the disease in that specific area.

The medical industry can analyze data related to their area and those analysis will help them in thefuture improvement of their facilities. Similarly, the other health departments and organizations ofthe country can analyze all kind of data to implement the government health policies in the country.



7.4 Potential Impact

Clinical Impact: The availability of patient’s medical records will create a more precise andaccurate treatment. The ability to electronically port medical information, such as imaging results,among different locations will significantly improve patient care especially in developing countries.

Business & New Services: International peering of NHIX’s will leverage cross border exchangeand trade of medical services. Patients from Pakistan can visit different parts of the world toreceive specialized treatment and a Multinational board of specialists may be formed more easilyto handle complex cases. Even an ordinary traveler will be able to travel worry free. If theyneed any emergency medical service from any part of world, critical medical information will beavailable everywhere. Medical information can travel seamlessly between his/her Pakistani doctorsas well as in medical industry.

Cost Impact: The infrastructure is expected to reduce the overall cost of medical services. Thiswill also reduce many redundant diagnostic tests. It will facilitate “paperless” automatic sharingof medical information between patients and doctor’s offices. The information will be much betterorganized and easy to retrieve, and thus will reduce clerical efforts.

Other Impact: NHIX can bring a fundamental qualitative improvement in healthcare with MDB.The national data can be a treasure trove for researchers to make fundamental innovation in findingdiseases and effective treatment methods. For Pakistan and developing countries, it will allowmedical services to expand into remote regions. It is also believed that the ability to access one’sown health information will create a new breed of culturally healthy citizenry.

7.5 Chapter Summary

The medical data of patients are available on MDB cloud in the form of XML. So this XML datacan also be used by any other medical application i.e. a web-based or a desktop application. MDBis purely designed and developed for the medical industry to manage data and also exchange thisdata with other medical entities. Individual’s privacy issues are considered according to the indi-viduals preferences. HL7 standards i.e. CCD or CDA formats are adopted in MDB for documentsto make its format exchangeable. Medical data is on the cloud and so available all over the worldall the time, which will help for the health improvement of not only that individual but also others



facing similar health issues. All kinds of analysis reports are presented for monitoring the healthof the nation and to facilitate decisions accordingly to resolve the problems.


Chapter 8

Medical Law Engine (MLE) for Privacy andAccess Control

This chapter presents a recommendation for a Medical Law Engine (MLE) that can be used toextract logical rules from medical laws. The MLE groups the medical laws then used in the ex-traction of rules to preserve the patient’s privacy and confidentiality. The proposed approach usesan XML format for storing the logical rules to generate decisions in case access is requested ofany particular patient’s information. All such requests from a participating entity traverse throughthe MLE in order to be granted access to the requested information. The Parts of Speech (POS)tagging algorithm is then used for logical rule generation. The proposed system is tested using theHIPPA privacy law of the United States. MLE is used by the Medical Drop Box (MDB) appli-cation (as discussed in chapter 7) to allow a patient to have access to his/her Clinical Document(discussed in chapter 6) through web-based or desktop applications. MLE would help to facilitateinternational exchange of information, allowing for prompt and proper treatment of a patient evenif outside of his or her home country.

8.1 System Methodology

The entities participating in the medical industry are almost the same all over the world. For thepurpose of this research, we assumed that every country has its own Medical Law Engine, whichdoes compliance checking separately according to a country’s medical laws.

80

Chapter 8. Medical Law Engine (MLE) for Privacy and Access Control

Rule ID or Clause ID

Cross References

Actor

Time

Purpose

Action

Condition

Figure 8.1: HIPAA rule with class representation

There are a number of actors/entities in the HIPAA that participate in different kind of activities.Each actor has a distinct role and purpose according to the regulations. Figure 8.1 shows the rulesrepresentation in HIPAA.

Khan et.al. have developed the World Rule Model (WRM) for the formalization of legal text tological rules from Medical Law (HIPAA) [64]. It begins by generating different concept classesfrom HIPAA, extracting information and distributing it among these concept classes. For com-pliance checking, the legal text of HIPAA privacy rules is formalized into eight different classes.These eight concept classes are 1) requester “ReqT”, 2) covered entity, purpose “PPT”, 3) patientpreference “PRI”, 4) condition “CT”, 5) action “AT”, 6) information procedure “IPT”, 7) time &fee “TFT” and 8) record release procedure “RR” class. Each rule ID or clause ID in the conceptclasses is assigned a unique TagID. Each rule is under any of the above mentioned classes. At theend, we assembled information together in a rule set to create logical rules that govern the imple-mentation of inputs and outputs. This is then used to process requests in the second part of WRM.We have assigned our own TagID to each clause and under that sub-clauses on a single level, thenused the rule ID reference with the TagID. Figure 8.2 shows the WRM Model with the completeMedical Law Engine processing components.



Figure 8.2: HIPAA (WRM) Rules Filtering Process Model with Law Engine Component

The Transponder is the brain of the Medical Law Engine (MLE). It evaluates requested informationfrom the requester, which includes but is not limited to identity, purpose of request, type of infor-mation needed, conditions for eligibility, and authorization with generated logical rules classes.Basically the Transponder works as a compliance checker between requested information fromone side and available patient medical data from the other side. Outputs are generated as a resultof the decision made by Transponder. The first output is related to the “decision” which is fromthe action class. It is then used to determine whether the request would be denied or not, howinformation will be disclosed and what information will be provided to the requester.

8.1.1 Mathematical Model for Rules Extraction

Let’s take a given text document Di is a legal text document. Firstly, sentence token ST areextracted from Di as ST = {ST1 , ST2 , ......STn}, where n is the number of sentence token. Forsentence token we have used “.” as stopping word. Every sentence token ST is used to produce

word token WT . So WT =n⋃

j=1

{ s⋃k=1

Token(STj

)}, where s is the number of words in each

sentence.



We generate a set of Part-Of-Speech (POS) Tags by using AccessLevel dictionary ALD using POSTagging algorithm 4 for rule generation. A sample from AccessLevel dictionary is shown in Table8.1.

Table 8.1: Sample of AccessLevel (AL) Dictionary

AL Types AL Value Matching Words Example

RuleID Rl Rule Numbers: i.e. 164.126.1, 164.128.2 etc.Permission Pm may, might, can, could, would etc.Obligation Ob must, shell, should etc.Action Ac release, allow, not allow, deny etc.RecordItems RI HIV, Heart, infection etc.Negation Ne should not, would not, shall not, etc.Condition Co authorization, permission, etc.CrossReference Cr Other Rules refer in current rule 164.128.1.a etc.Purposes Pr Access, Treatment, amendment etc.

We have set of classes C = {C1, C2, ......Cl} for which we need to generate rules, here l = 8. Allrules are classified into eight classes i.e.C =

{{C1ReqT

}, {C2PPT}, {C3PRI

}, {C4CT}, {C5AT

}, {C6TFT}, {C7IPT

}, {C8RRT}}

.The details about the classes are explained in section 8.1.

By using the POS-Tags we generate Rpq rules for each class available in Di i.e. ∀C ∈ Di. Valueof p in Rpq is 1 ≤ p ≤ 8 for number of classes, and value of q is 1 ≤ q ≤ t where t is the

number of rules generated for each class. So Rpq = Tf

(CT(POS − Tag

))a−1

b

where CT ∈ C,

b = occurrence of Rule-Id, and a = occurrence of next Rule-Id. Presence of Rule-Id serves ascurrent rule. Tf is the Transformation function to the given rules pattern/template in XML. The

rules generated in XML tags through Transformation function as T (x) =6⋃

o=1

(< tago > CTo <

/tago >)⊔(⋃

o=7

( r⋃u=1

(< tago > CTo < /tago >

)))tag8 ⇔ ∃CT8 ∈ tag1

⊔(⋃o=8

( s⋃u=1

(<

tago > CTo < /tago >)))

. Where tag8 ⇔ ∃CT8 ∈ tag1 implies that tag8 will create CT8“CrossReference” if and only if (iff) there exits ruleid in tag1. The details of the XML tags aredefined in Table 8.2 with descriptions and example.

Let the query Qi is used to process incoming request through fig.8.3 algorithm. Query Qi =

{QC/E

⋃QA} where QC/E

⋂QA = φ based on Pc(QC/E) and Pc(QA). we decide whether



Table 8.2: Details of Tags Representation with example

Tags Tag Value Description Example

tag1 Ruleid Rule Number in Document, i.e. 164.1 etc.tag2 Request Purpose of request, i.e. Access, Treatment etc.tag3 Requester Requesting Entity, i.e. Researcher, Doctor etc.tag4 Entity Data Providing Entity, i.e. Hospital etc.tag5 RecordItems Required Data Type, i.e. HIV, Heart patients etc.tag6 AccessLevel Actions To be performs, i.e. Release, denied etc.tag7 Condition Conditions for Request, Requester, Recordtag8 CrossReference Other Rules refer in current rule

query should be processed or not. In this Pc(QC/E)= {Requester Pre-Conditions, Purpose Pre-Conditions, Record Items, Request Pre-Conditions} and Pc(QA) = {Requester Authentication}.

Rules set Rk for each entity Ex are represented as R = {R1, R2, ......Rk} where for each ruleRx is 1 ≤ x ≤ k. When a request is processed through query Qi for a particular entity Ex,the Request Processing Function extract the rules for that particular entity. if (Purpose(Rx) ∧Condition(Rx) ≈ (Purpose(Qi) ∧ Condition(Ri)where∀Rx ∈ Ex.

The POS Tagging algorithm accepts two files: 1) The file to be tagged Di and 2) The wordsdictionary Wtd which includes the AccessLevel dictionary ALD.

Rules from different sections the HIPAA are extracted using the algorithm in fig.8.3, which isimplemented in python and BaseX Database is used to store XML generated rules. All the clausesin the different sections of the HIPAA are separated by XML “rule” tags. Each clause of HIPAAcontains some keywords for logical rules. These keywords can be about a requester, the purposeof information access, condition, action and cross referenced rules. These keywords used in theXML tags may vary in the “rule” tag of each clause depending on the information in the specificrule. These logical rules are categorized into different medical entities for the fast retrieval ofinformation. The XML logical rules are separately stored into the transponder of WRM modal foreach entity. The conditions related to the different actors are marked separately as references tocheck the “rule” for that condition. Samples of the logical rules for different entities are presentedin Appendix B.

<rules>





Data: Input: Legal Text File Di, Tag–Dictionary File = Wtd + ALD

Result: Generate the Tagged DataInitialization: raw sentence str File – a list of characters;candidate sentence citem – a list of (word, tag) pairs;maximum word–length record maxwlen for each tag;the Tagging rules list rulesTemp;the tag dictionary tagdict;start index for current word;end index for current word;rulesTemp[0] = [];rulesTemp[i] = [](i 6= 0);Algo: str ← String Tokenized(Di);for end index = 1→ str.length do

forall tag dofor start index = max(1, end index−maxwlen[tag] + 1)→ end index do

word = str[start index→ end index];if (word, tag) consists in tagdict = Wtd +ALD then

for citem ∈ rulesTemp[start index− 1] doitem1 = citem;item1.append((word,tag));rulesTemp[end index].insert(item1);

endend

endend

endOutput: rulesTemp[str.length].best tags

Algorithm 4: The POST Decoding Algorithm



Data: Input: Rule Pattern File RPF , POST Data File POStagF

Result: XML Based Logical RulesStep 1 Read RPF to Extract Rp (Rule Pattern);Read Rp and Placed in a List Rcl;Step 2 Create Lists Lm where 2 ≤ m ≤ n n is the no. of Component in Rule Pattern;forall Ruleid from POStagF do

Read Ruleid Ri;Read Words Wi Corrsponding to Rcl[p] 1 ≤ p ≤ n;Add it into its Revelent list Lp;rule =< Ruleid > Ri < Ruleid >;if length of each list Li is 1 then

use each list Li ;rule = rule+ < Rcl[i+ 1] > Li[1] < Rcl[i+ 1] >;

endelse

if Length of L2 > 1 thenlen = length(L2);Generate len many copies of Rule ;Rule1 = rule;Rule2 = rule;· · · ;· · · ;Rulelen = rule;

endwhile t = 1→ len do

Rulet = Rulet+ < Rcl[2] > L2[t] < Rcl[2] >endforall Rulet where 1 ≤ t ≤ len do

forall List Li where i > 2 dowhile s = 1→ Lenght(Li) do

Rulet = Rulet+ < Rcl[i] > Li[s] < Rcl[i] > + newline;end

endend

endendOutput: XML Logical Rules Pattern Generated;

Algorithm 5: The XML Logical Rule Generation Algorithm





Categorization

Save Rules

XML LogicalRules

No Allowed

Sa v

e

Med

ical

Ru

le

Request

Allowed

Validate

Ru

les

Figure 8.3: Medical Rules Extraction and Request Processing Algorithm Model







</rule>

</rules>

Different “Access Level” keywords are defined, which are used in the algorithm for the releaseor denial of information. These levels are considered under the action class for response on therequest. An example of the different “Access Levels” are shown in fig 8.4.

8.1.2 Request Processing through MLE

Information from a request is preprocessed using the parsing algorithm to extract the input. Onthese inputs, different conditions are tested and decisions are made accordingly. We have develo-ped our algorithm in Python and applied when a request is received from an entity.



Data: Input: User Request Along Request Info URI , Medical Rules MR

Result: Requested Medical Data Release or DeniedStep 1: Medical Data MD ← Null;Step 2: Parsing the URI for Information Extraction

Parsed Data PData to Obtain =

Requester Entity REI

Requesting From Entity RFI

Purposes PPurpose

Record Items RItems

Record Format RFormat

Step 3: Divide Parsed Data PData into two group of functions(1)− Check Authorization(REI ,MR)←− returns 1(2)− Check Eligibility(RFI , PPurpose, RItems,MR)←− returns 1 ifCheck Authorization(REI ,MR) == 0 then

Not Authorized;return MD;

endif Check Eligibility(RFI , PPurpose, RItems,MR) == 0 then

Not Eligible for this request;return MD;

endif Check Eligibility() && Check Authorization() == 1 then

Check the User’s Preferences from Records;Check Preferences(RItems)←− returns PREData ;Arrange the Medical Data in Required Format;Data Format(RFormat, PREData)←− returns MData;MD = MData;return MD;

endOutput: Medical Records

Algorithm 6: Request Processing Algorithm



Figure 8.4: Access Levels from Action Class in XML Logical Rules

Example: Figure 8.5 explains an example from HIPPA in which the requester is a Researcher.The example elaborates in the form of a modal to explain the flow of the different rules. In HIPAAcomplete guidance is available when a request comes for research purposes from any Researcher.

When a request comes from Researcher, heshe must provide a summary of the intended data usage,a brief description of what patient data is required and in what type of format (i.e. electronic orprint). According to the HIPAA rules, entities must provide medical data for research. HIPAA re-quires authorization before anyone’s health information is used for research purposes. Authoriza-tion must be requested from the researcher by the record releasing entity/covered entity(hospital),including how the information will be used in hisher research. Authorization is taken by researcherfrom his institute after the patient’s consent. If no authorization is provided by the Researcher thenthere are some waiver rules to test the request against. The record releasing entity must release thede-identifiable data or limited data for research. Table 8.3 shows the comparison of data elementsthat should be removed or included for de-identifiable data and limited data.

Table 8.3: A comparison between De-identifiable and Limited Data

S.No Data Attributes De-identified Data Limited Data

1. Name, All type of address, city and Zip Codes Remove Remove Home, Street No.2. All data related to date except years Remove May included if needed3. All contact number like cell, fax, email etc. Remove Remove4. ID Card, Any Account Number, Medical Number etc. Remove Remove5. License, Health Plan, Vehicle Numbers etc. Remove Remove6. Biometric Identification, Photograph etc. Remove Remove7. Any identifiable number or characteristic Remove May include

In the figure 8.5 example, Request is processed through Request Processing Algorithm 6. Parsingprocess should be done on the request to extract the data: like who is the requester, Purpose list,



Request FromResearcher

Process

Check Conditions Rule

Actors List Purpose ListPatient Record

Items

Patient Billing HIV

Doctor Payment Physiotherapy

Nurse Treatment ENT

.... .... ....

Check Wavier

Decision

If N

o

No

Sat

isfie

d

Rule IDIn

RequestBy Rule Need

Referance Rule

Condition

(164.512) i . 1 Yes Yes

(164.508) (b).3.i No Yes Wavier Rule Test

(164.508) (c).1.v No Yes Wavier Rule Test

(164.508) (b).4.i Yes Wavier Rule Test

(164.508) (b).4.i No Yes Wavier Rule Test

(164.512) (i ). 2. i i i Yes Wavier Rule Test

(164.512) (i ). 1 Yes Wavier Rule Test

(164.512) (i ). 1. i i .A, B & C

Yes

164.514 (d).ii i .D Yes

164.514 (e).3.i Yes Yes

(164.512) i . 2 Yes Yes

164.532 (b) Yes

Rule ID By Waiver ActionYes Allowed

Yes Allowed

Yes Allowed

Yes Allowed

Yes Allowed

Yes Allowed

Yes

Document required for the min requirement of research related activity

Rule Discription

Request is from researcherAn authorization for the use or disclosure of protected health information for a researchNon-expired Authorization is Required

Covered entity may condition research treatment

Researcher meet the conditionsA brief description from the researcher regarding protected health information for ResearchHealth provider allow the use of protected health information for research?Protected health information required for the success of this research

(164.512) i . 1. i Board approval of a waiver of authorization for this kind of

research

(164.512) (i ). 2. i i i

(164.512) (i ). 1

(164.508) (b).4.i

(164.508) (b).4.i

(164.508) (c).1.v

(164.508) (b).3.i

A covered entity may use or disclose a l imited data set

wavier going to be used

Restrict to disclosure of information if individual restricted

Rule Discription Rule under Waiver

if N

o

If N

oIf

Nul

l or

No

If N

oIf

Nul

l

If Null

Decision

Con

tinue

to n

ext r

ule

Output:Information Released Procedure According to Rules - Released Decisionif all satisfied

If n

ot s

atis

fied

Output:Information Released Procedure According to Rules - Denied

Figure 8.5: Request Processing for Researcher with MLE Model

Patient Record Items and data format to release records. After parsing the request, rules are testedon different conditions for Requester’s authentication and authorization, Purpose, Record Itemswith the Medical Law Engine. If all the conditions are fulfilled by the researcher in the request, therequested data will be released according to the requested format. Otherwise, the MLE checks ifthere is a waiver associated to the request. If there is none, it is only then that the request is denied.

Based on the MLEs decision, a process for preparing a response will be followed. If the request isapproved, this process will define which data will be released and what will be released. If denied,then the reason for this will be added in the response.



8.2 Algorithm’s Results and Discussion

There are three algorithms introduced in MLE development. Algorithm 4 corresponds to the POStagging process, Algorithm 5 is used to generate the XML logical rules and Algorithm 6 explainshow a request is processed in order to produce the result.

8.2.1 Decoding Algorithm

The decoding algorithm for the segmentation and POS tagging system is one of the main challengesin developing the MLE because the accuracy and speed of the decoder is very important. For POStagging, the algorithm covers a very large search space with different combined candidates. Ouralgorithm currently works in a linear manner using rules templates, and it is difficult to get exactsuggestions for the POS tags. In the future this can be achieved with some learning algorithms andsome extra feature selections.

8.2.2 Optimization

We optimized the program using coding techniques so that it is able to produce better results evenwith large scale data. In the case of POS tags, they are represented with strings and the algorithmshave to perform many comparisons between the tags. This was optimized by assigning an integervalue or index value to a tag in order for it to perform faster. Similarly, rules templates were usedfor the evaluation. Python built-in NLTK libraries are also very helpful in POS Tagging.

8.2.3 Part-of-Speech Tagging

The first step in implementing the MLE, Algorithm 4, uses part-of-speech tagging to build a wordslist. This will then be used for POS tagging. There are many ambiguous words and each wordcan belong to several classifications. For example, “Note” can either be treated as a verb or anoun. Thus, the objective of POS tagging is to resolve ambiguities by understanding the contextof each word. There are two approaches used in POS tagging: 1) Rule-based and 2) Stochastic.In this paper we adopted the rule-based approach, with rules generated using some transformationfunction of tags for each class.



8.2.4 Tagging of Unknown Words

We have developed our own Accesslevel dictionary to deal with unknown words related to medicallaw by understanding each words context during discussions with experts. For some of the words,we simply assigned it to the most common POS and trust the rules for the correction of errors.Algorithm 4 is implemented with Python NLTK using our own AccessLevel dictionary for POStagging.

8.2.5 Test Results

The POS tagging algorithm was tested on multiple sections of the HIPAA. We found that thereare 683 clauses from Section 164.502 to 164.534. For POS tagging, more than 112,000 words areextracted. The system was first tested on each section of the HIPAA to verify the results. Errorswere analyzed and it was found that 26% of the errors were due to unknown words. A separateAccessLevel dictionary is created for the proper understanding of medical law terminology whichare treated as unknown or ambiguous words in the NLTK. New unknown words were added inthe AccessLevel dictionary for each section to decrease the percentage of errors. The POS taggingalgorithm takes two files as input: 1) the file to be tagged and 2) the words dictionary extended withthe AccessLevel Dictionary. The Output, on the other hand, is a Tagged Data File which containsthe information for each word. The best result for each section was 2.3% for general tagging errorsand 3.6% for specific tagging errors.

After the POS tagging algorithm, the XML logical rule generator (algorithm 5) generates the logi-cal rules by taking the Tagged Data File and Rule Template File as input. The XML logical rulesfor each medical entity are generated as output of the algorithm.

Finally, the request processing algorithm process the requests. This algorithm is activated as thesystem receives a request for data from any entity. This algorithm is a key point of the MLE as itproduces the results according to the law.

8.2.5.1 Open Vocabulary Test

Open Vocabulary is used to find the performance of the tagging algorithm. It means that we did notcreate the AccessLevel dictionary and therefore the ratio of unknown words of about 26% exist.



Accuracy without AccessLevel DictionaryKnown words: 78%Unknown words: 53%All words: 81%

8.2.5.2 Closed Vocabulary Test

This test is performed for the POS tagging algorithm, and checks if there are no unknown wordsremaining in the text that will be tagged. The result is shown in a percentage of correctly taggedwords by the tagging algorithm and is referred to as tagging accuracy. After applying the rulestemplate on the tagged data, the accuracy of the XML logical rules generated is considered asXML rules accuracy

Accuracy with AccessLevel DictionaryTagging Accuracy : 88%XML Rules Accuracy: 91%

Figure 8.6: Open and Close Vocabulary Test for Algorithms 4 & 5

Figure 8.6 shows accuracy percentages, achieved using the Open (i.e. without the AccessLeveldictionary) and Closed (i.e. with the AccessLevel dictionary) vocabulary tests. It is clear from thefigures that in the Open Vocabulary test, where the Accesslevel dictionary is not used, a higher levelof accuracy is harder to achieve for tagging the data and generating XML logical rules. However,an improvement in the tagging result has been observed in the closed vocabulary test due to the useof AccessLevel dictionary. Test 1 in the given figure represents a scenario wherein the number of



known words (dictionary size) is limited in comparison to the Open Vocabulary test. The numberof known words had been increased in Test 2 to Test 5, and it can be seen that the results havesignificantly improved, with Test 5 being the best.

8.3 MLE Deployment with Medical Application

Formalizing the legal text into an automated rules set for compliance checking will help us for theimplementation and document generation that conforms with medical law. It will further help us toexchange medical information amongst different medical entities (e.g. doctors, hospitals, clinics,medical laboratories, medical researchers, government agencies and medical institutions) as shownin figure 8.7.

PublicOrganization

Hospital Services

Web Portal

Clinical ServiceProvider

Pharmacy

Society HealthCenter

Mobile Doctors

Doctors Office

Request forPatient History (1)

Receive PatientPast History (2)

Submit NewMedical Records (3)

Figure 8.7: Medical Law Engine Deployment Design

We implemented a small experimental medical application called the “Medical Drop Box” (MDB)discussed in chapter 6. With it patients are able to access hisher electronic medical informationand share it with his/her medical service provider. All healthcare providers must use the MDBapplication interface and each entity can access the information in accordance with the rules andpolicies of the relevant country’s Medical Law. The MDB also provides controlled access to anindividual’s information according to privacy laws, and allows exchange of information in portablestandards of HL7. Continuity of Care Document (CCD). The HL7 format is used to create themedical data with MDB. CCD uses the XML-based standard to specify the structure, encodingand semantics of clinical documents for the exchange of medical information.



To request data through the MDB, a medical healthcare provider drags and drops information fromand to the MDB. This action is considered a request for information access and/or update. Butthe MLE verifies the request with the patient’s corresponding medical laws in his/her county forcompliance. For example, in figure 8.7, when a patient visits a doctor with a small password keyof his/her MDB using a two-way authentication procedure for individuals, the doctor’s office picksup all pertinent medical data from the MDB with the individuals preferences (steps 1 and 2). Afterthe treatment, the new information moves into the MDB (step 3). These steps repeat every timethe patient visits a new medical facility, enriching the content within the MDB.

The information stored through the MDB is in the form of XML as a clinical document file foreach individual. The data from XML files can be accessible through any web-based and/or desktopmedical application, so it can be easily exchange among different networks. Similarly, the logicalrules generated are also in XML-based architecture. Samples of Clinical document and Logicalrules for Individual/user are shown in Appendix A and B respectively.

8.4 Chapter Summary

The demand for medical data exchange among different countries is becoming greater. As a largernumber of people travel abroad, it is unavoidable that they need to visit hospitals. In such cases thedoctors may need to have access to the patient’s medical history in order to offer proper treatment.To facilitate this, clinical data must be exchanged internationally [10, 52].

Healthcare data is one of the most sensitive types of data that can be exchanged, but if there isa standard medical application and Medical Law Engine (MLE) working for each country therequested for medical data can be handled in accordance with privacy laws.

Our recommendations for the MLE includes deploying it using SOA (Service Oriented Architec-ture) based architecture as a web service. All the data related to the patients will be stored in theform of an XML clinical document file stored in the cloud. In this way, the data can be presentedthrough any type of medical application (i.e. web-based or desktop)

Another important aspect of the MLE is the development of the Medical Drop Box (MDB), inwhich medical-related information of individuals can be accessed at all times. We created a stan-dardized an exchangeable clinical document for medical data that is in accordance with the HL7standard, and which can be shared with different medical entities.



Once implemented, the MLE and MDB will allow fast access to and exchange of medical infor-mation while ensuring that no medical privacy laws are violated, regardless of the country whereit will be accessed.


Chapter 9

Conclusions and Future Directions

In Pakistan, like many other developing countries, there is a great awareness to modernizing theirhealthcare system, though there is yet no concerted plan like there is in the US. Hardly any of themajor healthcare facilities in Pakistan, particularly in government sectors, has an HIS in place. Inthe absence of any required standards and rules framework, there are only a few sporadic effortsto develop a local HIS in a few private institutions. But without the portability standards, thesesystems are not going to be interoperable and will not serve patients long term interest.

The development of a comprehensive National Health Information Exchange/ Network (NHIX/N-HIN) is paramount. In this research, we have proposed such a framework for Pakistan that willallow all entities (hospital, insurance, employers, doctors, labs, individuals themselves, emergencyrooms, and perhaps future home monitoring systems) to be involved in treating a person duringtheir lifetime, and to exchange information efficiently without violating the individual’s privacy.This will dramatically improve the healthcare rights of every citizen of Pakistan. In the era ofglobalization, when most of developed countries are building such an infrastructure, it is also im-portant that the citizens of Pakistan to be able to connect to the world’s medical infrastructure.As we have explained, the proposed research will enable Pakistan’s medical information to beinteroperable with other world systems.

97

Chapter 9. Conclusions and Future Directions

9.1 Potential Impact of Research

1. Clinical Impacts: In the long run, we expect the implementations of the MDB will put Paki-stan’s healthcare system on a confident footing towards twenty-first century modernization.The availability of patient’s medical records will create a more precise and accurate treat-ment. The ability to electronically port medical information, such as imaging results, amongdifferent locations which will significantly improve patient care especially in developingcountries.

2. Business & New Services: International peering of NHIX will leverage the cross borderexchange and trade of medical services. Patients from Pakistan can visit different parts ofthe world to receive specialized treatment. A multinational board of medical specialists mayeven be formed to more easily to handle complex cases with an information network thatextends around the world. Even an ordinary traveler will be able to travel worry free. If atraveler were to need any emergency medical services in any part of world, critical medicalinformation will be available, no matter where. Medical information can travel seamlesslybetween patient’s doctors.

3. Cost Impacts: The MDB infrastructure is expected to reduce the overall cost of medical ser-vices. In part, the reduction will be due to the reduced occurrence of redundant diagnosticstests. Another factor in the reduction of costs will be due to paperless medical records. TheMDB will facility ”‘paperless”’ automatic sharing of medical information between patientsand doctor’s offices. Information will be much better organized and easy to retrieve, and thuswill reduce clerical efforts.

4. Other Impacts: NHIX/NHIN can bring a fundamental qualitative improvement in healt-hcare. National medical data can be a treasure trove for researchers interested in makingfundamental innovations in finding disease patterns, or in locating effective treatment met-hods. For Pakistan and developing countries, the MDB will allow medical services to expandinto remote regions because the cost of services will be reduced. Additionally, there is evi-dence that individuals will make more responsible and aware health decisions when theyare able to monitor and manage their own medical information and records. A new breedof culturally healthy citizenry would reduce a country’s overall medical spending, freeingup investment for other improvements. Shortages of personnel in medical fields would nolonger be a cause for panic, as there would not be as many requirements, if citizens werehealthier.


Chapter 9. Conclusions and Future Directions

5. Global Tech Transfer: Interestingly, many developing countries are at a very similar stageto Pakistan in developing their medical records systems. However, Pakistan’s strong nationaldesire to modernize its healthcare system with information technology means that it is a per-fect location to begin this project. The international climate is primed for the disseminationof the MDB and NHIX/NHIN once it is implemented in Pakistan.


Appendix A

Decision Tree Data, A Clinical Documentand Logical Rules Samples

A.1 Decision Tree and Rules Flow: Examples

Here we have detailed diagrams related to rules those are generated from HIPAA for the individualwho wants to access his own PHI from Decision Support System as a test case. We also present therules for Researcher, Health Sponsor and the Patients in Emergency. We also present the DecisionTree of rule generation from the point of view of an individual wishing to access his PHI. Thesediagrams are presented in sequence below.

1. The Patient/individual Access Decision Tree rules data that are generated from HIPAA toAccess his own PHI

2. The flow of researcher rules that are generated in HIPAA

3. The flow of Plan Sponsor rules that are generated in HIPAA

4. The flow of Patient in Emergency rules that are generated in HIPAA

5. Decision Tree for the rule generation for Access

100

S. No Requestor Purpose ItemsReq

ConditionPre

ConditionPurpose

ConditionTime

TakenAction Info Release Fee Information Produced

1 Patient PPT1 Any Item ReqT1 PCT1 ~CPT1 TT3 AT4 RR1 FT1" RRT1 " ^ " TT3 || TT3 ^ TT7 ^

TT8 " ^ " FT1"


TT8 " ^ " FT2 "


TT8 " ^ " FT3 "


TT8 " ^ " FT1 "


TT8 " ^ " FT2 "


TT8 " ^ " FT3 "


TT8 " ^ " FT1"


TT8 " ^ " FT2 "


TT8 " ^ " FT3 "


TT8 " ^ " FT1 "


TT8 " ^ " FT2 "


TT8 " ^ " FT3 "

13 Patient PPT1 Any Item ReqT1 PCT1 CPT4 TT3 AT2 IPT2-3-4 FT4 " IPT2-3-4 " ^ " TT3 " ^ " FT4"

14 Patient PPT1 Any Item ReqT1 PCT2 CPT4 TT3 AT2 IPT2-3-4-5 FT4 " IPT2-3-4-5 " ^ " TT4 " ^ " FT4"

Decision Tree Data : (164.524) Access of individuals to protected health information








22 Patient PPT1 Any Item ReqT1 PCT2 CPT8 TT3 AT3 IPT2-3-4-5-6 FT4" IPT2-3-4-5-6 " ^ " TT4 " ^ "

FT4"



FT4"



FT4"

27 Patient PPT1 Any Item ReqT1 PCT1 CPT11 TT4 AT5 IPT1,RR1 FT4" IPT1 " ^ " RR1 " ^ " TT4 " ^ "

FT4"


FT4"


FT4"

Rule 1 :(164.508) (b).3.i An authorization for the use ordisclosure of protected health information for a research

Is authorization OR a combined authorization available for thisresearch?

In RequestBy Rule

Response Extra Condition by Rule

Yes Yes

ProcessRequest FromResearcher

request

Researcher Related Rules In HIPAA

Rule 3 : (164.508) (c).1.v Non-expired Authorization isRequired

Is Authorization expired ?

In RequestBy Rule

ResponseExtra Condition by Rule

No No

Check Rule

Rule 2 : (164.508) (b).4.i Covered entity may conditionresearch treatment

Is there any condition for this particular research from Health careprovider?

In RequestBy Rule


No

Rule 2.1 : (164.508) (b).4.i Condition for researcherDoes the researcher meet the conditions?

In RequestBy Rule


Yes Yes

DecisionIf No continue check Rule

Rule 4 : (164.512) (i). 1 Covered entity may use informationfor research

Does Health provider allow the use of protected health informationfor research?

In RequestBy Rule


Yes

DecisionIf yes continue check Rule

DecisionIf No continue check Rule

DecisionIf yes continue check Rule

Rule 8 : (164.512) (i). 1. ii.A, B & C Reviews preparatory toresearch, purpose of research.

Is the Protected health information required for the success of thisresearch

In RequestBy Rule


yes yes

DecisionIf No Access denied

DecisionIf Yes continue check Rule

Output:Information will be released according to Rules - Denied

If ye

s co

ntin

ue

If ye

s C

heck

Wav

ier

If N

o C

heck

Wav

ier

If ye

s C

heck

Wav

ier

If N

o C

heck

Wav

ier

Rule 9 : (164.512) (i). 1. ii.A, B & C Necessary research to userin other

Is this type of research is helpful or necessary for other research?

In RequestBy Rule


yes yes

If N

o C

heck

Wav

ier

Rule 10-11 : (164.512) (i). 1. iii Research on Decedent'sRequirements

Does this research need the decedent's protected health information?

In RequestBy Rule


No No

Continue

DecisionIf yes verify- continue to rules

Output:purpose+documentation+necessity of research ( covered entity obtain from researcher)

If N

o C

ontin

ue

Rule 16 : (164.512) (i). 2. iii Description research of usedpurposes

Is there brief description from the researcher regarding protectedhealth information

In RequestBy Rule


No Yes

DecisionIf yes verify- continue to rulesIf

No

Che

ck th

eW

aive

r

Rule 20 : 164.514 (d).iii.D Document required for the minrequirement of research related activity

Is there brief description from the researcher regarding protectedhealth information

In RequestBy Rule


Yes Yes

DecisionIf No

Output: Denied research Activity ( covered entity obtain from researcher)

If ye

s C

ontin

ue

Rule 21 : 164.514 (e).3.i A covered entity may use or disclosea limited data set

Does the minimum data required for research?

In RequestBy Rule


No Yes

Rule 5 : (164.512) i. 1. i Board approval of a waiver ofauthorization

Is the wavier applied?

In RequestBy Rule


No yes Provide -

No Yes

No Yes

Yes No

Yes No

No Yes

Yes Yes About Wavier

Output:Information will be released according to Rules

Rule 12-15 : (164.512) i. 2 Documentation of waiver approvalIs wavier going to be used?

In RequestBy Rule


yes yes


Output:Documentation of Wavier and action date + Other Information related to wavier

If N

o


If N

o

Rule 26 : 164.532 (b) Restrict to disclosure of information ifindividual restricted disclosure

Does the user request his data to be restricted from research?

In RequestBy Rule


No

Output: That User Information will not be shown in result

DecisionIf yes

If N

o

Rule 1 : 164.308 (b).2.ii Insurance company can transmitprotected health information

Could an Insurance company transmit electronic record of protectedhealth information?

In RequestBy Rule


Yes

ProcessRequest

request

Insurance OR Plan Sponsor Related Rules In HIPAA

Rule 2 : 164.504 (f).1.i Plan document restricts disclosinginfo to plan sponsor

Is the requester is a plan sponsor?

In RequestBy Rule


yes Yes

Check Rule

Rule 2.1 : 164.504 (f).1.icould a plan sponsor get protected health information?

In RequestBy Rule


No Exception rule 12

continue check Rule

Rule 4 : 164.504 (f).1.iii Disclose information aboutenrollment of individuals for health plan

Can the Insurance company provide the status of individualenrollment in Group health plan?

In RequestBy Rule


Yes

continue check Rule

continue check Rule

Rule 5 : 164.504 (f).3.ii Health Insurance can't permit use ofinfo to sponsor

Does the request demand a protected Health Information ?

In RequestBy Rule


No Yes Exception rule 12

continue check Rule

Rule 7 : 164.508 (b).5.ii Authorization can't be revoked ifinsurance coverage used

Was the Insurance Coverage used ?

In RequestBy Rule


yes

Rule 3 : 164.504 (f).1.ii Disclose summary of protectedinformation

could a plan sponsor get the summary of protected healthinformation?

In RequestBy Rule


Yes

continue check Rule

continue check Rule

Rule 8 : 164.514 (g) can't disclose protected info toinsurance if not placed with health plan.

Is Health Insurance placed with health Plan?

In RequestBy Rule


Yes Exception Rule 12

Rule 9 : 164.520 (a).2.i.A Individual has the right to get noticefrom the group health plan if he/she doesn't receive healthbenefits.

Is the requester an Individual?

In RequestBy Rule


No yes Disclose Notice to Individual

Continue check Rule

DecisionIf No


Continue check Rule

Rule 6 :164.504 (f).3.iii Group Health Plan may not permit andnot disclose a protected health information to InsuranceIssuer or Plan Sponsor Unless required by Rule 12.

Is the requester of protected health information an insurancecompany or a plan sponsor?

In RequestBy Rule


Yes No


If N

o

Rule 12 : 164.520 (b).iii.C Insurance may disclose protectedinfo to sponsor.

Is the purpose of request for the (treatment, payment, and health careoperations)?

In RequestBy Rule


No Yes

If ye

s C

ontin

ue

Rule 1 : 164.308 (a).7.i Administrative safeguardsIs request related to the administrative safeguard policies and

procedures for responding to an emergency or other occurrence(for example, fire, vandalism, system failure, and natural disaster?

In RequestBy Rule


Yes Yes

Process

Decision


Request ForEmergency

request

Patient Related Emergency Rules In HIPAA

Rule 2 : 164.308 (a).7.ii.C Administrative safeguardsEmergency mode operation plan: business processes for protection

of the security of electronic protected health information whileoperating in emergency mode.

In RequestBy Rule


Yes

Check Rule

Rule 3 : 164.310(a).2.i Physical safeguardsProcedures that allow facility access in support of restoration of lost

data under the disaster recovery plan and emergency modeoperations plan in the event of an emergency

In RequestBy Rule


Yes

Rule 4 : 164.312(a).2.ii Technical safeguardsprocedures for obtaining necessary electronic protected health

information during an emergency.

In RequestBy Rule


Yes

If yes check other administrative Rule

If N

o C

heck

Pat

ient

Rel

ated

Rul

e

Rule 5 : 164.510 (a).3.i Release Information in EmergencyDoes the health care provider disclose some or all protected health

information to another health care provider

In RequestBy Rule


Yes Yes In Emergency Only

Rule 6 : 164.510 (b).3 Limited uses and disclosures when theindividual is not present and best interests of the Patient.

Is the patient is present?

In RequestBy Rule


Yes No

Rule 7 : 164.510 (b).4 Use and disclosures for disaster reliefpurposes

Is this for a disaster relief purposes?

In RequestBy Rule


No No

Rule 6.1 : 164.510 (b).3Is the disclose of protected health information will be in the best

interests of the individual

In RequestBy Rule


No yes

Rule 8 : 164.512 (f).3.ii Disclose protected information asrequired by law enforcement Officials

Is this request related to a law enforcement purpose?

In RequestBy Rule


No No

Rule 9 : 164.510 (f).6.i Reporting crime in emergenciesIs this Request related to crime in emergency?

In RequestBy Rule


yes yes

Rule 10 : 164.510 (f).6.ii Disclose protected information asrequired by law enforcement Officials

Is this request related to a law enforcement purpose?

In RequestBy Rule


yes yes

DecisionIf yes Law enforcement Rule

If N

o C

heck

Pat

ient

Rel

ated

Rul

e


Rule 11 : 164.520 (c).2.i.B Provide the notice: (B) In anemergency treatment situation

Is this Request also related to Provide Notice in EmergencyTreatment?

In RequestBy Rule


yes No

Rule 12 : 164.522 (a).1.iii Not restrict information inemergency.

Does individual requested to restrict protected health information?

In RequestBy Rule


yes Not In Emergency situation


Rule 13 : 164.522 (a).1.iv the covered entity must request thatsuch health care provider not further use or disclose

Will the requester health care provider use or disclose protectedhealth information for other purposes.

In RequestBy Rule


No No

AMENDMENT

ACCESS

ACCOUNTING

Requester

Items

Items

DECISION 1Purpose

DECISION 2Record Items

Items

DECISION 3Req Condition

DECISION 4Pre Condition

Req2

Req3

Req1

Pre Co

Pre Co

Pre Co

DECISION 5Time

T3

T4

AT

T7 T8

AT

T7 T8

DECISION 6Action

AT1

AT5

AT3

AT2

AT4

DECISION 3Req Condition

DECISION 4Pre Condition

Req1

PCT2

PCT1

DECISION 5Time

T3

T4

AT

T7 T8

AT

T7 T8

DECISION 6Action

AT1

AT5

AT3

AT2

AT4

T 2

T 1

T ...................

AT1

AT5

AT3

AT2

AT4

DECISION 7Document Release

RRT1

RRT3

RRT2

" FT4" ^ " RRT2 " ^" TT3 || TT3 ^ TT7 ^ TT8 "

DECISION 5Time

T3

AT

T7 T8

DECISION 6Action

AT1

AT5

AT3

AT2

AT4

DECISION 8Record Release

RRT1

RRT3

RRT2

FT1

FT4

FT2

FT3

DECISION 9Fee

OUTCOMES

'IP2ÎP3ÎP4ÎP5" ^" TT3 || TT3 ^ TT7 ^ TT8 "

DECISION 7Information Procedure

IP2

IP2

IP3 IP4 IP5

IP3 IP4'IP2ÎP3ÎP4" ^" TT3 || TT3 ^ TT7 ^ TT8 "

IP1

RRT1

RRT3

RRT2

FT1

FT4

FT2

FT3

" FT4" ^ " RRT2 " ^"IP1"TT3 || TT3 ^ TT7 ^ TT8 "

IP2

IP2

IP3 IP4 IP5

IP3 IP4

IP6

IP6

'IP2ÎP3ÎP4ÎP5ÎP6" ^" TT3 || TT3 ^ TT7 ^ TT8 "

'IP2ÎP3ÎP4ÎP6" ^" TT3 || TT3 ^ TT7 ^ TT8 "

Appendix A. Decision Tree Data, A Clinical Document and Logical Rules Samples

A.2 A Clinical Document Format

A sample of Clinical document that is generated through MDB is represented here. This Clinicaldocument is generated with followup of HL7 standard document CDA. The document representsa patient’s relevant information when he/she visits to doctor. It has the patient’s history related tohis checkups, medications and diseases. One Clinical document file is created for one patient, andcontains the patient’s medical records reflecting his/her whole life.

<ClinicalDocument xmlns:sdtc="urn:hl7-org:sdtc" xmlns:xhtml="

http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org

/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3

http://xreg2.nist.gov:8080/hitspValidation/schema/cdar2c32/

infrastructure/cda/C32_CDA.xsd">

<realmCode code="US"/>

<typeid extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/

>

<templateid root="2.16.840.1.113883.10.20.1"/>

<templateid root="1.3.6.1.4.1.19376.1.5.3.1.1.1"/>

<templateid root="2.16.840.1.113883.10.20.3"/>

<templateid root="2.16.840.1.113883.3.88.11.32.1"/>

<id root="916F4EE3-54CE-42CF-868A-2743411F9A88"/>

<code code="34133-9" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC" dispayName="Summarization of episode

note"/>

<Title>Continuity of Care Document from EHR Doctors</Title>

<effectiveTime value=""/>

<confidentialityCode code="N" codeSystem="

2.16.840.1.113883.5.25"/>

<languageCode code="en-US"/>

<recordTarget contextControlCode="OP" typeCode="RCT">

<patientRole>

<id extension="15072014abc" root="

2.16.840.1.113883.3.608.1.1"/>

<addr use="HP">

<streetAddressLine/>



<city/>

<state/>

<postalCode/>

<streetAddressLine/>

<city/>

<state/>

<postalCode/>

</addr>

<telecom use="WP" value=""/>

<patient>

<name>

<given>fname</given>

<given>lname</given>

</name>

<administrativeGenderCode code="UN" codeSystemName="HL7

AdministrativeGender" displayName="UNKNOWN" systemCode

="2.16.840.1.113883.5.1"/>

<birthDate value="15-07-2014"/>

<maritalStatusCode/>

</patient>

</patientRole>

</recordTarget>

<author>

<time vlaue=""/>

<assignedAuthor>

<id root="E81E943B-1D48-4A68-839D-D3883E06E768"/>

<addr/>

<telecom use="WP" value=""/>

<assignedPerson>

<given/>

<given/>

</assignedPerson>

</assignedAuthor>

</author>



<custodian>

<assignedCustodian/>

</custodian>

<documantationOf>

<serviceEvent classCode="PCPR">

<effectiveTime>

<low value="20110606000000"/>

<high/>

</effectiveTime>

</serviceEvent>

</documantationOf>

<component>

<structureBody>

<component>

<section>

<templateid root="2.16.840.1.113883.10.20.1.8"/>

<templateid root="2.16.840.1.113883.3.88.11.83.112"/>

<templateid root="1.3.6.1.4.1.19376.1.5.3.1.3.19"/>


codeSystemName="LOINC" displayName="History of

medication use"/>

<title>Medication</title>

<orignaltext>Single</orignaltext>

</section>

</component>

<component>

<section>

<templateid root="2.16.840.1.113883.10.20.22.2.7.1"/>


codeSystemName="LOINC" displayName="HISTORY OF

PROCEDURES"/>

<title>PROCEDURES</title>

</section>

</component>



<component>

<section>

<templateid root="2.16.840.1.113883.10.20.22.2.5.1"/>


codeSystemName="LOINC" displayName="PROBLEM LIST"/>

<title>PROBLEM LIST</title>

</section>

</component>

<component>

<section>

<templateid root="2.16.840.1.113883.10.20.22.2.3.1"/>


codeSystemName="LOINC" displayName="Allergies and

Adverse Reactions"/>

<title>Allergies and Adverse Reactions</title>

</section>

</component>

<component>

<section>

<templateid root="2.16.840.1.113883.10.20.22.2.4.1"/>


codeSystemName="LOINC" displayName="VITAL SIGNS"/>

<title>VITAL SIGN</title>

</section>

</component>

<component>

<section>

<templateid root="2.16.840.1.113883.10.20.22.2.17"/>


displayName="SOCIAL HISTORY"/>

<title>SOCIAL HISTORY</title>

</section>

</component>

<component>



<section>

<templateid root="2.16.840.1.113883.10.20.22.2.3.1"/>


codeSystemName="LOINC" displayName="RESULTS"/>

<title>RESULTS</title>

</section>

</component>

</structureBody>

</component>

</ClinicalDocument>



A.3 Snapshots of Medical Drop Box Application

(a) Statistical Data Related to Doctors and Patients

(b) MDB Application Interface for Doctor

Figure A.1: Medical Drop Box View

Samples of Clinical document in XML files are presented here. Each individual has their ownXML file containing the entire medical history of the patient. The XML file also contains theindividual’s login information for access to the MDB, including his/her personal information with



Figure A.2: Clinical Document Representation in Medical Drop Box for Patient’s Data

his/her privacy preferences settings.



A.4 Samples of Logical Rules for Medical Entities

Section A.4 shows some samples of logical rules that are generated through MLE for medicalentities. The samples of Hospital, Individual and Lab rules are shown.

In figA.3 sample of Hospital logical rules are shown.

Figure A.3: Hospital logical rules generated by MLE

In figA.4 sample of User logical rules with information and privacy setting are shown.

In figA.5 sample of Lab logical rules are shown.



Figure A.4: User logical rules Information with privacy preferences

Figure A.5: Lab logical rules generated by MLE


Bibliography

[1] D. M. Sherman, “A prolog model of the income tax act of canada,” in Proceedings of the 1st

international conference on Artificial intelligence and law. ACM, 1987, pp. 127–136.

[2] “Nationwide privacy and security framework for electronic exchange of individuallyidentifiable health information,” 2008. [Online]. Available: http://www.healthit.gov/sites/default/files/nationwide-ps-framework-5.pdf

[3] “Health laws of pakistan,” 2013. [Online]. Available: http://www.lexadin.nl/wlg/legis/nofr/oeur/lxwepak.htm\#HealthLaw

[4] “Pakistan medical and dental council code of ethics,” 2013. [Online]. Available: http://www.pmdc.org.pk/LinkClick.aspx?fileticket=v5WmQYMvhz4\%3d&tabid=292&mid=845

[5] “The medical and dental council ordinance xxxii 1962,” 2013. [Online]. Avai-lable: http://www.pmdc.org.pk/LinkClick.aspx?fileticket=7AY1\%2fco4suQ\%3d&tabid=292&mid=850

[6] “Pm&dc regulations, ordinance,” 2013. [Online]. Available: http://www.pmdc.org.pk/OtherPMDCRulesandRegulations/tabid/292/Default.aspx

[7] “Fundamental rights and principles of policy,” 2013. [Online]. Available: http://www.pakistani.org/pakistan/constitution/part2.ch1.html

[8] “Health level seven international,” 2013. [Online]. Available: http://www.hl7.org/

[9] “In 2009 the total number of 348 million passengers immigration transportation number,”2010. [Online]. Available: http://www.mps.gov.cn/n16/n1252/n1702/n2347/2287060.html

[10] Z. Ts, J. Chu, K. Araki, and H. Yoshihara, “Design and development of an international

115

Bibliography

clinical data exchange system: the international layer function of the dolphin project. pubmedcommons,” J Am Med Inform Assoc, vol. 18, no. 5, pp. 683–9, 2014.

[11] F. Mostashari, M. Tripathi, and M. Kendall, “A tale of two large community electronic healthrecord extension projects,” Health Affairs, vol. 28, no. 2, pp. 345–356, 2009.

[12] J. M. Marchibroda, “Health information exchange policy and evaluation,” Journal of biome-

dical informatics, vol. 40, no. 6, pp. S11–S16, 2007.

[13] “HIPAA administrative 45 cfr, parts 160, 162 and 164 (2009), department of health andhuman services, office for civil rights,” http://www.hhs.gov, 2009.

[14] T. D. Breaux and A. I. Anton, “Analyzing regulatory rules for privacy and security require-ments,” Software Engineering, IEEE Transactions on, vol. 34, no. 1, pp. 5–20, 2008.

[15] T. D. Breaux, Legal requirements acquisition for the specification of legally compliant infor-

mation systems. ProQuest, 2009.

[16] N. M. Brennan and M. A. Flynn, “Differentiating clinical governance, clinical managementand clinical practice,” Clinical Governance: An International Journal, vol. 18, no. 2, pp.114–131, 2013.

[17] J. C. Maxwell, A. I. Anton, P. Swire, M. Riaz, and C. M. McCraw, “A legal cross-referencestaxonomy for reasoning about compliance requirements,” Requirements Engineering, vol. 17,no. 2, pp. 99–115, 2012.

[18] P. N. Otto and A. I. Anton, “Addressing legal requirements in requirements engineering,” in15th IEEE International Conference on Requirements Engineering , 2007. RE’07. IEEE,2007, pp. 5–14.

[19] A. K. Massey, P. N. Otto, L. J. Hayward, and A. I. Anton, “Evaluating existing security andprivacy requirements for legal compliance,” Requirements engineering, vol. 15, no. 1, pp.119–137, 2010.

[20] J. C. Maxwell and A. I. Anton, “The production rule framework: developing a canonical set ofsoftware requirements for compliance with law,” in proceedings of the 1st ACM International

Health Informatics Symposium. ACM, 2010, pp. 629–636.

[21] T. Alshugran, J. Dichter, and A. Rusu, “Extending XACML to express and enforce laws andregulations privacy policies,” in Systems, Applications and Technology Conference (LISAT),

2015 IEEE Long Island. IEEE, 2015, pp. 1–5.


Bibliography

[22] J. G. Hodge, “Health information privacy and public health,” The Journal of Law, Medicine

& Ethics, vol. 31, no. 4, pp. 663–671, 2003.

[23] “Medical privacy,us department of health and human services , national stan-dards to protect the privacy of personal health information. office for civil rights,”http://www.hhs.gov/ocr/hipaa/finalreg.html, 2000.

[24] T. D. Breaux, M. W. Vail, and A. I. Anton, “Towards regulatory compliance: Extracting rightsand obligations to align requirements with regulations,” in Requirements Engineering, 14th

IEEE International Conference. IEEE, 2006, pp. 49–58.

[25] J. F. Wilson, “Health insurance portability and accountability act privacy rule causes ongoingconcerns among clinicians and researchers,” Annals of internal medicine, vol. 145, no. 4, pp.313–316, 2006.

[26] M. A. Borrelli, “Prolog and the law: Using expert systems to perform legal analysis in theuk,” Software LJ, vol. 3, p. 687, 1989.

[27] P. E. Lam, J. C. Mitchell, and S. Sundaram, “A formalization of hipaa for a medical messagingsystem,” in Trust, Privacy and Security in Digital Business. Springer, 2009, pp. 73–85.

[28] H. DeYoung, D. Garg, L. Jia, D. Kaynar, and A. Datta, “Experiences in the logical specifica-tion of the HIPAA and GLBA privacy laws,” in Proceedings of the 9th annual ACM workshop

on Privacy in the electronic society. ACM, 2010, pp. 73–82.

[29] J. C. Maxwell and A. I. Anton, “Developing production rule models to aid in acquiring requi-rements from legal texts,” in Requirements Engineering Conference, 2009. RE’09. 17th IEEE

International. IEEE, 2009, pp. 101–110.

[30] T. Takemura, K. Araki, K. Arita, T. Suzuki, K. Okamoto, N. Kume, T. Kuroda, A. Takada,and H. Yoshihara, “Development of fundamental infrastructure for nationwide EHR in japan,”Journal of medical systems, vol. 36, no. 4, pp. 2213–2218, 2012.

[31] E. Tello-Leal, O. Chiotti, and P. D. Villarreal, “Process-oriented integration and coordinationof healthcare services across organizational boundaries,” Journal of medical systems, vol. 36,no. 6, pp. 3713–3724, 2012.

[32] D. Lang, S. Huang, and T. Lv, “A method of legal text formalization,” in Internet Computing

for Science and Engineering (ICICSE), 2012 Sixth International Conference on. IEEE,2012, pp. 26–30.


Bibliography

[33] M. Hashmi, “A methodology for extracting legal norms from regulatory documents,” in En-

terprise Distributed Object Computing Workshop (EDOCW), 2015 IEEE 19th International.IEEE, 2015, pp. 41–50.

[34] A. O Neill, “An action framework for compliance and governance,” Clinical Governance: An

International Journal, vol. 19, no. 4, pp. 342–359, 2014.

[35] T. Alshugran and J. Dichter, “Toward a privacy preserving hipaa-compliant access controlmodel for web services,” in Electro/Information Technology (EIT), 2014 IEEE International

Conference on. IEEE, 2014, pp. 163–167.

[36] ——, “Extracting and modeling the privacy requirements from hipaa for healthcare applicati-ons,” in Systems, Applications and Technology Conference (LISAT), 2014 IEEE Long Island.IEEE, 2014, pp. 1–5.

[37] T. Alshugran, J. Dichter, and M. Faezipour, “Formally expressing hipaa privacy policies forweb services,” in Electro/Information Technology (EIT), 2015 IEEE International Conference

on. IEEE, 2015, pp. 295–299.

[38] P. K. Sinha, G. Sunder, P. Bendale, M. Mantri, and A. Dande, Electronic health record:

standards, coding systems, frameworks, and infrastructures. John Wiley & Sons, 2012.

[39] R. H. Dolin, L. Alschuler, S. Boyer, C. Beebe, F. M. Behlen, P. V. Biron, and A. Shabo, “HL7clinical document architecture, release 2,” Journal of the American Medical Informatics As-

sociation, vol. 13, no. 1, pp. 30–39, 2006.

[40] H. People, “Conclusion and future directions: CDC health disparities and inequalities reportunited states, 2013,” CDC Health Disparities and Inequalities Report United States, 2013,vol. 62, no. 3, p. 184, 2013.

[41] J. Guo, A. Takada, K. Tanaka, J. Sato, M. Suzuki, T. Suzuki, Y. Nakashima, K. Araki, andH. Yoshihara, “The development of mml (medical markup language) version 3.0 as a medicaldocument exchange format for hl7 messages,” Journal of Medical Systems, vol. 28, no. 6, pp.523–533, 2004.

[42] J. M. Ferranti, R. C. Musser, K. Kawamoto, and W. E. Hammond, “The clinical documentarchitecture and the continuity of care record,” Journal of the American Medical Informatics

Association, vol. 13, no. 3, pp. 245–252, 2006.

[43] E.-W. Huang, T.-L. Tseng, M.-L. Chang, M.-L. Pan, and D.-M. Liou, “Generating standardi-


Bibliography

zed clinical documents for medical information exchanges,” IT professional, vol. 12, no. 2,pp. 26–32, 2010.

[44] K. Sebelius, “US department of health and human services strategic plan; fiscal years 2010–2015. washington, dc: Department of health and human services; 2010,” 2012.

[45] J. C. Maro, R. Platt, J. H. Holmes, B. L. Strom, S. Hennessy, R. Lazarus, and J. S. Brown,“Design of a national distributed health data network,” Annals of internal medicine, vol. 151,no. 5, pp. 341–344, 2009.

[46] D. M. West and A. Friedman, “Health information exchanges and megachange,” Governance

Studies at Brookings, 2012.

[47] J. R. Vest, “Health information exchange: National and international approaches,” 2012.

[48] H.-C. Huang, W.-C. Fang, and W.-H. Lai, “Secure medical information exchange with rever-sible data hiding,” in Circuits and Systems (ISCAS), 2012 IEEE International Symposium on.IEEE, 2012, pp. 1424–1427.

[49] N. Privacy, “Security framework for electronic exchange of individually identifiable healthinformation,” Office of the National Coordinator for Health Information Technology, US De-

partment of Health and Human Services, vol. 15, 2008.

[50] “Nhs human services & netsmart technologies,” 2011. [Online]. Available: http://www.nhsonline.org/attachments/NHS Reprint P1.pdf

[51] “The number of americans who moved declined sharply last year,” 2009. [Online].Available: http://www.cleveland.com/business/index.ssf/2009/04/the number of americanswho mo.html

[52] L. Lenert, D. Sundwall, and M. E. Lenert, “Shifts in the architecture of the nationwide healthinformation network,” Journal of the American Medical Informatics Association, vol. 19,no. 4, pp. 498–502, 2012.

[53] P. Anthonysamy and A. Rashid, “Software engineering for privacy in-the-large,” 2015.

[54] J. D. Young, “Commitment analysis to operationalize software requirements from privacypolicies,” Requirements Engineering, vol. 16, no. 1, pp. 33–46, 2011.

[55] R. B. Ness, “A year is a terrible thing to waste: early experience with hipaa,” Annals of

Epidemiology, vol. 15, no. 2, pp. 85–86, 2005.


Bibliography

[56] I. Khan, M. Alwarsh, and J. I. Khan, “Tr2012-06-01 quantitative charting of HIPAA section164 legal universe,” Technical Report, Networking and Media Communications Lab, KentState University, Tech. Rep., 2012.

[57] H. A. Simplification, “Hipaa administrative 45 cfr, parts 160, 162 and 164 (2009),” 2009.

[58] “Hipaa administrative 45 cfr, parts 160, 162 and 164 (2009), department of health and humanservices, office for civil rights,” http://www.hhs.gov, 2009.

[59] D. Garg, H. DeYoung, D. Kaynar, and A. Datta, “Logical specification of the GLBA andHIPAA privacy laws,” 2010.

[60] P. Ashley, S. Hada, G. Karjoth, and M. Schunter, “E-p3p privacy policies and privacy autho-rization,” in Proceedings of the 2002 ACM workshop on Privacy in the Electronic Society.ACM, 2002, pp. 103–109.

[61] P. Ashley, C. Powers, and M. Schunter, “From privacy promises to privacy management: anew approach for enforcing privacy throughout an enterprise,” in Proceedings of the 2002

workshop on New security paradigms. ACM, 2002, pp. 43–50.

[62] J.-W. Byun, E. Bertino, and N. Li, “Purpose based access control of complex data for pri-vacy protection,” in Proceedings of the tenth ACM symposium on Access control models and

technologies. ACM, 2005, pp. 102–110.

[63] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-based access controlmodels,” Computer, vol. 29, no. 2, pp. 38–47, 1996.

[64] I. Khan, M. Alwarsh, J. Khan et al., “A comprehension approach for formalizing privacy rulesof HIPAA for decision support,” in 12th International Conference on Machine Learning and

Applications (ICMLA), 2013, vol. 2. IEEE, 2013, pp. 390–395.

[65] J. C. Maxwell and A. I. Anton, “A refined production rule model for aiding in regulatorycompliance,” IEEE Trans. on Software Engineering, 2010.

[66] N. G. Chaudhry, S. Ilyas, A. Shahzad, A. Saleem, M. Rashid, and T. A. Chaudhry, “Anopen source health care management system for pakistan,” COMSATS Institute of Information

Technology, vol. 10, pp. 1–7, 2006.

[67] P. WHOROftW, “Medical records manual: a guide for developing countries: World healthorganization,” Regional Office for the Western Pacific, 2006.


Bibliography

[68] M. S. Qazi and M. Ali, “Pakistan’s health management information system: health managers’perspectives,” JPMA. The Journal of the Pakistan Medical Association, vol. 59, no. 1, p. 10,2009.

[69] A. Hafeez-Baig, S. Grist, and R. Gururajan, “Technology management, data management,improved outcomes, efficiency and software limitation influencing the use of wireless techno-logy for healthcare in pakistan,” in Computer and Information Science, 2007. ICIS 2007. 6th

IEEE/ACIS International Conference on. IEEE, 2007, pp. 1104–1110.
