# Overview ## Background CEDARS (Clinical Event Detection and Recording System) is a computational paradigm for collection and aggregation of time-to-event data in retrospective clinical studies. Developed out of a practical need for a more efficient way to conduct medical research, it aims to systematize and accelerate the review of electronic health record (EHR) corpora. It accomplishes those goals by deploying natural language processing (NLP) as a tool to assist detection and characterization of clinical events by human abstractors. In its current iteration, CEDARS is available as an open-source R package under [GPL-3 license](https://www.gnu.org/licenses/gpl-3.0.en.html). The latest stable package can be downloaded from [CRAN](https://cran.r-project.org/web/packages/CEDARS/index.html) and the most recent development version can be cloned from [GitHub](https://github.com/simon-hans/CEDARS). Full documentation is available [here](https://docs.cedars.io). ## Requirements R 4.2.3 and package dependencies\ RStudio\ MongoDB\ Unified Medical Language System (UMLS) MRCONSO.RRF file (desirable but not required) CEDARS can be installed locally or on a server. In the latter case, Shiny Server (open source or commercial version) will be required. A business-grade server installation of MongoDB is vastly preferred, even if CEDARS is run locally. Because by definition CEDARS handles protected health information (PHI), special consideration should be given to ensure HIPAA (Health Insurance Portability and Accountability Act) compliance, including but not limited to using HTTPS, encryption at rest, minimum password requirements and limiting operation to within institutional firewalls where indicated. **CEDARS is provided as-is with no guarantee whatsoever and users agree to be held responsible for compliance with their local government/institutional regulations.** All CEDARS installations should be reviewed with institutional information security authorities. The [UMLS](https://www.nlm.nih.gov/research/umls/index.html) is a rich compendium of biomedical lexicons. It is maintained by the National Institutes of Health (NIH) and requires establishing an account in order to access the associated files. Those files are not included with the CEDARS R package, but CEDARS is designed to use them natively so individual users can easily include them in their annotation pipeline. NegEx ([Chapman *et al*, Stud Health Technol Inform. 2013; 192: 677–681.](https://pubmed.ncbi.nlm.nih.gov/23920642/)) is included with CEDARS. ## Basic Concepts ![CEDARS Workflow](https://2797339908-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-ML9SpEg76Jeuy-dRmhY%2Fuploads%2Fgit-blob-f438d90702a449b0f1a4ae720f2cf252207bb20d%2FGitHub%20Schema%202%20C.png?alt=media) Sentences with keywords or concepts of interest are presented to the end user one at a time and in chronological order. The user assesses each sentence, determining whether or not a clinical event is being reported. The whole note or report drawn from the EHR is available for review in the GUI. If no event is declared in the sentence, CEDARS presents the next sentence for the same patient (#1). If an event date is entered, CEDARS moves to the next unreviewed sentence before the event date. If there are no sentences left to review before the event, the GUI moves to the next patient (#2) and the process is repeated with the following record (#3 and #4), until all selected sentences have been reviewed. In order for CEDARS to be sufficiently sensitive and not miss and unacceptable number of clinical events, the keyword/concept search query must be well thought and exhaustive. The performance of CEDARS will vary by medical area, since the extent of medical lexicon will vary substantially between event types. ## Operational Schema ![CEDARS Operational Schema](https://2797339908-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-ML9SpEg76Jeuy-dRmhY%2Fuploads%2Fgit-blob-da1501a34c21ae97d9d6b1ffc506d588bea9a6e1%2FGitHub%20Schema%201%20C%20blue.png?alt=media) CEDARS is modular and all information for any given annotation project is stored in one MongoDB database. User credentials, original clinical notes, NLP annotations and patient-specific information are stored in dedicated collections. Once clinical notes have been uploaded, they are passed through the NLP pipeline. Currently only UDPipe is supported and integrated with CEDARS. If desired, the annotation pipeline can include negation and medical concept tagging by NegEx and UMLS respectively. Multiple users can load the web GUI and annotate records at the same time. Once accessed, a given patient record is locked for the user. ## Sample Code The R CEDARS package includes a small simulated clinical notes corpus. This corpus is fictitious and does not contain information from real patients. Once access to MongoDB has been achieved, you can install and test drive CEDARS with the following code: ```r devtools::install_github("simon-hans/CEDARS", upgrade="never") library(CEDARS) # The code below creates an instance of CEDARS project on a public test MongoDB cluster, populated # with fictitious EHR corpora. # MongoDB credentials db_user_name <- "testUser" db_user_pw <- "testPW" db_host <- "cedars.yvjp6.mongodb.net" db_replica_set <- NA db_port <- NA # Using standard MongoDB URL format uri_fun <- mongo_uri_standard # Name for MongoDB database which will contain the CEDARS project # In this case we generate a random name mongo_database <- find_project_name() # We create the database and all required collections on a test cluster create_project(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database, "CEDARS Example Project", "Dr Smith") # Adding one CEDARS end user add_end_user(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database, "John", "strongpassword") # Negex is included with CEDARS and required for assessment of negation negex_upload(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database) # Uploading the small simulated collection of EHR corpora batch_upload_notes(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database, simulated_patients) # This is a simple query which will report all sentences with a word starting in # "bleed" or "hem", or an exact match for "bled" search_query <- "bleed* OR hem* OR bled" use_negation <- TRUE hide_duplicates <- TRUE skip_after_event <- TRUE save_query(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database, search_query, use_negation, hide_duplicates, skip_after_event) # Running the NLP annotations on EHR corpora # We are only using one core, for large datasets parallel processing is faster automatic_NLP_processor(NA, "latin1", "udpipe", uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database, max_n_grams_length = 0, negex_depth = 6, select_cores = 1) # Pre-searching based on query # This is optional but will speed-up the interface pre_search(patient_vect = NA, uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database) # Start the CEDARS GUI locally # Your user name is "John", password is "strongpassword" # Once you have entered those credentials, click on button "ENTER NEW DATE" and CEDARS will seek the first record to annotate # Try out the interface, adjudicating sentences, entering event dates, comments, moving between sentences and searching for records # Once you have entered some data, close the GUI start_local(db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database) # Obtaining events and info associated with data entry # The annotations entered in the GUI are now available in this dataframe event_output <- download_events(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database) # Remove project from MongoDB terminate_project(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, mongo_database, fast=TRUE) ``` If your systems use a different MongoDB URI string standard, you will have to substitute your string-generating function. ## Future Development We are currently documenting the performance of CEDARS with a focus on oncology clinical research. At the present time, we wish to solidify the CEDARS user interface and ensure a smooth experience in multi-user settings. In the longer term, plug-in modules featuring enhanced query generation and adaptive learning will be integrated into the R workflow. Support for other NLP engines and extensive parallel processing are also desirable. Please communicate with package author Simon Mantha, MD, MPH () if you want to discuss new features or using this software for your clinical research application. # Administrator Manual ## Getting Started ### Requirements **CEDARS is provided as-is with no guarantee whatsoever and users agree to be held responsible for compliance with their local government/institutional regulations.** All CEDARS installations should be reviewed with institutional information security authorities. CEDARS was tested on a desktop PC. R 3.5.0 or above and all dependency packages need to be installed: fastmatch\ jsonlite\ mongolite\ parallel\ readr\ shiny\ udpipe\ utils RStudio is required to use the app locally and to publish it to RStudio Connect. A MongoDB installation is required to hold all the project data, preferably on a dedicated server. Lastly, the Unified Medical Language System (UMLS) MRCONSO.RRF file is required for searches using Concept Unique Identifiers (CUI's). The [UMLS](https://www.nlm.nih.gov/research/umls/index.html) is a rich compendium of biomedical lexicons. It is maintained by the National Institutes of Health (NIH) and requires establishing an account in order to access the associated files. Those files are not included with the CEDARS R package, but CEDARS is designed to use them natively so individual users can easily include them in their annotation pipeline. NegEx ([Chapman *et al*, Stud Health Technol Inform. 2013; 192: 677–681.](https://pubmed.ncbi.nlm.nih.gov/23920642/)) is included with CEDARS. ### System Architecture ![CEDARS Operational Schema](https://2797339908-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-ML9SpEg76Jeuy-dRmhY%2Fuploads%2Fgit-blob-da1501a34c21ae97d9d6b1ffc506d588bea9a6e1%2FGitHub%20Schema%201%20C%20blue.png?alt=media) The CEDARS app runs from within a Shiny instance. It is possible to use either RStudio Connect or alternatively a dedicated server running Shiny Server. The former is easy to use from RStudio desktop but requires an existing RStudio Connect installation within your organization, while the latter is typically more costly and labor intensive. Users connect to the Shiny app by accessing a web URL provided by RStudio Connect or a web server on a dedicated Shiny Server installation. CEDARS performs the operations to pull data from the database, process it and present it to the end users. Data entered by users is processed by CEDARS and saved to the database. RStudio Connect and Shiny Server Pro allow for the automatic generation of multiple processes ("workers") when multiple end users access the app simultaneously, however this is rarely needed with CEDARS since in most implementations only a few abstractors (i.e. <5) will have access to the interface. In most cases, if pre-search is used (see below), CEDARS will run fairly quickly with 2 simultaneous users in a single-threaded setup. CEDARS can handle authentication, but ideally this will be done by Active Directory through RStudio Connect. This approach ensures optimal integration with an organization's IT architecture. ### Installing CEDARS #### CEDARS R Package Installation From RStudio, and with the devtools package installed: ```r devtools::install_github("simon-hans/CEDARS", upgrade="never") ``` This will install CEDARS on a desktop or server. In the case of RStudio Connect implementations, CEDARS will be automatically installed when uploading the app through RStudio. ## Project Execution ### Overview Extracting clinical event dates with CEDARS is a simple, sequential process: ![Project Execution Overview](https://2797339908-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-ML9SpEg76Jeuy-dRmhY%2Fuploads%2Fgit-blob-26341c43c96ff469c10e49269fe80e097f6cc80b%2FGitHub%20Schema%204%20B.png?alt=media) ### App Installation The CEDARS package includes its data entry interface in the form of a Shiny app. However, additional information from the administrator is required for the app instance to connect with MongoDB, including: database user ID and password\ host server and port (default is 27017)\ database name\ whether or not Active Directory will be used for user authentication\ destination path to save the app, mapped from the R working directory The function save\_credentials() must be called to generate the app and associated Rdata file: ```r db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" use_LDAP <- TRUE app_path <- "Out/app" save_credentials(db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name, use_LDAP, app_path) ``` Both the app.R and db\_credentials.Rdata files must be uploaded to the Shiny instance. #### RStudio Connect App Upload This option assumes you have an account with your institution's RStudio Connect service. From within RStudio, simply navigate to the folder where the app was saved and click on the app.R file. Click the "Publish to Server" icon, making sure both necessary files are included and hit "Publish". #### RStudio Server App Upload A discussion of the installation process and use of Shiny Server is beyond the scope of this manual; pertinent information can be found on the maker's [website](https://rstudio.com/products/shiny/download-server/). The CEDARS app.R and db\_credentials.Rdata files should be uploaded to the desired app directory. ### Database Setup Creating the database and populating it with data pertaining to the project occurs as follows: ![Preparing the Database](https://2797339908-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-ML9SpEg76Jeuy-dRmhY%2Fuploads%2Fgit-blob-7deee685abc2d72505651dee4d14ec7342a4af8b%2FGitHub%20Schema%203%20E.png?alt=media) #### Project Initialization Each data collection task on a given cohort of patients is a distinct CEDARS "project" with its own MongoDB database including all collections needed to operate. Different projects cannot share the same database or collections. This encapsulation allows for reliable backup and deletion of project data upon completion, also avoiding data corruption due to cross-talk between different annotation tasks. Initialization is the process by which necessary collections are generated and populated with project-specific data. The function create\_project() generates a database which will hold all collections pertaining to the project. If the CEDARS project administrator has database creation privileges, a new MongoDB instance will be created and collections generated automatically. If database creation privileges have not been granted, it is possible to have the MongoDB administrator create the blank database. Once this is done, create\_project() can be used to generate the collections: ```r uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" project_name <- "CEDARS Example Project" project_owner <- "Dr Smith" create_project(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name, project_name, project_owner) ``` If the option to use Active Directory was set to FALSE when creating the app, the add\_end\_user() function must be used to add end users (i.e. data abstractors) to the project: ```r new_end_user <- "John" new_end_user_pw <- "strongpassword" add_end_user(uri_fun, db_user_name, db_user_pw, db_host, db_port, db_name, new_end_user, new_end_user_pw) ``` #### Electronic Health Record Corpus Upload Function upload\_notes() is used to transfer the raw clinical corpus to the CEDARS database. This would typically consist of a collection of clinical notes or radiology reports formatted as a dataframe with the follwing fields: "patient\_id" Patient-specific unique identifier, typically a medical record number\ "text\_id" Unique identifier for the text segment\ "text" Text segment, can be a whole note or a section, sub-section etc.\ "text\_date" Date of the clinical encounter or radiology test\ "doc\_id" Unique identifier or the document\ "text\_sequence" Optional, if a document contains more than one text segment (each with a distinct text\_id), this field indicates the order of the segments/sections\ "text\_tag\_1" Optional metadata, for example patient's name, medical professional name, note section name, etc.\ "text\_tag\_2" Optional metadata\ "text\_tag\_3" Optional metadata\ "text\_tag\_4" Optional metadata\ "text\_tag\_5" Optional metadata\ "text\_tag\_6" Optional metadata\ "text\_tag\_7" Optional metadata\ "text\_tag\_8" Optional metadata\ "text\_tag\_9" Optional metadata\ "text\_tag\_10" Optional metadata ```r # patient_notes previously generated by user uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" upload_notes(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name, patient_notes) ``` In a typical use case, there would be a large number of patients/notes located on a separate server, so a custom batch function to download notes and transfer to CEDARS one patient at a time would have to be devised, e.g.: ```r for (i in 1:10000){ recnum <- patient_list$recnum[i] download_notes <- sqlQuery(origin_db_rodbc, paste(c("SELECT * FROM CORE_DB WHERE RECNUM = \'", recnum), collapse="")) # convert field names and ensure their format is compliant with CEDARS if (length(download_notes[,1])>0){ upload_notes(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name, download_notes) print(paste("notes uploaded for patient #", i, sep="")) } else print(paste("no notes for patient #", i, sep="")) } ``` Once all notes or reports have been uploaded, unique values for metadata tags can be obtained with the download\_filtered\_tags() function. This can be useful to select specific documents types to include/exclude in the query. By default, tags featured in the uploaded corpus will we matched with the stored CEDARS query but this can be overridden: ```r uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" tag_list <- download_filtered_tags(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name, eval_query = TRUE) ``` #### Natural Language Processing Annotation CEDARS uses the [UDPipe](https://cran.r-project.org/web/packages/udpipe/vignettes/udpipe-annotation.html) natural language processing (NLP) pipeline for paragraph/sentence boundary detection, tokenization, lemmatization, part-of-speech tagging and dependency parsing. The function automatic\_NLP\_processor() will assess the project for missing annotations and process documents as needed: ```r uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" txt_format <- "latin1" # Only UDPipe is supported for now nlp_type <- "udpipe" # Use your favorite model, can be standard issue or custom fitted udmodel_path <- "C:/R/NLP_models/latestversion.udpipe" # We are not using UMLS concept unique identifiers max_n_grams <- 0 # Negation will look up to 6 positions away from index token neg_depth <- 6 # CEDARS supports parallel processing sel_cores <- 10 automatic_NLP_processor(NA, txt_format, nlp_type, udmodel_path, uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name, max_n_grams, neg_depth, sel_cores) ``` #### Event Pre-Loading Sometimes a cohort of patients will already have been assessed with other methods and CEDARS is used as a redundant method to pick up any previously missed events. In this use case, a list of known clinical events with their dates will exist. This information can be loaded on CEDARS as a "starting point", so as to avoid re-discovering already documented events. The function upload\_events() can be used to insert these data: ```r # event_dates is dataframe with patient unique ID's and event dates uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" upload_events(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name, event_dates$patient_id, event_dates$event_date) ``` #### Search Query Definition The CEDARS search query incorporates the following wildcards: "?": for one character, for example "r?d" would match "red" or "rod" but not "reed" "\*": for zero to any number of characters, for example "r\*" would match "red", "rod", "reed", "rd", etc. CEDARS also applies the following Boolean operators: "AND": both conditions present "OR": either present present "!": negation, for example "!red" would only match sentences without the word "red" Lastly, the "(" and ")" operators can be used to further develop logic within a query. #### Pre-Search Once NLP annotations are complete and the search query has been defined, if an end user logs into CEDARS the system will automatically start parsing the annotations for matches. However, depending on the frequency (density) of hits, it can take several seconds to find a sentence to present the end user with. This can impact user experience, especially in multi-user settings. Because of this aspect, ideally records should be pre-searched: ```r uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" # All patient records will undergo a pre-search record_vect <- NA pre_search(record_vect, uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name) ``` The result is a shorter interface reaction time and more efficient data entry. ### Assessment of Clinical Events The process by which human abstractors annotate patient records for events is described in the [End User Manual](/cedars_end_user_manual). ### Dataset Download Once there are no sentences left to review, event data can be obtained from the database with function download\_events(). ```r uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB" output <- download_events(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name) ``` Detailed information is provided, including which sentences were reviewed. ### Audit CEDARS is by definition semi-automated, and depending on the specific use case and search query some events might be missed. This problem should be quantified by means of a systematic, old-fashion review of randomly selected patients. Typically, at least 200 patients would be selected and their corpora reviewed manually for events. Alternatively, a different method (e.g. billing codes) could be used. This audit dataset should be overlapped with the CEDARS event table to estimate sensitivity of the search query in the cohort at large. If this parameter falls below the previously established minimum acceptable value, the search query scope should be broadened, followed by a database reset, uploading of previously identified events and a new human annotation pass, followed by a repeat audit. ### Project Termination Once all events have been tallied and the audit results are satisfactory, if desired the CEDARS project database can be deleted from the MongoDB database. This is an irreversible operation: ```r uri_fun <- mongo_uri_standard db_user_name <- "myname" db_user_pw <- "mypassword" db_host <- "myserver" db_replica_set <- "my_mongo_set" db_port <- 27017 db_name <- "MyDB terminate_project(uri_fun, db_user_name, db_user_pw, db_host, db_replica_set, db_port, db_name) ``` ## Function Reference The full function reference can be found [here](https://cedars.io/docs/CEDARS.pdf). # End User Manual ## Introduction This short manual is intended for data abstractors who will enter information about clinical events detected by CEDARS. CEDARS is a data pipepline set up to optimally present you with sentences drawn from a patient's medical record and potentially indicating the presence of a clinical event. Sentence detection is automatic and based on the words used, but often those sentences do not actually represent a true event. For example, the following sentence does not signal an actual new thrombotic episode: "The patient was ruled-out for deep vein thrombosis last night." If sentence detection is based only on reporting sentences with the words "deep vein thrombosis", such a negative finding will be reported. In this case, you would not report an event and move on to the next sentence. Event detection approaches used by your CEDARS system administrator will vary, and some queries will be more selective than others, but generally the system will be set up to detect as many events as possible, at the cost of having a certain number of false positive findings. The intent here is for CEDARS to minimize the number of missed events, even if this approach results in you having to review a greater number of sentences. Sentences are presented in chronological order. Once you have identified and dated a clinical event, CEDARS might be set up by bypass all following sentences for this patient and move on to the next patient. This approach will be used when your system administrator only aims at capturing the first instance of an event of interest. Also, once you have evaluated all sentences of interest for a given patient, CEDARS will move on to the next patient seamlessly. This sequence of events is illustrated below: ![CEDARS Workflow](https://2797339908-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-ML9SpEg76Jeuy-dRmhY%2Fuploads%2Fgit-blob-f438d90702a449b0f1a4ae720f2cf252207bb20d%2FGitHub%20Schema%202%20C.png?alt=media) If you adjudicate a sentence as reporting no event, CEDARS will present the next sentence for the same patient (#1). On the other end, if you enter an event date, CEDARS will move to the next unreviewed sentence before the event date. If there are no sentences left to review before the event, the GUI moves to the next patient (#2) and the process is repeated with the following record (#3 and #4), until all selected sentences have been reviewed. ## Login ### Using RStudio Connect Using an internet browser, navigate to the web page provided by your CEDARS system administrator. Enter your user ID and password. ## Find Clinical Events As soon as you are logged in, CEDARS will start looking for the next available patient with information to review. It might take a few moments before the first sentence is presented to you. The following is an example from a simulated cohort: ![Simulated Patient Example - Data Entry Interface](https://2797339908-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-ML9SpEg76Jeuy-dRmhY%2Fuploads%2Fgit-blob-7cce09b039c3e817fcb2c91ba251c117b8251109%2Finterface%20A.png?alt=media) Keywords or concepts are highlighted in red to help you locate them in the text. ### Evaluating a Sentence Only one sentence to review will be presented at any given time. It can be found at the beginning of the section titled "Selected sentence:". Your first task is to determine whether or not the sentence refers to an actual clinical event of interest, i.e. if the sentence is a true positive. Typically you will be able to make up your mind just by reading the sentence itself. If the sentence is ambiguous and you would like to obtain more context, you can review the note or report from which the sentence was drawn, situated at the bottom of the screen under the section "Selected note:". Also, completely at the bottom of the screen you will find a list of tags with associated data. The information presented here will vary, but would typically include the patient's name, the type of note, the author etc. For your reference, the date of entry for the note from which the sentence was drawn is indicated below the sentence, along with sentence position (first, second, third in line for review, etc) and patient ID. ### Annotating a Negative Sentence In many cases, the sentence you are looking at will be a false positive, i.e. it does not represent the kind of event you were tasked to report. In this case, simply click on the button "ADJUDICATE SENTENCE". This will mark the sentence as such and move to the next one in line. ### Move Between Sentences Within a Patient's Record Often the sentence and note presented to you will hint at a possible event but remain ambiguous, or an event will be obvious but the timing unclear. In such cases, you can move from sentence to sentence by using the "<<< PREVIOUS" and "NEXT >>>" buttons. You will go from sentence to sentence, following the timeline of electronic record notes/reports. Note that using previous/next will not annotate sentences or otherwise enter information in the CEDARS database. ## Entering Information About a Patient ### Entering an Event Date Any known event date will be displayed at the beginning of section titled "Event date:". Most of the time this field will be empty, since generally speaking CEDARS projects aim to determine event dates for a cohort for which no prior information exists. However, CEDARS can also be used to verify known event dates, in which case the interface might display an event date for a patient you have not yet assessed. Your CEDARS system administrator will discuss this aspect with you before starting the project. Once you have determined a clinical event did indeed occur, the next step is to assess its timing. As noted above, you might have to travel between sentences or consult complete notes to confirm the date. Once you are ready to enter this information, click on the data entry field under the "ENTER NEW DATE" button. You will be prompted with a calendar. Once the date displayed is correct, press on button "ENTER NEW DATE". Given the nature of clinical narratives, not all events will be precisely dated. For example, a clinician might refer to an event only with the month and year, not the day. Such information can still be entered by using simple approximation guidelines. In CEDARS, if only the year of an event is known, enter July 1st of that year (e.g. "2020-07-01"). If only they year and month are known, enter the 15th day of that month/year (e.g. "2020-11-15" if the event was in November of 2020). When approximating a date, it is good practice to document this detail in a comment (see below). ### Deleting an Event Date It is possible to replace an erroneous date by entering a new one in the date entry field. If there was actually no event, the previously entered date can be deleted by clicking on button "DELETE OLD DATE". ### Entering Comments About a Patient At any point you can enter comments about a patient in the data entry field under "New comments:", however those will be saved only if you 1) adjudicate the sentence or 2) enter an event date. ## Search for a Specific Patient If you want to go back to a specific patient later on, take note of the patient ID number. After logon, CEDARS will automatically present you with the next available patient to review, so if you have already annotated all sentences for a given patient, the only way to find that record again is to do a search. In this case, simply enter the patient ID number under in the box under "Search for patient" and click button "SEARCH". If you click "SEARCH" on an empty field, CEDARS will bring up the next available patient for you to review. ## Record Locking Only one end user at a time can review or enter information about any given patient in the CEDARS database. If someone else is already looking at a specific patient record, you will be locked from accessing it.