Striking a match between FHIR‐based patient data and FHIR‐based eligibility criteria

Abstract

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.

1. INTRODUCTION

Clinicians face many challenges to provide their patients with evidence‐based care. Despite significant effort, the medical error persists as the third or fourth leading cause of death in the United States. ¹ , ² Decision support systems are seen as a bridge to closing the medical error gap, improving adherence with evidence‐based practices (reducing medical errors of omission), and reducing the utilization of non‐indicated or harmful treatments (reducing medical errors of commission).

Examples of decision support include identifying clinical practice guideline recommendations that apply to the patient, selecting patient decision aids that include information pertinent to the patient, informing the decision with evidence (research results) that are generalizable to the individual patient, recognizing care decisions that are used for clinical quality performance measurement, and finding clinical trials in a recruitment stage for which the patient is eligible. Given the rapid growth of evidence, it is not feasible for individual clinicians to be aware of all the published evidence for each specific disease process, thus introducing knowledge gaps driving medical error. Advances in health information technology and decision support can bridge these gaps.

A common challenge across the many types of decision support is matching the characteristics of the patient to the criteria to which the decision support knowledge applies. The criteria for which the decision support knowledge applies is defined herein as eligibility criteria regardless of whether they are eligibility criteria for participation (eg, for a research study) or for application (eg, indication for therapeutic intervention).

Such eligibility criteria are often complex and are typically expressed in forms not immediately interpretable by a machine, for example, “Key inclusion criteria were the following: age 30‐67, under a doctor's care for type 2 diabetes for at least 6 months prior to recruitment; a HbA1c ≥ 8.0% at the time of entry; and a serum C‐peptide level >1.0 ng/ml 90 minutes after a liquid mixed meal of Ensure® (250 calories, 6 g fat/40 g carbohydrate/9 g protein)”. ³

To support initial demonstrations of the utility of structured eligibility criteria in a standard form, a matching algorithm was created to support common types of criteria (age, race, conditions, observations, and combination of criteria using Boolean logic).

Figure 1 shows the six data transformations necessary for converting our unstructured knowledge of patients and eligibility criteria into a machine‐processable function to determine matching, represented in a commonly used multi‐layered framework for disseminating knowledge for computer‐based decision support. ⁴ This framework includes narrative text (L1), semi‐structured organized text (L2), structured data coded and interpretable by computer (L3), and executable data coded and interpretable by clinical decision support (CDS) systems (L4). Figure 1 adds a fifth layer (L5) for the system implementation using the executable data (L4). Data representing eligibility criteria are labeled E1 through E4 and data representing patient characteristics are labeled P1 through P4 corresponding to the four layers in the knowledge representation framework. A data transformation from L1 to L3 directly is shown in Figure 1 (no L2 representation) because the systems commonly used provide structured data (L3) upon data entry coming from the unstructured data (L1) in the human mind. The system implementation (L5) is represented as EP5 to convey the integration of E4 and P4 data.

FIGURE 1.

Six data transformations are needed to automate matching patients to eligibility criteria.

Substantial amounts of data representing patient characteristics are now available in machine‐interpretable form (using Health Level Seven International [HL7] Fast Healthcare Interoperability Resources [FHIR] format for interoperable data exchange with electronic health records), matching P1–P3 conversion in Figure 1. There is a potential for greater efficiency if eligibility criteria could be made available in machine‐interpretable form (E1 to E3) using similar methods because the later conversions reaching the Logic Processor (EP5) could be developed with similar tooling.

There are a number of efforts to provide structured eligibility criteria in a computable expression language (E4), such as Clinical Quality Language (CQL), and either convert eligibility criteria to this expression language (E1–E3–E4) using natural language processing (NLP) ⁵ , ⁶ or developing authoring tools to facilitate subject matter experts directly expressing their eligibility criteria in the expression language (such as the CDS Authoring Tool). ⁷ , ⁸ , ⁹ However, there are relatively few execution engines (EP5) that are able to evaluate CQL queries. ¹⁰ Efforts to extract patient data in FHIR to convert to other formats for execution engines not using CQL (eg, the P1–P3–P4 pathway for creating research datasets) require an uncommon level of technical expertise and are difficult to apply for real‐time decision support. ¹¹ , ¹²

