Identifying Unmet Treatment Needs for Patients With Osteoporotic Fracture: Feasibility Study for an Electronic Clinical Surveillance System

Background Traditional clinical surveillance relied on the results from clinical trials and observational studies of administrative databases. However, these studies not only required many valuable resources but also faced a very long time lag. Objective This study aimed to illustrate a practical application of the National Taiwan University Hospital Clinical Surveillance System (NCSS) in the identification of patients with an osteoporotic fracture and to provide a high reusability infrastructure for longitudinal clinical data. Methods The NCSS integrates electronic medical records in the National Taiwan University Hospital (NTUH) with a data warehouse and is equipped with a user-friendly interface. The NCSS was developed using professional insight from multidisciplinary experts, including clinical practitioners, epidemiologists, and biomedical engineers. The practical example identifying the unmet treatment needs for patients encountering major osteoporotic fractures described herein was mainly achieved by adopting the computerized workflow in the NCSS. Results We developed the infrastructure of the NCSS, including an integrated data warehouse and an automatic surveillance workflow. By applying the NCSS, we efficiently identified 2193 patients who were newly diagnosed with a hip or vertebral fracture between 2010 and 2014 at NTUH. By adopting the filter function, we identified 1808 (1808/2193, 82.44%) patients who continued their follow-up at NTUH, and 464 (464/2193, 21.16%) patients who were prescribed anti-osteoporosis medications, within 3 and 12 months post the index date of their fracture, respectively. Conclusions The NCSS systems can integrate the workflow of cohort identification to accelerate the survey process of clinically relevant problems and provide decision support in the daily practice of clinical physicians, thereby making the benefit of evidence-based medicine a reality.

. Image of Clinical Orders Navigator

Clinical Order Type:
The researcher can choose different clinical order types include diagnosis, drug, laboratory and so on.

Search Mode:
Two mode can be chose: Default Mode and Template Mode. If the researcher wants to define a set of clinical orders by himself, he can choose the default mode.
In addition, researcher can also use the public templates by choosing template mode which was defined a set of clinical orders contributed by other researchers.

Jump to Template Library:
If you want to browse which public templates are available, you can click the hyperlink to navigate the Template Library.

Query Keywords:
3 In order to improve the accuracy and flexibility for clinical orders search, in NCSS, support full text search and fuzzy search with wildcards. %: Allows you to match any string of any length _: Allows you to match any string of one length

Search Button:
To run the search based on the input values of Query Keywords and Clinical Order Type.

Query Result:
Researchers can click the checkbox in the table which presents the search result to decide which clinical orders they selected.

Add Button:
Synchronize clinical orders to MODULE II Orders Components according to the clinical orders they selected.      1. When the researcher selected the Template mode and entered the keyword-"CCI%" and then the Clinical Orders Navigator will search from the Template Library.
2. The search results found a record of the CCI (Charlson Comorbidity Index).
The researcher can click the label (blue text) and then it will pop-up a window to show the detail about all orders in the template.
3. The researcher can click the "Use Template" button and it will synchronize all clinical orders to MODULE II: Orders Components from this template.

Clinical Order Type:
To record the current clinical order type, such as pharmacy and laboratory.

Order Detail:
To record uniquely identifies and description for each clinical order. For example, if the clinical order type is diagnosis, it will record the ICD-9 code and its description.

Category:
Module II provide a way to help researchers designing a series of categories, because most of the clinical orders were in a collection.

Score:
If you want to give a weight to the clinical orders to calculate some indicators, like 10 CCI (Charlson Comorbidity Index), and then you can fill in a score based on the literature or guideline. The field is not required.

Export to Excel:
Because of Criteria Components store clinical domain knowledge, we also implement some batch function, such as export/import form Excel that allow researchers to process batch insert, update and export those criteria, easily.

Case I: [Osteoporotic Fracture] Incident Case
GOAL: Find the patients diagnosed with hip or vertebral fractures and age greater than 50 years old between 2010/01/01 and 2014/12/31. We based on workflow to introduce each stage, as depicted in Figure 10.
-Category: ICD-9-codes with 805 and 806 set "Fracture" as a category and ICD-9-codes with 820 set "hip" as a category.

Use Template:
If you click the 'Use Template' button, this template will synchronize to the orders component. There synchronized 96 diagnosis codes in order setting.

Order Setting:
There are two criteria: First, researchers define the 96 diagnosis codes which have been synchronized to the Orders Component. Second, filtering the age between 50 to 130.

16
The setting of case "[Osteoporotic Fracture] Incident Case" had been authorized, it was been added a task to Task Queue for cloud batch process in server side. The cloud batch process maintains a Task Queue. Every task will be executed follow First-In-First-Out (FIFO) mechanism in batch server that read the setting of Identification to query eligible patients in IMDB. After completion of the task, the patient list will be stored into database and send a mail notification to researchers. Finally, the case's status become "Finished" in Data Mart.

View of Characteristics:
The view is demographic summary that help clarify the characteristics for patient list. For example, the descriptive statistics of age, gender, body mass index (BMI), income level, as show as figure 12.

View of Source Record:
The view present number of include/exclude patients in every Identification process. If the patient list contains hierarchical structure that run the process of identification more than once, the Report Service can track all result of identification in aggregation table, as show as figure 14. Service. We designed a mechanism for reusing the patient list in the Data Mart. We believe that this identified list of patients should be reused, especially for the design of subgroup study, case control study, or research on a similar context. To better interpret the identification process of each patient list, we designed a hierarchical structure, using which each patient list could be traced back to its patient data source and researchers could compare every patient data source with the characteristics and longitudinal incidence trend in the Report Service. We aimed to describe the advantages of the hierarchical structure, and compare the differences between Cases I and II.

Use Template:
If you click the 'Use Template' button, this template will synchronize to the orders component. There synchronized 586 diagnosis codes in order setting.

Order Setting:
There are two criteria: First, researchers define the 586 diagnosis codes which have been synchronized to the Orders Component and every diagnosis code have 2 status -NOT and before 365 day.
-Include / Exclude : NOT -Limitation of index : before 365 day The patient will be excluded when he/she is diagnosed with a malignant neoplasm within one year before the index date (newly diagnosed with a hip or vertebral fracture) by the Cloud Batch Process.

Characteristics view:
The characteristics view implies the demographic summary of the characteristics that helps clarify them for a patient list. For the case "[Osteoporotic Fracture] excluding malignant neoplasm", we can realize the descriptive statistics of age, gender, body mass index (BMI), income level, as show in Figure 17. Further, the results of Case I can be compared with those in Figure 12 to understand that the number of males decreased from 1,583 to 1,356, while the number of females decreased from 3,115 to 2,785.

Longitudinal Incidence Trend view:
Case II has a hierarchical structure, using which each patient list could be traced back to its patient data source. Figure 15 shows two patient lists: Case I "[Osteoporotic Fracture] Incident Case (73)" and Case II "[Osteoporotic Fracture] excluding malignant neoplasm". The end user could compare every patient list by using the longitudinal incidence trend at specific intervals such as monthly, quarterly, and yearly. We compared Cases I and II quarterly with respect to the Longitudinal Incidence Trend view and stratified them based on gender, as shown in Figure 18.

Source Record view:
Here, we describe the advantages of the hierarchical structure in the Source Record view. As Case II contains a hierarchical structure that runs the process of identification more than once, the Report Service can track all the results of identification in the aggregation table. Finally, we can obtain a source record report.
The Source Record view presents the number of patients included/excluded in every Identification process, as shown in Figure 19.