Data Model: Structure and Function

In our article on OIDM-based reporting assistance, we described a framework by which a reporting system exposes data about the current reporting context to plugins, which are then able to use that context to potentially offer assistance back to the reporting radiologist via standardized commands. Let's take a deeper dive into the nature of that data context—what should be in it, and how it should be structured. This is the essence of the Open Imaging Data Model—representing the context surrounding an imaging exam. This data model would be the core of a "SDK" for the assisting plugins.

Core Data Model Elements

• Observations: These are the individual radiology findings that the radiologists is describing in their current report, structured as CDE-labeled FHIR Observations.

• Current Report Text: The actual text of the current report, ideal represented as hypertext with tags indicating the relationships between elements of the text and Observations/component values.
• Imaging Stud(y|ies): The information on the imaging studies that are the subject of the report. This can make use of a standard reference library of exam type definitions (described below) for standard information but might include specific information about the performance of the exam, including DICOM metadata and image data, as well as operational data such as timestamps.
• Patient: Core information on the patient who is the subject of the report.
• Order: Information on the order(s) that led to the stud(y|ies) being reported on.
• Prior Imaging Studies: Representations of the patient's imaging history, including both report text and structured Observation objects.
• Tracked Observations: An index of the association of the same radiology finding (e.g., a tumor or a fracture) and the way it has been represented as Observation objects during different imaging studies in the patient's history.
• EHR Data: A subset of EHR-based results associated with the patient, including perhaps lab results, operative notes, pathology reports, pathology results, problem list data, medication lists, etc.

Utility Libraries/Datasets

These are standardized data that can be re-used to enable standard reference values for anatomy and performed exams. They will include libraries that enable easy integration.

• Body Part: See anatomiclocations.org. A standard set of tags associated with common ontologies (RadLex, SNOMED, ACR Common) for body parts used in radiology reporting, with hierarchy and other information appropriate for informatics applications.

• Exam Type: Sister project to the anatomic location index. This library is based on LOINC Playbook, but also tightly connected to standard anatomic locations for both the imaging area of focus but also included body regions. For example, the entries referring to chest CTs represent the focus as the chest, but also reflect that lower neck and upper abdominal structures are included in the exam.

Relationship to FHIR

• The data model is intended to make extensive use of FHIR definitions in its structuring, but will likely reflect a superstructure on top of these FHIR definitions to both organize them and enable more straightforward programmatic access to the data.

An analogy for the relationship between OIDM and FHIR might be that between the browser's DOM and HTML. The DOM reflects the HTML, but provides easier access to its content, and also contains a superstructure of additional context information.

• The reference implementations should be able to take in FHIR objects (such as Observations, reports, patient/order information etc.) and make them available for manipulation where appropriate.
• Reference implementations as part of OIDM should be able to export FHIR representations (e.g., the Observation object should be able to generated FHIR in the CDE-labeled FHIR Observation format, and the entire current report should be able to be exported as FHIR.