The EBMonFHIR project is an HL7 effort to extend FHIR for use for Evidence‐Based Medicine (EBM) knowledge assets, specifically to provide interoperability (standards for data exchange) for those producing, analyzing, synthesizing, disseminating, and implementing clinical research (evidence) and recommendations for clinical care (clinical practice guidelines). ¹³ , ¹⁴ The EBMonFHIR project resulted in an FHIR EvidenceVariable Resource to describe an element that knowledge (evidence) is about. ¹⁵ Participants in the HL7 Biomedical Research and Regulation Work Group, seeking a method to report structured eligibility criteria for clinical trials in an FHIR Resource, collaborated with the EBMonFHIR project to enhance the FHIR EvidenceVariable Resource StructureDefinition for this use.

Many processes are required for the overall transformation of eligibility criteria into applications for automated patient matching. These processes include the specification of eligibility criteria in discrete, logical forms (E1–E2), specification of discrete logical forms of eligibility criteria in computable structured forms (E2–E3), conversion of computable structured forms into executable logic expressions (E3–E4); similar processes for patient characterization (P1–P2, P2–P3, P3–P4); combining the executable logic expressions to determine a matching result (E4 and P4–EP5); and reporting the matching result in usable forms.

The developments shared here are specific to executable code to support the matching function with executable logic expressions (E4, P4, EP5) using JavaScript instead of CQL or another standard expression language. Additional developments by the EBMonFHIR project may result in more efficient authoring tools to help subject matter experts express structured eligibility criteria and more efficient data transformation tools to convert structured eligibility criteria to CQL.

2. METHODS/TECHNICAL ARCHITECTURE

The model was developed using the FHIR model with the R5 current (continuous integration) build version of FHIR as of August 29, 2022. In this article, FHIR Resources are described with a capital “R” where a Resource describes a data structure for electronic data exchange. Elements contained within a Resource are described with italicized text for the element name.

For initial development, we selected a set of recommendations and research results regarding bariatric surgery. ¹⁶ , ¹⁷ , ¹⁸ , ¹⁹ , ²⁰ We evaluated the eligibility criteria across this set and selected the following characteristics to model for matching against patient characteristics:

• Age

• Body mass index (BMI)

• Presence of conditions, such as diabetes mellitus type 2

• Quantified values of laboratory tests, such as HbA1c

• Race, such as Asian

Age and race data are reported in FHIR using the Patient Resource. ²¹ For age, we selected the birthDate element as the expected means of determination of the patient's age. For race, we selected the US Core Race Extension to be used within the extension element of the Patient Resource. ²² Condition data, such as type 2 diabetes, are reported in FHIR using the Condition Resource with the code element. ²³ The Observation Resource may be used for both BMI and laboratory test values, using the code element to express what is being observed and the valueQuantity or valueRange element to express the observed value. ²⁴

To represent these eligibility criteria in the EvidenceVariable Resource, ¹⁵ we used a definitionByTypeAndValue element for each singular characteristic. For each singular characteristic, we used a definitionByTypeAndValue.type element to define what is being described, using codings for age, race, disease, or the specific measurable concept (such as BMI). To define the acceptable values of the parameter being described, we used either a definitionByTypeAndValue.valueCodeableConcept element if definable with a coding (such as type 2 diabetes mellitus) or a definitionByTypeAndValue.valueQuantity element or definitionByTypeAndValue.valueRange element if definable with quantitative limits (such as BMI). For combinations of characteristics (ie, a characteristic defined as the presence or absence of a defined number of a set of characteristics), we used a definitionByCombination element with the definitionByCombination.code element contained a value that defines the acceptable combination value (specifically “all‐of,” “any‐of,” “at‐least,” or “at‐most”). If using “at‐least” or “at‐most” the definitionByCombination.threshold element was used to complete the expression of the acceptable combination value.

