ࡱ>  @ 0bjbj00 ,RbRbm    `4L`FFF8FG`u,H:HHH,I{{ {$RiN~9{^{~~4(H^,I 2(~&T,IN,I~|z N,IH G"F΄9<u$``&&&H{| }lw}Y{{{``d/?j``?Matching Electronic Patient Records to Clinical Trials: An Ontology Reasoning Approach A. Introduction : Clinical trials are systematic studies in human patients aimed at determining the safety and effectiveness of new or unproven therapies. Significant efforts are involved in recruiting eligible patients for clinical trials. Several surveys have indicated that almost half of the time (in conducting clinical trials) is spent on recruiting patients and significant delays occur in planned schedules for patient enrollment. Low participation rate is a common problem in conducting clinical trials, for example, less than 5% of eligible patients participate in most cancer trials and less than 10% in many cardiovascular trials. With the patient data available in electronic form, screening eligible patients for on-going clinical trials at a given institution provides a promising direction to accelerate the process of translating discoveries in biomedical sciences to clinical research. However, patient data is generally distributed across clinical notes, laboratory test results, pharmacy orders and imaging data. Of these data modalities, only few of them are currently present electronically in structured form (such as lab data, pharmacy data). In this paper, we explore the possibility of using these clinical data to match patients for eligible clinical trials. A significant challenge in matching clinical patient records to clinical trials is the gulf that exists between the criteria that specified in clinical trials, and the electronic data that are available from the patient record (we refer to this gulf as . Patient data typically is coded in the form of specific drugs or diseases, where as clinical trials queries tend to occur at the level of broader descriptions. For instance, a clinical trial may be interested in including patients on drugs with a certain active ingredient (e.g., warfarin), but patient data only contains the specific drug that the patient is on (e.g..). Even worse, these specific drugs are often coded in a local or vendor-based clinical terminology (or ontology). To find patients who are on drugs that have an active ingredient of warfarin, one must understand which of the vendor-specific or local drugs do have the ingredient, and then build a custom program to find patient records that satisfy the query. Given that the queries for clinical trials change frequently, it should be apparent that building such custom programs is not practical, and is highly prone to errors. The emergence of several clinical ontologies such as the SNOMED-CT, openGalen, Foundational Model of Anatomy (FMA) and NCI Thesaurus provide a promising new alternative to the problem of matching clinical records to clinical trials queries. These ontologies specify a rich set of representation constructs in standardized terms such that it is possible for one to infer for instance, the set of drugs in SNOMED-CT that have an active ingredient of warfarin. In formal logic based terms, the clinical trial query for drugs that have an active ingredient of warfarin may be formulated as a new concept within SNOMED (e.g., (hasActiveIngredient.Warfarin). It is then possible to infer that Warfarin-substance is a subclass of this queried concept, and therefore, any local drug that is either equivalent to Warfarin-substance or is a subclass of that concept is a candidate drug for this query. In this paper, we explore the use of computational knowledge present in clinical terminologies such as SNOMED-CT to determine clinical trials eligibility. Our hypothesis is to test whether limited structured clinical data can be used to perform broad range of clinical trial queries by the use of formal ontology reasoning. We build our work on recent efforts to scale ontology reasoning to large data sets in relational databases. Translating the discoveries from basic biomedical sciences into clinical research and practice is a challenging process. Various technical, regulatory and policy issues need to be resolved to accelerate the translational process as outlined in the current NIH roadmap initiative on re-engineering the clinical research. A significant fraction of the translational research effort is directed towards identifying and recruiting eligible patients for clinical trials that deal with evaluating the efficacy and safety of new drugs or therapies in the human population at large. However, low recruitment rates account for major delays in conducting the clinical trials. In the current scenario, the clinical trials recruitment can occur through either patient-initiated search or investigator-initiated search. Several publicly accessible clinical trials registries such as clinicaltrials.gov, NCI PDQ for clinical trials and WHO international clinical trial registry provide the trial information with specific eligibility criteria. The patients can search for the trials relevant to their condition and contact the investigator for possible recruitment. On the other hand the investigator can also communicate the trial information to different health care institutions where the local physicians are responsible for contacting the patients that visit the institution to receive care and are found to be eligible for an ongoing trial. With the patient data available in electronic form, screening eligible patients for on-going clinical trials at a given institution provides a promising direction to accelerate the translational research. However, the patient data is generally distributed across clinical notes, laboratory test results, pharmacy orders and imaging data. Of these data modalities, only few of them are present in structured form (such as lab data, pharmacy data) and therefore potentially useful in performing clinical trials queries. A large chunk of unstructured data is present in form of free text notes and images; no reliable methods have been developed to extract computational knowledge from such sources (except in specific sub-specialties such as MedLee for NLP over chest x-ray reports). Often the clinical data is coded using a local or vendor-based clinical terminology (or ontology). The use of concept-oriented clinical ontologies, besides facilitating inter-operability, allows for several secondary uses of the data in a variety of health care applications such as decision support alerts, infection control, and clinical research. Furthermore, the formal clinical ontologies provide explicit representation of the domain knowledge thereby facilitating computational reasoning over the patient data. Several clinical ontologies such as the SNOMED-CT, openGalen, Foundational Model of Anatomy (FMA) and NCI Thesaurus use rich set of representation constructs that lead to subsequent scalability and tractability issues for reasoning algorithms. The methods to perform logic-based reasoning over large patient (instance) data are still in early developmental phase. We propose an approach of using the computational knowledge present in clinical terminologies to determine clinical trials eligibility. Our hypothesis is to test whether limited structured clinical data can be used to perform broad range of clinical trial queries by using formal ontology reasoning. We build our work on recent developments in ontology reasoning that can scale over millions of patient records in relational databases and we also propose novel approaches for partitioning the ontology to allow efficient and scalable inferencing. B. Related Work and Background 1. Current status of Clinical Trials Recruitment Currently, clinical trials recruitment can occur either through patient-initiated search or investigator-initiated search. Several publicly accessible clinical trials registries such as clinicaltrials.gov, NCI PDQ for clinical trials and WHO international clinical trial registry provide trial information with specific eligibility criteria. Patients can search for the trials relevant to their condition using a key-word based search and contact the investigator for possible recruitment. On the other hand the investigator can also communicate the trial information to different health care institutions where the local physicians are responsible for contacting the patients that visit the institution to receive care and are found to be eligible for an ongoing trial. Clinical trials are systematic studies in human patients aimed at determining the safety and effectiveness of new or unproven therapies. Significant efforts are involved in recruiting eligible patients for clinical trials. Several surveys have indicated that almost half of the time (in conducting clinical trials) is spent on recruiting patients and significant delays occur in planned schedules for patient enrollment. Low participation rate is a common problem in conducting clinical trials, for example, less than 5% of eligible patients participate in most cancer trials and less than 10% in many cardiovascular trials. The trial sponsors are adopting various competitive enrollment practices that offer financial incentives for accelerating the recruitment process. 2. Related Standards and Applications for clinical trials matching The National Cancer Institute has been funding the caMATCH initiative to develop clinical trial matching applications. One of their recent pilot programs includes the BreastCancerTrials.org (BCT.org) that allows patients to self-report their medical history with eligibility requirements. When a match occurs the patients initiate contact with the clinical investigators. In such a process, Tthe accuracy of self-reported clinical information remains questionable is an issue and would require additional validation step with actual clinical record. Furthermore, self-reported clinical information is still unlikely to match the query in a clinical trial query. An automated approach for recruiting patients from clinical data repositories has been considered as one the promising solution. However, the current prevalence of electronic health records in healthcare practices remains significantly low (14.1% in the US[twin cities report]). Several of the recently developed Regional Health Information Organizations (RHIOs) have concrete plans to include capabilities for clinical trials recruitment at state or regional level. Various technical and social aspects need to be resolved to realize an interoperable infrastructure for storing, sharing and reusing data for clinical research. A range of proposals have been made for ontology-based representation and management of clinical trial protocols [ravi shankar, trialdb, nadkarni etc]. The current standardizations efforts by CDISC and HL7 will allow representation and bridging of healthcare and clinical research data elements at a global scale. Nevertheless, issues pertaining to patient privacy and consents need to be handled in a principled way. Query languages such as Arden Syntax (Medical Logic Modules) and GELLO provide simple syntax to formulate queries for screening patients from clinical data repository and send alerts pertaining to decision support or adverse drug events. These languages can be also used to represent the eligibility criteria in trials for querying patients. An example of Arden Syntax is shown in Figure 1a. In next section, we discuss Description Logic as an alternative to modeling clinical trials eligibility criteria. 3. Automated Clinical Trials Eligibility Determination Existing work has shown that automated approaches provide a promising aide to clinicians and investigators for eligibility determination from electronic health records. Query languages such as Arden Syntax (Medical Logic Modules) and GELLO provide simple syntax to formulate queries for screening patients from clinical data repository and send alerts pertaining to decision support or adverse drug events. These languages can be also used to represent the eligibility criteria in trials for querying patients. However, this approach suffers from the problem that criteria for participating in a clinical trial often does directly match the data in the patient record, as we pointed out in the Introduction. Converting a clinical trial query into Arden Syntax or GELLO therefore has the problem that it must be custom coded and maintained with respect to a local/vendor-specific terminology, for each new clinical trial gets posted on a website. Existing work has shown that automated approaches provide a promising aide to clinicians and investigators for eligibility determination from electronic health records. However, theOther methods have focused on developing Bayesian networks [] or decision tree models [] to perform the matching. These that require significant knowledge acquisition effort upfront and hence do not scale beyond few sub-domains. In approach present here [] and other nave matching approaches would miss the implicit clinical knowledge leading to poor recall. In the work by Ohno-Machado et al. [], the authors use a classification hierarchy with Bayesian belief networks to perform eligibility determination, however no sufficient details were provided on the scope, size and structure of the hierarchy. The work done at Indiana University showed the feasibility of using portable decision support tools for clinical trials eligibility matching that required manual feeding of all clinical information into the system. Most of the current work in automated eligibility determination has focused narrowly on solving the matching problems for specific type of trials or 3. Formal Ontologies and Description Logic Description Logic is a subset of first-order logic that provides various expressive modeling constructs. There are various fragments of Description Logic that explore the trade-offs in the expressivity and tractability of algorithms. TBox ABox  SHAPE \* MERGEFORMAT  4. Abox Reasoning Background information. how patient data gets stored.. structured.. notes SNOMED-CT description logic OWL, DL Tbox reasoning, FMA in-memory ? InstanceStore, inmemory, indb reasoningAbox, Tbox ? Abox querying etc.. negated query and find inconsistent individuals C. Rationale and Approach With the recent need for accelerating the bi-directional flow of findings across basic and clinical research, the methods and tools in informatics [awk: are being viewed as one of the promising solution]. Automated screening of patients from clinical data repositories presents important challenges. Currently, there exists a wide gap between the specification of eligibility criteria and the actual clinical information present clinical databases, which is generally restricted to structured information such as laboratory data and pharmacy data. In this research we intend to explore methods that use biomedical ontologies and automated reasoning to bridge the gap. The challenges include representing clinical data and clinical trials into ontology-based framework and performing scalable reasoning over a large patient knowledgebase. <.> We restricted our analysis to the laboratory and pharmacy data which is generally available in structured and electronic form across a number of institutions. Secondly, most structured patient data is generally coded using some controlled terminology or dictionary provided by the vendor or maintained inhouse Why SNOMED-CT, DL <> We approach the problem by representing clinical trials criteria as ABox queries and patient data as SNOMED-CT (TBox) based knowledgebase (ABox). The eligibility criteria queries will be fed to an ontology reasoner in order to find matching patients from the knowledgebase stored in secondary storage. In order to achieve this goal, some important challenges include, Representing clinical trials eligibility criteria as ontology-based logic queries. Importing the patient data to SNOMED-CT by mapping to local terminology (MED). Scalable ontology reasoning for TBox (ontology partitioning) and ABox (over secondary storage). D. Methods We describe here the methods used for preparing, modeling and reasoning over the patient data for ontology-based querying of clinical trials. We believe that the proposed approach can be easily replicated across different institutions [say something more..]. We first describe the overall architectural workflow of the proposed approach (see Figure 1) and later discuss in detail the corresponding methods.  SHAPE \* MERGEFORMAT  1. Extracting Query Concepts from Clinical Trials In this section, we describe the methods that were used to create structured queries from free-text clinical trials. We started by scraping clinical trial documents represented in XML from clinicaltrials.gov. The criteria sections (containing free-text descriptions) were retained and corresponding NCT numbers were used as the query identifiers. Next we separated the text in the Inclusion and Exclusion sections and passed it through the Meta Map tool (MMTx). The result was a list of Unified Medical Language System (UMLS) concepts per clinical trial, several of which were filtered based on the Semantic Type of the concepts. The filter essentially removed concepts that were irrelevant from clinical data to be queried for e.g. concepts such as Before(qualifier), condition (attribute), Scientific Study etc. Further, only the concepts having source terminology as SNOMED-CT were retained. Next these concepts were populated in the Clinical Trial Workbench (CTQWorkbench) that allowed formulation of description logic queries using the parsed concepts. 2. CTQWorkbench Clinical Trial Query Formulation We developed a user tool, CTQWorkbench, to enable semi-automated approach to representing clinical trial criteria as logic queries. The tool (Figure 2) allows web-based browsing of clinical trials from the clinicaltrials.gov and also presents the corresponding concepts parsed using MMTx (section D1). In addition, users can select a piece of text and search for corresponding concepts in UMLS using the UMLS-Knowledge Server (UMLSKS). Often the UMLSKS returns several matching concepts (restricted to SNOMED-CT) that all match the given text, consider for example <.> results in We found that the multiple matching concepts infact allow creation of broader queries by using logical union of matched concepts. The advantage of such broader queries is that they eliminate the possible false negatives arising due to concept coding differences in various clinical systems and databases. The tool also provides a full-fledged description logic expression editor that can be used to formulate the ontology-based query. The editor provides the properties and corresponding inclusion\exclusion concepts required for query formulation. The output is represented as OWL based ABox queries. Consider the following example of criteria from clinical trial NCT00286182 from clinicaltrials.gov Inclusion Criteria: Heart failure and a Normal Ejection Fraction (HFNEF) Exclusion Criteria: Disorder of prosthetic heart valve As shown below these criteria get coded using existing SNOMED-CT concepts e.g. heart failure (84114007) and newly formed concepts such as HFNEF, where we add qualifier of hasInterpretation Normal to Cardiac Ejection Fraction (70822001). Also note that the exclusion criteria get modeled as negated concepts which might be complex expressions. Heart failure " (Cardiac ejection fraction " (hasInterpretation.Normal) " Disorder of prosthetic cardiac valve where Disorder of prosthetic cardiac value a" (Heart Valve Disorder " (after. ((directDevice. Prosthetic Implant " (method. Insertion) " (associatedWith. Surgical Proc) --say something about expressivity of SNOMED + queries 3. Mapping the MED and SNOMED-CT The Medical Entities Dictionary (MED) is used as the local terminology for coding the patient data at the New York Presbyterian Hospital. One of the preliminary step involved is to map the concepts in MED to SNOMED-CT to allow description logic based ontology reasoning. The MED currently uses frame-logic [] for ontology representation and maintenance. We used a lexico-semantic approach for mapping the concepts in MED to SNOMED-CT, which we now describe in detail: Terminological Connection: The MED consists of a slot that contains corresponding UMLS concept identifier. This provides a straightforward mapping approach, wherein we find the mapped UMLS concept and check whether it has SNOMED-CT as one of the source terminology. However, only a small percentage of MED concepts actually contain a mapping to UMLS. NLP Mapping: In the next step we used the Meta Map tool (MMTx) to map the MED concept strings to UMLS concepts (and transitively to SNOMED-CT). We found several putative mappings using this approach, however, we only used the mappings that gave 100% matching MMTx score. Institution Prefix Removal: MED is used to integrate information from different hospitals, hence several MED concept strings contain institution prefix such as CPMC or NYPH that lead to low matching score with MMTx. We removed such prefixes and recomputed the mappings using the Meta Map. Semantic Validation: To remove the false positive mappings, we performed a semantic validation of the mapped concepts. We traced and verified the semantic types of MED concepts and UMLS concepts in the Semantic Network. This allows removal of mappings where the concepts have same terms but different meanings altogether for example 4. MED in OWL: From Frame-based to Description Logic To exploit the local ontological knowledge present in the MED, we converted the frame-based representation of MED in to a description logic based OWL representation. We performed a straightforward transformation by modeling slots as properties and using existential restrictions to associate slots with frames/class. Next, we identified a set of slots that can serve as defining properties for given concepts, which were converted into defined classes in OWL, for example, the slots, entity-measured and assesses-sample serve as definitional properties for the laboratory concepts, for example, Pleural Fluid Triglyceride Measurement a" (assesses-sample. Clinical Chemistry Pleural Fluid Specimen " (entity-measured. Triglycerides Next, we ran a description logic classifier to re-compute the class hierarchy and compared it against the original MED taxonomy. 5. Big Fat Clinical TBoxes Ontology Partitioning and Closure Given the extensive scope and size of the MED and SNOMED-CT, we ran into scalability issues while using in-memory ontology reasoning (see Results for details). Generally TBoxes tend to be highly expressive that require in-memory reasoning; in our case, the expressivity of MED\SNOMED-CT and queries (with negations) made the reasoning complex. We observed that most of the concepts in TBox dont tend to be relevant to the actual coded patient data (ABox) under consideration. Hence, we developed methods to partition the TBox and find minimal closure based on the concepts used in the ABox and the clinical trials query. Below are the tableaux rules that were used to calculate the closure of concepts  SHAPE \* MERGEFORMAT  Figure. Computing the closure in MED/SNOMED-CT for the concepts referenced in patient data (ABox) 6. The GLUE Ontology The clinical data is coded using the MED concepts, however, to be able to query the data, we need to model utility glue concepts and properties to connect the various aspects of the data (lab results, lab specimen, drug order time, drug concentration and so on). Secondly, the implicit information present in the clinical data needs to be made explicit for the purposes of querying clinical trials, for example, probable disorders given the lab test. One of the goal in modeling the new GLUE ontology was to re-use the concepts already available in MED or SNOMED-CT. We now provide some details on modeling aspects of the GLUE ontology. Utility Concepts and Properties: We modeled few concepts to provide a coherent view of the raw clinical data coming from different sources, for example, hasFinding is a generic role/property that subsumes from specific roles hasProcedureFindings (that can be hasXRayFindings), labFindings (that subsumes causative-agent, SNOMED-CT:xxx) and so on. The advantage of modeling such role hierarchy is to allow generic clinical trials queries such as give me patients that hasFinding.X there by decoupling the actual underlying data stores and the query language. We also imported and re-used the concepts in TIME-ML OWL ontology[] to represent the temporal aspects in the dataset such as drug-order time, and the drug administration frequencies. The temporal axioms in TIME-ML ontology such as before and after allowed inferences for ordering the clinical events. Explicit Inference Rules: We also modeled various inference rules (in Description Logic) to increase the recall and perform interesting queries by making the knowledge in clinical data explicit. Consider for example, the lab results coded using a concepts such as Positive for Staphylococcus aureus and the clinical trial is looking for patients with MRSA (Methicillin Resistant Staph. Aureus) or VRSA (Vancomycin Resistant Staph. Aureus), the query would not be able to find such patients although they are likely candidates. To allow such inferences we encode explicit rules of the form (hasDisorder.(causative-agent.Staphylococcus_Aureus " (hasProbableDisorder. MRSA_Infection " (hasProbableDisorder. VRSA_Infection (hasFindingLocation. Thoracic_Cavity_Structure " (hasProbableFindingLocation. Mediastinal_structure " (hasProbableFindingLocation. Entire_Pleura One of the trade-off in encoding such explicit inferences is that such rules generate complex GCI (General Class Inclusion) axioms that are known to increase the complexity of reasoning. 7. Scalability in ABox Summarization and Refinement [ too technical ?] The ABox or clinical data in our case can easily range into millions of records. Existing description logic reasoners fail to scale given the constraints on in-memory reasoning with large datasets. We have developed an approach[] to provide scalable reasoning over relational databases. The core idea is to summarize the knowledgebase into a smaller size and then perform reasoning such as consistency checking over the summary in memory. To perform ABox query processing, we first find the inconsistent partitions of the summary and iteratively prune and refine the summary to find the actual individuals matching the query. We now describe these steps in detail: Step 1: Summarization - In this step, we summarize the knowledgebase to conservatively identify the partitions that can be potentially responsible for causing an inconsistency. Step 2: Refinement - E. Evaluation To evaluate the correctness of the proposed ontology-based reasoning approach, we performed following expert-system limited experimental analysis. We manually selected 20 criteria\queries from clinicaltrials.gov that were closely related to the clinical data encoded in the knowledge base (refer to figure to for sample queries). Then we performed a random sampling of the patient database to encode the F. Results NLP over Clinical trials. Mapping results, semantic validation. MED, SNOMED-CT- memory footprints for classification MED discovery of new subsumption relationships Ontology Partitioning evaluation Experimental Results G. Discussion Limited electronic data Terminology coded data is necessary Snomed-Ct Description logic (adding expressivity) Clinical trial queries representable in dL Ranking the matching patients (future work e.g. based on number of satisfied criterias) http://caonline.amcancersoc.org/cgi/content/abstract/48/1/6 H. References  Note that the role hasActiveIngredient is a SNOMED-CT role and the concept Warfarin is a SNOMED-CT concept. The query is a new SNOMED concept that builds on the roles and concepts in the SNOMED-CT ontology.     Dont we have the same issue (i.e. the patient may state that they are on some drug, but it still might not match if the drug has warfarin). Chintan, this is very confusing as it stands right now if we did have the entire clinical record, would that somehow do away with the need for fomal ontology reasoning? I suspect not because there is a fundamental gulf between the clinical trials queries, and the actual data for the patient record. So in my opinion, all these standards are not really alternative approaches to the problem Can we have a specific example here??? This section needs to be fleshed out further precisely how are these approaches problematic?? . NIH Roadmap,  HYPERLINK "http://nihroadmap.nih.gov/" http://nihroadmap.nih.gov/ . Landis SH, Murray T, Bolden S, Wingo PA. Cancer statistics, 1998. CA Cancer J Clin. 1998 Jan-Feb;48(1):6-29. . National Library of Medicine, Clinical Trials,  HYPERLINK "http://clinicaltrials.gov/" http://clinicaltrials.gov/ . National Cancer Institute, Physician Data Query (PDQ) Clinical Trials search  HYPERLINK "http://www.cancer.gov/search/clinicaltrials/" http://www.cancer.gov/search/clinicaltrials/ . World Health Organization (WHO), International Clinical Trials Registry Platform, http://www.who.int/ictrp/en/ . National Library of Medicine, Clinical Trials,  HYPERLINK "http://clinicaltrials.gov/" http://clinicaltrials.gov/ . National Cancer Institute, Physician Data Query (PDQ) Clinical Trials search  HYPERLINK "http://www.cancer.gov/search/clinicaltrials/" http://www.cancer.gov/search/clinicaltrials/ . World Health Organization (WHO), International Clinical Trials Registry Platform, http://www.who.int/ictrp/en/ knowledge: type: data-driven;; data: K := read last {serum potassium} where it occurred before now;; priority: 50;; evoke: potassium_storage;; logic: if K >= 3.3 then conclude false; endif;; action: write "This patient has hypokalemia in the setting of digoxin therapy...." ;; urgency: 50;; end: storage_of_potassium := EVENT { '32506', '1709';'32506', '1721';'32506', '1723'; '32506', '1724';'32506', '1805';'32506', '1887'; '32506', 888';'32506','28186'; '32506','32693} Medical Entities Dictionary (MED) codes for whole blood Na-K stat lab panels chem 20 chem 7 Pau chem panel chem 8 VBG . Definition of potassium storage event in the MLM Description Logic formulation of the query using SNOMED-CT Lab Test ( (component. Potassium Figure 1: Comparing query representation using Arden Syntax and Description Logic a). A Medical Logic Module for warning the health care provider of hypokalemia in the setting of digoxin therapy. b). The module for potassium_storage in the MLM that exhaustively checks the events (coded using the Medical Entities Dictionary, MED) that report potassium measurements the patient. c). The corresponding text for the MED codes d). SNOMED-CT based Description Logic representation for the Lab tests that measure potassium b d c a Clinical Trials (free text) clinicaltrials.gov ifpma.org Scraper MMTx (NLP) CTQWorkbench MED (frame-logic) SNOMED-CT (description-logic) Patient Glue Ontology ABox Generator DL-Reasoner (SHER) matching patients Clinical Data Repository Filters Figure. Overall schematic of the components involved in the preparing, modeling and reasoning over the patient data for matching to clinical trials. The detailed description of each component is presented in the corresponding sections numbers shown in the schematic. Closure Computation (On-Demand) ABox Query TBox+ABox D1 D3 D5 D7 D4 D2 D6 ABox MED SNOMED-CT WX[hituw e f g h  l m n QlƼƼƥƑƑƑƑ}si_iHh˓&hUyHhy&hWHhx&hWHhw&h6cHhw&hWHhv&hWHht&hWHhu&hWHhk&h/Vh6cHhk&h6cHht&h6chh5OJQJ^Jh5OJQJ^JhOv#hhOv5CJOJQJ^JaJ%WXhm n PJ$C$Eƀw&a$gdOvJ$C$Eƀk&a$gdW $<<a$gdgdOv$a$gdyB$uջo\IIIIII%h{h3gScHdhdhdh&%hOvh6ccHdhdhdht&%h vh3gScHdhdhdh&%hNPh3gScHdhdhdh&%hh3gScHdhdhdh&%hOvh3gScHdhdhdh&2jhh3gS0JUcHdhdhdh&+hhh3gScHdhdhdh&(hh3gS6cHdhdhdh& : E j t 4!!!"Q""""I########t$m%ٳ٠ٍٳٍٍٳzٍٍٍb.hw^hOvhW6cHdhdhdh&%h.hWcHdhdhdh&%hyThWcHdhdhdh&%hhWcHdhdhdh&%h{hWcHdhdhdh&%hhWcHdhdhdh&%hOvhWcHdhdhdh&%hvNh3gScHdhdhdh&m%n%o%r%~%%%%%%%%%%%%&|&&&&&&&&&&ϽucuWJJHh&hhfwHh&hfw6#jHh&hfw0J6UHh&hy%hfw6Hh&hfwHh&hfwHh&hOv5h2HhOv5Hh&hfw5 h72w5hOvhh5OJQJ^JhhOv5OJQJ^Jh5OJQJ^Jh%hOvh3gScHdhdhdh&o%%%%%((++UJ$C$Eƀ&a$gdfwJ$C$Eƀ&a$gdfw$a$gdOv $<<a$gd&&&&&&''['y'(((S)q*****>+++++,,帘ooooc^YMEh2HhOv5Hh&hi75 hOv5 h72w5Hh&hfw5%hOvhfwcHdhdhdh&+h/VhOvhfwcHdhdhdh&>hfwhfwhfw5cHdhdhdh&&*5Hh&hfwHh&hfwHh&hhfwHh&hfw6Hh&hfw jHh&hfw0JU++,..024YG$a$gdi7o&d&`J$C$Eƀ&a$gdOv$a$gdi7$a$gdOvJ$C$Eƀ&a$gdOv,--------;.<.>....//0/1///N111122򢏢taNNN%hOvhi7cHdhdhdh&%hOvhi7cHdhdhdh&5jhi7h{0J<UcHdhdhdh&%hOvhi7cHdhdhdh&%hOvh{cHdhdhdh&Hhɓ&hIjhI0J<UHhȓ&h{Hh&h{%hOvhi7cHdhdhdh&Hh&hi7hOv2244446@777^8n8z88888^9j9o9999O:vcPcFBFcBh72wHhƓ&h{%h72wh{cHdhdhdh&%h72wh{cHdhdhdhƓ&.h72wh{h{5cHdhdhdh&Hhē&h{Hhœ&h{HhÓ&h{Hh“&h{Hh&h{Hh&h72w5h72wh72w5 h72w5%hOvh{cHdhdhdh&%hOvhi7cHdhdhdh&44488_GC$Eƀ&gd{J$C$Eƀ&a$gd{$a$gd72wgdOv88<9=:=f=Q>R>X>Y>^>_>|>~>>>>  gdOv$a$gdZgdOv$a$gd72w$a$gd{J$C$Eƀ&a$gd72wO:P:w<{<<<<<<9=:=S=f=r=s===P>Q>]>^>_>`>w>x>y>{>~>>>>>M?Y?ü졝얥|nia]V hHhhhF`hOv5 h72w5hOvCJOJQJ^JaJjhOvUmHnHuhOvjhOvU hh;hh hhh;hOv5h;h72w5 h;h72w%h;h{cHdhdhdhȓ&+h;h;h{cHdhdhdhȓ&h;h72wjh{0J<U!>>>>?%?Z????CC6hh6 h uhhUh6 h72whCJOJQJ^JaJjhUjhUmHnHujhUh72wh6CJaJhh6CJaJ hm8h72w hm8hh+FfFFFmHnHHSNFAAgd$a$gdgdU$ & F 8Eƀj&)^a$gdU$ & F 8Eƀj&)^a$gdHHLMRR2RhRjR~RRRSSTTTTDUV VWVxVLXgd$a$gdgdXTTTTTTTTTFUHUtUvUxUzUUUUUUUUUUUUVVVVWVxVV0]e]H_X_]_l__```z`|`~````a$bee*e+e,e-e.e/e谺캰訚j hUjhUmHnHujhU j$hh hhh#h6h; h72whCJOJQJ^JaJ j$h uhhh uhOJQJ^J h uh9LXYZeL$ & FEƀj&)a$gdL$ & FEƀj&)a$gdZ[0]e]__``a$be`XXSXX`gd$a$gdgdL$ & FEƀj&)a$gdL$ & FEƀj&)a$gd $b~cddeee/eeee,hkU$ & F Eƀj&)^a$gd72wgdgd$a$gd$a$gd /e}eeeeeee,hKhhh i!i"i#iAiLi\ikii jAkGkLkQkkklllllmmAmmmmmnn n"n(n8njnü鴭韔wh ;h5CJaJ h ;hCJOJQJ^JaJh ;hCJaJ j$h ;hCJaJ hDhh}h6 hJ'h h6h,h6hJ'h5 h72whCJOJQJ^JaJhhCJaJh~/hCJaJ.kmmnnoopppssDtEt[t\t]tgdgd $^a$gd$a$gdU$ & F Eƀj&)^a$gd72wjnlnnnpnvnnnnooo o&o6oooooooooooppppppsssCtDtEtWtZt[t_t`t0uBu v v¾xq h72wh72whh6h72w h. h h5h;Oh5hZCJOJQJ^JaJ h72whCJOJQJ^JaJ h ;hhhCJaJh ;h5CJaJ j$h ;hCJaJh ;hCJaJ h ;hCJOJQJ^JaJ,]t^t_tmtttvvvvv v vv0vI & FEƀj&-gdgd72w$a$gdgdgd vvvvvw.x1x;x?ABDEGHJKOPQSTVW[\]hitu$a$gdgdhituhlh@| h&h@|CJOJQJ^JaJhCJOJQJ^JaJh@|CJOJQJ^JaJhOhCJOJQJaJh ugdgdOvgd*1h:pOvBP/ =!"#$%Dd$D  3 @@"?Ddt"D  3 @@"?Dd x5D  3 @@"?DyK http://nihroadmap.nih.gov/yK Nhttp://nihroadmap.nih.gov/yX;H,]ą'c%DyK http://clinicaltrials.gov/yK Nhttp://clinicaltrials.gov/yX;H,]ą'c%ADyK -http://www.cancer.gov/search/clinicaltrials/yK rhttp://www.cancer.gov/search/clinicaltrials/yX;H,]ą'c%DyK http://clinicaltrials.gov/yK Nhttp://clinicaltrials.gov/yX;H,]ą'c%ADyK -http://www.cancer.gov/search/clinicaltrials/yK rhttp://www.cancer.gov/search/clinicaltrials/yX;H,]ą'c%@@@ OvNormalCJ_HaJmH sH tH \@\  Heading 2$<@& 56CJOJQJ\]^JaJV@V  Heading 3$<@&5CJOJQJ\^JaJDA@D Default Paragraph FontRi@R  Table Normal4 l4a (k(No Liste@ OvHTML Preformatted7 2( Px 4 #\'*.25@9CJOJQJ^JaJ<+@<  Endnote TextCJaJ>*@> Endnote ReferenceH*6U@!6  Hyperlink >*B*phH@2H 6c Balloon TextCJOJQJ^JaJ>@B> R Footnote TextCJaJ@&@Q@ RFootnote ReferenceH*B'@aB i7Comment ReferenceCJaJ<@r< i7 Comment TextCJaJ@j@qr@ i7Comment Subject5\ ~g~WBp1m7P`t  #8g    C E \ b e h k n t w z ~    JMNOPQRSY[_bcdfgijkmnopqr"#$&'()+,-/01568:<=?ABDEFGs1m7P`t  #8g    C E \ b e h k n t w z      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFIBM_User;&0'O24~IIIIɓ&ȓ&ȓ&ȓ&E~ WXhmn x y )Jmno ###$&&(*,,,000495:5f5Q6R6X6Y6^6_6|6~66666667%7Z7777;;<<O<S<=>f>>>m@n@@@DEJJ2JhJjJ~JJJKKGLpLqLwLLM MWMxMLOPQR0TeTVVBWCWWX^YZZZZZ[q[r[[ ^hacci?iMiiijjjjjjjjk6kkkkkkkklLlwlllmmmmmmmmmnppAppppiqqrssIttttttuFu[u|uuuuuuv6v^vwvvvvvv9w;w0<>0<>(0<>0?(0<>0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD0ZD(0<>0L 0L 0L 0L 0L(0<>0S0S0S0S0S(0<>09W09W09W09W09W09W09W09W09W(0<>0Z 0Z 0Z0000000(0000000000(0000000000(0 0 0 0 0 0 0(0 0 0 0 0 000(0@0 0@0@0@0@0 0ܑ @0@0@0@0@0 05@0@0@0@0@0@0@0@0 0l 00x0x0x0x0x0x0x0x0x0x0x0x0x0x0x0x0x0x0p00x0x0x000 0 0x 0x 0x 0x 0x 0x00000x000x0000000000000x0000000000000x000x00000x000x00000x0000000x0x000x000000000000000000000000000x0x000x0x000x0x0x000x0000000x000000000000000000000x00000000000x0000000x000000000000WXhmn x y )Jmno ###$&&(*,,,000495mmmmmmmmnppAppp~0000000000000000000@00@00@00@00@00@00@00@00@00@00@00@00@00@00@00@00@00@00@00@00@00 @00 04@00@00@00@00@00P;@00@00@00@00@000 @0 .im%&,2O:Y?XT/ejn va{|l<χhDGIKLMNOQSTWY\`bdjklruvz|n xo%+48>FHLXZ$bk]t0vvvlwy:т|;Շ!uEHJPRUVXZ[]^_acefghimnopqstwy{}F_6w6z6n@@@Z [ [~___:U$?;wXXXXX8st@1ssZ0(    |)! 3  s"*?`  c $X99? |)!zB  c $&"`  &T  # '4  'T  # (X & (4R   <X B   ln  C )"`dP )n  C *"` < *n  C +"` ! |); +n  C ,"` !  ,ZB  S DX$ YZB  S D$ ZB   S D$ ZB ! S D$ 2 " 0-""`$   - # 0.#"`<, .`B $ C /$\ X,t /ZB %B S D< hn & C 0&"`  0n ' C 1'"` < 1n ( C 2("`(#  2` ) C 3)h 3H2 * # 4h`B + C 4+Ph 4` , C 5,P" 5n - C 6-"`(#0 6H2 . # >n / C 7/"`0`' 7`B 0 C 80P 8n 1 C 91"`# 9V 2 # f"`d (B 3  $ \ fB 4  $ 2 5 0:5"`$  D :z 6 c $;6"`( ;B 7  $ z 8 c $<8"`D <B 9   z : c $=:"` ` =B ;  $   < 0><"`$ @ | >z2 = c $?="` ,| ?B >  @  TB ? # @?`d| @B @  ,n A 0AA"`$ L  Az2 B c $BB"` Lx BB C    n D C CD"`X  Cn E C DE"`  Dn F C EF"` 0 En G C FG"` h F" |)/ H3  s"*?n I c $X99?"`|)/T J # J  ZB K S D  ZB L S Dn M C M"`3 n N C N"`3O T O # O  T P # Ps " T Q # Q/(N* Z R 3 R T S # S !( TB T C DlmTB UB C D  !!ZB V S D  ZB W S D  s ZB X S D " #Z Y 3 Y<!%$ ZB Z S D45!Z [ 3 [!l$ ZB \ S DZB ]B S DlC#<D#ZB ^ S D)d)T _ # _d{'* ZB ` S D4$5{'ZB a S D)X )n b C b"`X /((* TB c # c3t" T d # d#& ZB e S D & /(h f 3 "`g,(/ T g # gt" `B h c $D!h i 3 "`{'dK* h j 3 "`_% /( 2 k 0"`H;dW b l C H|"`H&2 m 0 "` !  2 n 0!"`D%`'! !2 o 0""` &</( "2 p 0#"` '! #2 q 0$"`x&( $2 r 0%"`#& % x+0 3  s"*?n  c $X99?"`x+0N     N   |* ZB  S D|ZB  S D#4#f  S #+ f   S !@*$ n   C "`0 ZB  B S D`%f   S < "|N% h   3 "`<%' b  # "`)*0 t2  S  "`0H  t2  S  "`$E&  t2  S  "`h !  t2  S  "`H  f s S Gd% GB S  ?"$3"#45675895:;<=>=?@Cx6@ [~$tHt"lt`'t! ConceptNameKL~oL~ Q٨IR٨LwS٨|FT٨U٨4V٨\W٨ X٨=Y٨LpZ٨w[٨[s\٨, ]٨twFJaKaKMMMMqqwwl~l~~    LJgKgKMMNN q qwwq~q~~ =*urn:schemas-microsoft-com:office:smarttags PlaceType= *urn:schemas-microsoft-com:office:smarttags PlaceName9 *urn:schemas-microsoft-com:office:smarttagsplace8 *urn:schemas-microsoft-com:office:smarttagsCity    # ; D % - g  ' J$Q$22R6V6Y6]6667 7%72747<7>7B7M7Q7S7W7Z7^7N8Q84<;<<<<<<<!=)=>>>>BBDDDD3E?E5F9FGGIIOK`K,LDLLLMMNNPPQQRRWWXXYYYYZZPZTZk[o[^^^___!_,_T_Z___bbbbbbbbbcccc ccccccdddd+d-d;d>dPdSdldpddddddddeeeeDfMfggkkl lclpltlvlllm1mDmimqmmmmmmmmmmmmmmnnnno"ooopq qJqNqthuyuuuv#vFvMvvvwwwwwwwwwwxxxy#y4yzzzz {{{'{||||||<~F~H~R~T~^~`~j~~im./;/666666667$7S7Y7k7m7n7u7??CCqLvLLLLLLLLMkQtQVVW!WZZ[[s`|`ccccd,d>dPdSddddeeffiimmmmmmmmmmmmmmp%q=q>qOq\q_qttttttttt'u,uLuTuaufuuuuuuuuuuuuuv#vFvMvivpv}vvvvw x)x?xyyyyVzWzYzZz\z]z_z`zszwzzzzz0{8{g{n{}}}}<~F~H~R~T~^~`~j~~333333333333333333333333333333333333333333333333333333333333333333333333,,R6_677M M3WCWr[[-d=dddJhrh?iMirkk[llmmmmmmmmmmmmmmmmoppsstivv9w;wjww)xJxVzWzYzZz\z]z_z`zbz}zzzzzzzzzzzzzzzz { {{{.{0{A{C{\{^{e{t|||||||||||||||||||||||||||||!}#}R}T}n}p}t}v}w}y}z}|}}}}}}}}}}~~~~~~!~"~$~%~'~(~*~.~0~1~3~4~6~:~<~F~H~R~T~^~`~j~l~~~~~mmmmmmmmmmmmmmpt~Up1m=I dm#MbY !p_ jLe&zS{96h88^8`)h ^`hH.h  L ^ `LhH.h   ^ `hH.h xx^x`hH.h HLH^H`LhH.h ^`hH.h ^`hH.h L^`LhH.^`o() ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.^`OJPJQJ^Jo(-^`OJQJ^Jo(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoPP^P`OJQJo(hHh ^`5OJPJQJ^Jo(hH.h^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH^`OJPJQJ^Jo(-^`OJQJ^Jo(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoPP^P`OJQJo(hH^`o() ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.!p_m#MUp1zS{jLeI                  K                K                 AtE+l,+W*@.?thyR`*G1]<4i7NPS3gSyT6c72wUy{RvNJ~@|qy;{Z3`.e vOvIl2~,fw@ll]V lldLMVWcd|~@T@`@n@@UnknownIBM_User Gz Times New Roman5Symbol3& z Arial?5 z Courier NewO& k9?Lucida Sans Unicode;" Helvetica7&  Verdana5& z!Tahoma;Wingdings"1h{ғ&+H\7H\74dll2qHP ?hOvVMatching Electronic Patient Records to Clinical Trials: An Ontology Reasoning ApproachBiomedical InformaticsIBM_User$      Oh+'0$0<P dp   XMatching Electronic Patient Records to Clinical Trials: An Ontology Reasoning ApproachBiomedical Informatics Normal.dot IBM_User15Microsoft Word 10.0@)@ @"H\՜.+,D՜.+,P hp  /Columbia University7l WMatching Electronic Patient Records to Clinical Trials: An Ontology Reasoning Approach Title 8@ _PID_HLINKSAh -http://www.cancer.gov/search/clinicaltrials/u6 http://clinicaltrials.gov/-http://www.cancer.gov/search/clinicaltrials/u6http://clinicaltrials.gov/ynhttp://nihroadmap.nih.gov/  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry Fg"Data 1Table)WordDocument,SummaryInformation(DocumentSummaryInformation8CompObjj  FMicrosoft Word Document MSWordDocWord.Document.89q