> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.emtelligent.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.emtelligent.com/_mcp/server. # Reported Event Relations This section describes the reported event relation, its NLP API JSON output and database schema. It also contains a sample query that illustrates how this relation can be used. After reading this page, we hope you will: * Understand what reported event relations are. * Understand what attributes are extracted for this relation. * Know how to find reported event relations and their attributes. The content in this section builds on the concepts and data models explained in earlier sections (see [Entity-level Tables](/nlp/database/schema/core/entity-tables)). > **Warning** > > Reported event relations are only extracted from these sections of **Radiology** reports: FINDINGS, IMPRESSION, COMMENTS and CRITICAL RESULTS COMMUNICATION, and other sections mapped to these sections. For example, the heading CALLED REPORT is mapped to CRITICAL RESULTS COMMUNICATION. ## What are Reported Event Relations Reported event relations are identified in text when the text details that a person has communicated (or `reported`) something to another person. An example of this would be, `"His father told Dr. Lee this morning that his cough was getting worse."` In this example, the patient's father reported an event (worsening of a cough) to Dr. Wong, at a certain time (this morning). The initial implementation of this relation in the NLP API is a special use case, that of critical results communication, used when a diagnostic physician identifies a finding on a diagnostic test that requires direct communication with the care provider who ordered the test. From the US Joint Commission 2022 Hospital National Patient Safety Goals (NPSGs) report, the #2 goal is to “Improve the effectiveness of communication among caregivers” with the key objective being the timely reporting of critical results of tests and diagnostic procedures (NPSG.02.03.01) . Critical results of tests and diagnostic procedures that fall significantly outside the normal range may indicate a life-threatening situation. The NPSGs recommendations for this safety goal include the following: * Develop written procedures for managing the critical results of tests and diagnostic procedures that address the following: * The definition of critical results of tests and diagnostic procedures * By whom and to whom critical results of tests and diagnostic procedures are reported * The acceptable length of time between the availability and reporting of critical results of tests and diagnostic procedures * Implement the procedures for managing the critical results of tests and diagnostic procedures. * Evaluate the timeliness of reporting the critical results of tests and diagnostic procedures. `(The above points are excerpts from Hospital NPSG 2022)` In the field of diagnostic medicine, to achieve this safety goal the diagnostic physician (e.g. a radiologist, nuclear medicine physician, pathologist, or cardiologist) that identifies an important diagnosis must, in addition to proper documentation of the finding in the patient's medical report report: 1. communicate the result directly, and 2. record in an auditable fashion that this communication had occurred. Hence, it is commonplace to find sentences in medical imaging reports like `“These findings were relayed via telephone to Dr. Smith at 0900h”`. To address the need to report and monitor the communication of critical results as a safety statistic, medical software vendors have developed tools and workflows to capture critical communications but uptake and actual day-to-day usage (at least anecdotally) has been poor. While diagnostic physicians are good at picking up the phone and communicating results, the extra step to record this event in a separate tool or workflow is a deterrent. A simpler and more natural workflow only requires physicians to remark at the end of reports that results were communicated. NLP-based data extraction is then used to generate the required reports. The reported event relation was designed specifically with this use case in mind. The NLP API’s reported event relation captures the notion of a communication between two groups of entities and associated attributes from sentences like this: ![Reported event relation arguments](/_fern-files/emtelligent-prod.docs.buildwithfern.com/2e58d2897e9eab49c448c4fd3aa7903429dde84c2b76acb121c695a05c2516a1/assets/nlp/reportedeventrelation_anno.png) The **subject** must be present for the report event to be extracted. The other attributes may be omitted, and often are. Other examples of sentences from which reported event relations can be extracted are: ```text IMPRESSION: The findings regarding ureteral calculi were discussed with Dr.Kenji at the time of the study. ``` In the above case, `ureteral calculi` is the subject. ```text IMPRESSION: Findings were discussed with Dr. Kenji in person at approximately 6 p.m. and again to Dr. Smith via telephone at 930pm on March 28th, 2022. ``` In this case, `two physicians` were informed and `multiple time expressions` are provided. The reported event relation attributes extracted by the NLP API are: * **Subject**: The `subject` entity is the topic of the communication. * **To entity**: The `person` with whom it was discussed, preferably a proper name like Dr. Smith, but possibly something like `the attending physician` as the author may not recall the physician's name. * **From entity**: The `person` that delivered the critical result. This is often omitted as it it assumed to be the author of the report * **Time Expression**: The `time and/or date` when the finding was discussed. Often just a time is reported (e.g. `0900h`, `13:40 hours`, `1:30 pm`) as it is implied that the date is the date of dictation, but the full date and time may also be reported. * **Communication method**: The `method` of communication (e.g. paged, telephoned, discussed in person, etc). * **Polarity**: The `polarity` attribute for this relation indicates whether the communication event occurred (polarity of `asserted`) or did not occur (`negated`). * **Category**: The only supported category of temporality is `critical_results` at the current time. For more complete reporting of reported events, software vendors may opt to use report templates or other mechanisms to prompt the user to provide these details when documenting the critical communication. ## Definition of Critical Results The NPSG does not specify the disorders or findings that constitute critical results. Typically, any diagnostic results which are potentially life-threatening acute findings or pathologies should be considered. The definition of critical results will be specific to a given medical service. For example, in radiology reports critical results would include findings such as (but not limited to) infarcts, hemorrhages, fractures, pneumothorax, ectopic pregnancies etc. The NLP API allows you to specify the set of disorders or findings to be considered critical results at query time. See [Query: Find all reported event relations](#query-find-all-reported-event-relations). To cast a wide net, you may also consider searching for `all` clinical findings by performing a hierarchical concept search for the SNOMED concept `404684003 | clinical finding (finding)`. For more information about using SNOMED CT concept hierarchies in queries, see [Using SNOMED CT Concept Hierarchies](/nlp/database/schema/extensions/snomed-hierarchies). ## JSON Data Model Below is the NLP API’s JSON result output for a reported event relation extracted from this statement: ![Reported event relation arguments](/_fern-files/emtelligent-prod.docs.buildwithfern.com/2e58d2897e9eab49c448c4fd3aa7903429dde84c2b76acb121c695a05c2516a1/assets/nlp/reportedeventrelation_anno.png) ```json { "relations": { "reportedevents": [ { "label": "RR0", "attributes": { "confidence": null, "category": "critical_results", "polarity": "asserted" }, "args": { "subject": { "ref": "E4", "text": [ "Findings" ] }, "to_entities": [ { "ref": "E1", "text": [ "Dr James Smith" ] } ], "from_entities": [ { "ref": "E2", "text": [ "Radiology Fellow" ] } ], "methods": [ { "ref": "E3", "text": [ "telephone" ] } ], "time_expressions": [ { "ref": "E0", "text": [ "2005-6-10 at 6:30 p.m" ] } ] }, "concept_links": [] } ] } } ``` From the JSON output above, we see that: * The `reportedevents` array is an element of the relations object. Each element of this array is a single object representing a reported event relation instance. * Each reported event relation instance has several named arguments: the `subject` and the `to_entities`, `from_entities`, `methods`, `time_expressions` * Note that the `subject` is required. The other arguments are optional (i.e. the reported event relation will be extracted even when the author has not provided values for them). * It is important to note the cardinality of the relation between subject and the other arguments. There is a **one-to-zero-or-more** relationship between the `subject` and other `arguments`. * A reported event relation has 2 attributes: category and polarity: * **category**: The only supported category of temporality is `critical_results` at the current time. * **polarity**: This attribute is indicates whether the physician remarked that the result **was communicated** (`asserted`) or **was NOT communicated** (`negated`). In practice, the `negated` case rarely occurs. ## Reported Event Relation Tables In the Output Database schema, reported event relations are stored in the **reportedeventrelation** table. Its attributes are stored in correspondingly-named tables as shown in the following ER diagram. ![Reported event relation tables](/_fern-files/emtelligent-prod.docs.buildwithfern.com/91a482b3a8ba51637140c384605cdd29c8605868e1bfb71d2e86d6ad501a5689/assets/nlp/reportedeventrelation_schema.png) A few key points should be noted about this schema: * Each reported event relation relates to exactly one **subject** term. Each subject mentioned is extracted as an **entity** in the Output Database schema, and has a corresponding row in the **entity** and **foundentity** tables respectively. * Like the **subject** entity, arguments of the reported relation (e.g. the method, receiving and sending physician ) are also entities and also have corresponding rows in the **entity** and **foundentity** tables. For the `to_entity` and `from_entity`, which are typically proper names, you will need to retrieve their value as the annotated term from the **foundentity** table. * A **subject** can have **zero or more** instances of the other argument types; for example, a critical result may be communicated `by phone` and `in person` (`method` arguments), to the `attending physician` and the patient’s `primary care physician` (`to_entities`), but the time of the event may be omitted. This is be important to remember when writing queries to retrieve all extracted values. An additional aggregation step will also be required to aggregate the terms or concepts for each attribute type. > **Warning** > > Because there is a **one-to-zero-or-more relationship** between the **subject** of a reported event relation and other arguments (e.g. `to_entity`, `from_entity` etc), when querying for reported event relations you must use LEFT JOINs and aggregate the values retrieved for these arguments. See [Query: Find all reported event relations](#query-find-all-reported-event-relations). ## Sample Queries In this section, we present SQL queries that retrieve information about reported event relations for initial data exploration. An example is provided: * [Query: Find all reported event relations](#query-find-all-reported-event-relations) ### Query: Find all reported event relations This query finds all extracted reported event relations and their attributes. This query is useful for reviewing the output of the reported event relation extraction feature. The following query uses the **reportedeventrelation** table and performs joins with the **entity** and **foundentity** tables to retrieve the term (annotated text), section heading, and sentence. Because we want to return one row per reported event, we must handle the cases where multiple values are given for each argument (e.g. when results are communicated to multiple physicians). To do this, we concatenate the values for each argument separately in a CTE using the string aggregation function before assembling the values in the outer SELECT clause. ```sql WITH reportedevents AS ( SELECT ev.*, rel.document_id FROM relation rel JOIN reportedeventrelation ev ON rel.relation_id = ev.id AND rel.type_='reportedevent' WHERE ev.category = 'critical_results' ), to_persons AS ( SELECT ev.reported_event_id, string_agg(fe.text, ', ') as to FROM reportedeventrelationtoentity ev JOIN entity e ON ev.entity_id = e.id AND e.type_='found' JOIN foundentity fe ON e.entity_id = fe.id GROUP BY ev.reported_event_id ), from_persons AS ( SELECT ev.reported_event_id, string_agg(fe.text, ', ') as from FROM reportedeventrelationfromentity ev JOIN entity e ON ev.entity_id = e.id AND e.type_='found' JOIN foundentity fe ON e.entity_id = fe.id GROUP BY ev.reported_event_id ), methods AS ( SELECT ev.reported_event_id, string_agg(fe.text, ', ') as method FROM reportedeventrelationmethod ev JOIN entity e ON ev.entity_id = e.id AND e.type_='found' JOIN foundentity fe ON e.entity_id = fe.id GROUP BY ev.reported_event_id ), time_exprs AS ( SELECT ev.reported_event_id, string_agg(fe.text, ', ') as when FROM reportedeventrelationtimeexpression ev JOIN entity e ON ev.entity_id = e.id AND e.type_='found' JOIN foundentity fe ON e.entity_id = fe.id GROUP BY ev.reported_event_id ) SELECT cr.id, cr.category as event_category, cr.polarity as event_polarity, sub_c.description as concept, sub_c.concept_id, sub_fe.text as subject_term, tp.to, frp.from, m.method, te.when, sl.text as sentence, d.id as doc_id FROM reportedevents cr -- get subject JOIN entity sub_e ON cr.subject_id = sub_e.id AND sub_e.type_='found' JOIN foundentity sub_fe ON sub_e.entity_id = sub_fe.id JOIN foundentityconcept sub_fec on sub_fe.id = sub_fec.found_entity_id AND sub_fec.concept_ontology = 'snomed' JOIN concept sub_c on sub_fec.concept_id = sub_c.concept_id and sub_fec.concept_ontology = sub_c.ontology -- get critical result communication details LEFT JOIN to_persons tp ON cr.id = tp.reported_event_id LEFT JOIN from_persons frp ON cr.id = frp.reported_event_id LEFT JOIN methods m ON cr.id = m.reported_event_id LEFT JOIN time_exprs te ON cr.id = te.reported_event_id -- get document info JOIN document d ON cr.document_id = d.id JOIN foundentitylocation fel ON sub_fe.id = fel.found_entity_id JOIN location l on fel.location_id = l.id AND l.type_='sentence' JOIN sentencelocation sl ON l.location_id = sl.id ORDER BY cr.document_id, sub_fe.start; ``` | id | event_category | event_polarity | concept | concept_id | subject_term | to | from | method | when | sentence | doc_id | | -- | ---------------- | -------------- | ------------------------------------ | ---------- | ---------------------- | ------------- | --------- | ---------- | ----------------- | --------------------------------------------------------------------------------- | ------ | | 1 | critical_results | asserted | Clinical finding (finding) | 404684003 | findings | Dr. Chen | — | — | 2/3/2022 10:46 PM | These findings were communicated to Dr. Chen on 2/3/2022 10:46 PM. | 20 | | 2 | critical_results | asserted | Fracture of scapular body (disorder) | 40643005 | scapular body fracture | Dr. Hayward | — | — | 9:15 a.m | The scapular body fracture was communicated to Dr. Hayward in the ER at 9:15 a.m. | 28 | | 3 | critical_results | asserted | Tension pneumothorax (disorder) | 233645004 | tension pneumothorax | Dr. West | — | telephone | 0900h | The tension pneumothorax was communicated to Dr. West via telephone at 0900h. | 29 | | 4 | critical_results | asserted | Small bowel obstruction (disorder) | 281255004 | SBO | Dr. Clacher | Dr. Zheng | telephone | 8:15 pm | The SBO was communicated by telephone to Dr. Clacher by Dr. Zheng at 8:15 pm. | 56 | | 5 | critical_results | asserted | Clinical finding (finding) | 404684003 | findings | Dr. Smith | — | — | 1715 hours | The findings were reported to Dr. Smith at 1715 hours. | 91 | | 6 | critical_results | asserted | Bleeding (finding) | 131148009 | hemorrhage | Dr. Ko | — | was phoned | 9:31 a.m | This hemorrhage was phoned to Dr. Ko at 9:31 a.m. | 96 | | 7 | critical_results | asserted | Deep venous thrombosis (disorder) | 128053003 | DVT | Dr. Khokorova | — | telephoned | 11:30 a.m | The DVT was telephoned to Dr. Khokorova at 11:30 a.m. | 105 | | 8 | critical_results | asserted | Breast lump (finding) | 89164003 | breast mass | Dr. Hsu | — | telephoned | 12:05 pm | The findings regarding the breast mass were telephoned to Dr. Hsu at 12:05 pm. | 109 | | 9 | critical_results | asserted | Clinical finding (finding) | 404684003 | findings | Dr. Wu | — | telephone | 15:30 | These findings were discussed with Dr. Wu at 15:30 via telephone. | 128 | ## References [Joint Commission - National Patient Safety Goals](https://www.jointcommission.org/resources/news-and-multimedia/fact-sheets/facts-about-national-patient-safety-goals/)