For each characteristic element, including each characteristic contained within a definitionByCombination element, the Logic Processing function determines if the patient data is a “Match,” “No Match,” or “Undetermined.” The function returns the EvidenceVariable Resource using an extension element for each characteristic and for the Resource itself to report the match results.

3. DEPLOYMENT

This is a newly‐released proof‐of‐concept application. Testing has been limited to developers. An Eligibility Criteria Matching Software Demonstration project page, located at https://fevir.net/resources/Project/51402, provides access to the application (with the “Check for Match” button) and allows testing using included or added sets of test data.

To share modular portions of functional code that can be used to reproduce some of the matching functions, we created an Eligibility Criteria Matching Software Library, located at https://fevir.net/resources/Project/110192. A “Check for Match 2” button uses these shareable functions and can be tested on the Eligibility Criteria Matching Software Demonstration project page, or the files can be copied from https://github.com/FEvIRnet/EligibilityCriteriaMatchingSoftware for local installation.

4. DISCUSSION

The primary goal was to develop a software solution that functions as a matchmaker accepting the input of two datasets: (1) one defining eligibility criteria from research studies or guidelines and (2) one defining an individual patient's characteristics. A live deployment of such a system could significantly reduce medical error by bringing clinically relevant evidence to the point of care and delivering it to clinicians and patients in a user‐friendly manner.

The initial matching function demonstration has many limitations; this is to be expected as it is the initial demonstration of a new approach. The initial matching function is limited to checking eligibility criteria (EvidenceVariable.characteristic elements) defined by definitionByTypeAndValue or definitionByCombination elements and does not interpret five other definition methods (definitionReference, definitionCanonical, definitionCodeableConcept, definitionExpression, and definitionId). For criteria defined by definitionByTypeAndValue elements, the function is limited to the interpretation of criteria defined with definitionByTypeAndValue.type.coding elements and within those elements limited to a subset of four coding systems:

1. SNOMED CT http://snomed.info/sct

2. LOINC http://loinc.org

3. FHIR Resource Types http://hl7.org/fhir/valueset-resource-types.html

4. US Core Race OMB Category urn:oid:2.16.840.1.113883.6.238

For criteria defined by definitionByCombination elements, the function is limited to interpretation of criteria defined with definitionByCombination.code elements containing one of four values (“all‐of,” “any‐of,” “at‐least,” or “at‐most”) and is limited to interpretation of criteria defined with definitionByCombination.characteristic elements that are interpretable within these limitations.

The initial matching function does not include interpretation of modifier elements (such as timeFromEvent, definitionByTypeAndValue.method, ordefinitionByTypeAndValue.offset) that will later serve to support more complex structured eligibility criteria.

Current limitations of the model using FHIR EvidenceVariable Resource to provide structured eligibility criteria include the need to match precisely to structured characteristic element expressions in HL7 FHIR format. The software is not artificial intelligence friendly and is limited by guidelines that are not conducive to computer resolution and/or require human judgment. Therefore, many concepts in real‐world eligibility criteria cannot yet be captured in a structured form. These limitations can be mitigated to some degree with the creation of structured terminology for capturing more human expressions in machine‐interpretable form.

To obtain maximum value from the matching function in the earliest stages, recommendations include:

1. Limit structured eligibility criteria to the following types of concepts:

   1. Age based on calculated values derived from the Patient.birthdate value.
   2. Race defined with the US Core Race Extension.
   3. Presence or absence of conditions or diagnoses using SNOMED CT codes.
   4. Quantified, coded, or Boolean values for observations for which the type of observation can be defined using LOINC codes.

2. Do not include timing considerations or other modifiers in the initial stages of development.

To obtain maximum value from the matching function over time, recommendations include:

1. Identify your needs for additional expressivity and functionality.

2. Communicate your needs.

3. Participate in collaborative development to meet those needs.

4. Provide additional technologies, such as artificial intelligence, to collaborative development.

This application has thus far only been tested in a limited setting with a limited topic domain, just enough to develop an initial function. It should be generalizable to other settings including clinical trial recruitment, clinical practice guidelines, clinical quality performance, and clinical decision support and generalizable to other areas of clinical practice beyond bariatric surgery.

