Longitudinal clinical decision support for assessing decisions over time: State-of-the-art and future directions.

Objective: Patients and clinicians rarely experience healthcare decisions as snapshots in time, but clinical decision support (CDS) systems often represent decisions as snapshots. This scoping review systematically maps challenges and facilitators to longitudinal CDS that are applied at two or more timepoints for the same decision made by the same patient or clinician. Methods: We searched Embase, PubMed, and Medline databases for articles describing development, validation, or implementation of patient- or clinician-facing longitudinal CDS. Validated quality assessment tools were used for article selection. Challenges and facilitators to longitudinal CDS are reported according to PRISMA-ScR guidelines. Results: Eight articles met inclusion criteria; each article described a unique CDS. None used entirely automated data entry, none used living guidelines for updating the evidence base or knowledge engine as new evidence emerged during the longitudinal study, and one included formal readiness for change assessments. Seven of eight CDS were implemented and evaluated prospectively. Challenges were primarily related to suboptimal study design (with unique challenges for each study) or user interface. Facilitators included use of randomized trial designs for prospective enrollment, increased CDS uptake during longitudinal exposure, and machine-learning applications that are tailored to the CDS use case. Conclusions: Despite the intuitive advantages of representing healthcare decisions longitudinally, peer-reviewed literature on longitudinal CDS is sparse. Existing reports suggest opportunities to incorporate longitudinal CDS frameworks, automated data entry, living guidelines, and user readiness assessments. Generating best practice guidelines for longitudinal CDS would require a greater depth and breadth of published work and expert opinion.

Striking a match between FHIR-based patient data and FHIR-based eligibility criteria.

Inputs and Outputs: The Strike-a-Match Function, written in JavaScript version ES6+, accepts the input of two datasets (one dataset defining eligibility criteria for research studies or clinical decision support, and one dataset defining characteristics for an individual patient). It returns an output signaling whether the patient characteristics are a match for the eligibility criteria. Purpose: Ultimately, such a system will play a "matchmaker" role in facilitating point-of-care recognition of patient-specific clinical decision support. Specifications: The eligibility criteria are defined in HL7 FHIR (version R5) EvidenceVariable Resource JSON structure. The patient characteristics are provided in an FHIR Bundle Resource JSON including one Patient Resource and one or more Observation and Condition Resources which could be obtained from the patient's electronic health record. Application: The Strike-a-Match Function determines whether or not the patient is a match to the eligibility criteria and an Eligibility Criteria Matching Software Demonstration interface provides a human-readable display of matching results by criteria for the clinician or patient to consider. This is the first software application, serving as proof of principle, that compares patient characteristics and eligibility criteria with all data exchanged using HL7 FHIR JSON. An Eligibility Criteria Matching Software Library at https://fevir.net/110192 provides a method for sharing functions using the same information model.