This application uses a specific approach to defining eligibility criteria (also called cohort definitions or clinical phenotypes). There are several other methods for sharing clinical phenotypes and phenotyping algorithms, and a recent study concludes with “A standard representation for phenotype definitions should support these formats and be modular to support localization and shared logic.” ²⁵ The EBMonFHIR project and related efforts include an “Eligibility Criteria Working Group” and collaboration across groups representing phenotype definitions could develop such a standard. The inclusion of groups sharing cohort definitions for quality measurement could ultimately result in a common standard representation that could be used for increased efficiency across clinical research, clinical decision support, clinical quality measurement, and prior authorization.

4.1. Technical implementation and test plan

The authors created an Eligibility Criteria Matching Software Demonstration interface at https://fevir.net/51402 to support ease of access for testing the function. This interface is freely available and may be used without login. An Eligibility Criteria Matching Software Library was developed at https://fevir.net/110192 and can be used to find simple matching functions in JavaScript that can be reused in other systems. Developers are welcome to contact the authors if interested in collaborative development and contribution to the Eligibility Criteria Matching Software Library.

Inputs for testing require the selection of one mock patient data instance and one or more sets of eligibility criteria. The tester may select from pre‐loaded test data or enter new data to be tested.

Without logging in, the user may enter a mock patient data Bundle or select from pre‐loaded examples, and may select from pre‐loaded eligibility criteria examples, and then use the function by clicking the “Check for Match” button. If signed in, the user may enter new data for mock patient data Bundle or eligibility criteria EvidenceVariable inputs and save the data to be presented in the selection lists that will be limited to user‐submitted data for the specific user and pre‐loaded examples.

4.2. Technical specification

4.2.1. Input specification: two datasets—Mock patient data and Structured eligibility criteria

1. Mock patient data

   1. The mock patient data must be in the form of an FHIR Bundle Resource JSON that includes one Patient Resource and any number of Condition and Observation Resources.
   2. Specific expectations for the Strike‐A‐Match function:

      1. The Patient Resource and related Resources must be delivered as a single Bundle Resource. The resourceType element must have a value of “Bundle.” The FHIR Bundle Resource is a container for the multiple FHIR resources needed to find the data to determine eligibility.
      2. The FHIR Bundle Resource must have a type element with the value of “collection.”
      3. The FHIR Bundle Resource must contain 1 and only 1 Patient Resource; only one patient will be evaluated to see if they match the eligibility criteria.

         1. The Patient Resource should include the birthDate element reported in ISO format (years, months, day as YYYY‐MM‐DD) which will be used to calculate an age for eligibility purposes.
         2. To report race, the Patient Resource should include an extension for Race using the US Core Race Extension with an extension.url element wtih the value of “http://hl7.org/fhir/us/core/StructureDefinition/us-core-race” which contains an extension with an extension.extension.url element with the value of “ombCategory” and an extension.extension.valueCoding.system element with the value of “urn:oid:2.16.840.1.113883.6.238.”
      4. The Bundle Resource may include any number of Condition Resources.

         1. Each Condition Resource must have a clinicalStatus element. This element must include a code (in the clinicalStatus.coding.code element) with a value in the required Condition Clinical Status Codes value set (active, recurrence, relapse, inactive, remission, or resolved).
         2. The condition definition itself is expressed in the code element using the code.coding.code element.
      5. The Bundle Resource may include any number of Observation resources.

         1. The Observation Resource is required to have a status element. This element must include a code (in the status.coding.code element) with a value in the required ObservationStatus value set (registered, preliminary, final, amended, corrected, canceled, entered‐in‐error, or unknown).
         2. The Observation Resource is required to have a code element, using the code.coding.system element and the code.coding.code element, to define the type of observation, typically with a LOINC code.
         3. For the matching function the Observation Resource needs to have one and only one of the following elements: valueBoolean, valueCodeableConcept, valueQuantity, or valueRange.
2. Structured eligibility criteria

   1. The structured eligibility criteria must be in the form of an FHIR EvidenceVariable Resource JSON that includes at least one characteristic element.
   2. Specific expectations for the Strike‐A‐Match function:

      1. The EvidenceVariable Resource must have a resourceType element which must have a value of “EvidenceVariable.”
      2. The EvidenceVariable Resource must have a status element which must have a value in the required PublicationStatus value set (draft, active, retried, unknown).
      3. The EvidenceVariable Resource must have a characteristic element that must contain an array of one or more characteristic instances.
      4. Each characteristic instance must have no more than one of the following elements: definitionReference, definitionCanonical, definitionCodeableConcept, definitionExpression, definitionId, definitionByTypeAndValue, and definitionByCombination.
      5. Only characteristic.definitionByTypeAndValue and characteristic.definitionByCombination elements will be interpreted by the Strike‐A‐Match function.
      6. Criteria expressed with a definitionByTypeAndValue element must:

         1. Include a definitionByTypeAndValue.type element with values contained in definitionByTypeAndValue.type.coding.system anddefinitionByTypeAndValue.type.coding.code elements.
         2. Include one and only one value element using valueCodeableConcept, valueBoolean, valueQuantity, or valueRange. Other value types (valueReference and valueId) are not interpreted by the Strike‐A‐Match function.
   3. Additional expectations for the “Check for Match 2” functions used with the Eligibility Criteria Software Matching Library:

      1. Each EvidenceVariable.characteristic element that is to be checked must have a definitionExpression element which contains two elements:

         1. A name element that contains a string exactly matching the function name which will be the file name without an extension.
         2. A language element that will contain “text/javascript.”
      2. There needs to be a corresponding JavaScript file with .js file extension located in the EligibilityCriteriaMatchingSoftware folder associated with the Eligibility Criteria Software Matching Library (or in a suitable location if locally deployed).
3. Code Systems Used by the Strike‐A‐Match function

   1. SNOMED CT http://snomed.info/sct
   2. LOINC http://loinc.org
   3. Units of Measure http://unitsofmeasure.org
   4. FHIR Resource Types http://hl7.org/fhir/valueset-resource-types.html
   5. US Core Race OMB Category urn:oid:2.16.840.1.113883.6.238

4.2.2. Output specification

The function itself produces an output in the form of an EvidenceVariable Resource instance which is derived from the input EvidenceVariable Resource and modified with the addition of extensions. The extensions are applied at the Resource level and in each characteristic element that was evaluated with the function. The extension.url element is “http://www.eunochains.com/fhir/Extension/68e980d41a3effd2ac65d1c39d4617948213220f6886de7d5bbd2e3c5e4063fd” and the extension.valueCoding.coding.system element will have a value of “http://www.eunochains.com/fhir/CodeSystem/714a86033e892a0c5406cfb5fd2d265fd708b200d22845cbf54844f9ee3ae992” and the extension.valueCoding.coding.code element will have a value representing the match result (eg, Match, NoMatch, or Undetermined) and other data such as the level of item checked (eg, characteristic or eligibility criteria).

When using the Eligibility Criteria Matching Software Demonstration interface at https://fevir.net/51402 the output will be provided as a human‐readable report in a modal view.

When using the “Check for Match 2” demonstration, the output is a JSON object with two keys. The result key will contain a value of either “MATCH,” “NO match,” “Undetermined,” or “OOPS! Something went wrong.” The details key will contain an array of results (for individual criteria) defined by the named functions which are called.

The Eligibility Criteria Matching Software Library includes six software scripts, ²⁶ , ²⁷ , ²⁸ , ²⁹ , ³⁰ , ³¹ three pre‐made example input files for mock patient Bundle Resources, and two pre‐made example input files for eligibility criteria in EvidenceVariable Resources. The expected outputs when using these example input files are:

For input with “Example 1 – BMI 39.2 Asian” and “StudyEligibilityCriteria: Obese patients ≥ 18 years old”, the expected output is:

• result: “MATCH”

• details: “MATCH – check if current age ≥ 18 years”, “MATCH – check if BMI ≥ 30 kg/m²”

For input with “Example 1 – BMI 39.2 Asian” and “StudyEligibilityCriteria: Eligibility Criteria for DIBASY Trial”, the expected output is:

• result: “MATCH”

• details: “MATCH – check if history of type 2 diabetes”, “MATCH – check if current age 30‐60 years”, “MATCH – check if BMI ≥ 35 kg/m²”

For input with “Example 4 – BMI 34.3 with diabetes” and “StudyEligibilityCriteria: Obese patients ≥ 18 years old”, the expected output is:

• result: “MATCH”

• details: “MATCH – check if current age ≥ 18 years”, “MATCH – check if BMI ≥ 30 kg/m²”

For input with “Example 4 – BMI 34.3 with diabetes” and “StudyEligibilityCriteria: Eligibility Criteria for DIBASY Trial,” the expected output is:

• result: “NO match”

• details: “MATCH – check if history of type 2 diabetes,” “MATCH – check if current age 30‐60 years,” “NO match – check if BMI ≥ 35 kg/m²”

For input with “Example 5 – BMI units not using UCUM standard” and “StudyEligibilityCriteria: Obese patients ≥ 18 years old,” the expected output is:

• result: “Undetermined”

• details: “MATCH – check if current age ≥ 18 years,” “Undetermined – check if BMI ≥ 30 kg/m²”

For input with “Example 5 – BMI units not using UCUM standard” and “StudyEligibilityCriteria: Eligibility Criteria for DIBASY Trial,” the expected output is:

• result: “Undetermined”

• details: “MATCH – check if history of type 2 diabetes,” “MATCH – check if current age 30‐60 years,” “Undetermined – check if BMI ≥ 35 kg/m²”

4.2.3. Source code and information to run it

The Strike‐A‐Match function is encoded as a JavaScript file. The source code is not openly available due to the inclusion of proprietary content of EunoChains, Inc. The source code was minimally modified for integration with the Fast Evidence Interoperability Resources (FEvIR) Platform. To run the source code, the authors created an Eligibility Criteria Matching Software Demonstration interface at https://fevir.net/51402. This interface is freely available and may be used without login. Without logging in, the user may enter a mock patient data Bundle or select from pre‐loaded examples, and may select from pre‐loaded eligibility criteria examples, and then use the function by clicking the “Check for Match” button. If signed in, the user may enter new data for mock patient data Bundle or eligibility criteria EvidenceVariable inputs and save the data to be presented in the selection lists that will be limited to user‐submitted data for the specific user and pre‐loaded examples. Developers of software to match FHIR‐based eligibility criteria with FHIR‐based patient data may contact the authors to include their software in the Eligibility Criteria Matching Software Demonstration interface.

To use the shareable matching functions, the source code in JavaScript is available through the Eligibility Criteria Matching Software Library at https://fevir.net/110192 (which may grow as others participate) or in an associated GitHub repository at https://github.com/FEvIRnet/EligibilityCriteriaMatchingSoftware.

4.2.4. License

The original matching software itself is licensed by EunoChains, Inc. to Computable Publishing LLC for demonstration purposes and is not available for derivative works without direct communication with EunoChains, Inc. The intellectual property agreement allowing testers and readers to access and run the matching software is provided on the FEvIR Platform by reference to the Acceptable Use Policy at https://fevir.net/termsofuse.

The shareable matching functions are created directly by Computable Publishing LLC and available with an Attribution‐NonCommercial‐ShareAlike 4.0 International (CC BY‐NC‐SA 4.0) license (https://creativecommons.org/licenses/by-nc-sa/4.0/).

CONFLICT OF INTEREST STATEMENT

Brian S. Alper owns Computable Publishing LLC. Khalid Shahin and Joanne Dehnbostel are employed by Computable Publishing LLC. Neeraj Ojha is the Co‐Founder and Chief Technology Officer of EunoChains, Inc. Gopal Khanna and Christopher Tignanelli have no conflicts to disclose.

Alper BS, Dehnbostel J, Shahin K, Ojha N, Khanna G, Tignanelli CJ. Striking a match between FHIR‐based patient data and FHIR‐based eligibility criteria. Learn Health Sys. 2023;7(4):e10368. doi: 10.1002/lrh2.10368