HCLSIG/cabig

HCLS-caBIG Collaboration Activities

Contents

• Overview
• Status
• Protocol Matching
  • Approach
  • Background
    • caMatch
• Access Control Policy Evaluation
• Resources

Overview

This document describes areas of common interest between the W3C HCLS Clinical Observations Interoperability (COI) group and the U.S. NCI caBIG program. More specifically, these groups are interested in exploring how the previous work of the COI group, and Semantic Web technology in general, can be applied to use cases that are relevant to clinical research and care.

We have identified two general areas of interest:

1. Protocol Matching
2. Access Control Policy Evaluation

Both of these areas relate to activities that are taking place in caBIG in 2010. First, the caEHR activity [1] involves designing and implementing the HL7 Ambulatory Oncology EHR Functional Profile. Part of this functional profile will include supporting matching of participants to protocols - both from the perspective of care providers, clinical researchers, and potential participants themselves. Second, the caBIG infrastructure is being overhauled in order to serve the needs the larger, BIG Health Consortium [2]. A major part of the overhaul involves enhancing the caBIG semantic infrastructure [3], and in particular, there is a desire to utilize Semantic Web technology to support data integration, knowledge representation, and inference [4]. Furthermore, the security infrastructure is being enhanced to support interoperable evaluation of access control policy across organizations, in a way that supports the kinds of scenarios addressed by OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) profiles of SAML and XACML [5].

The following is as high-level set of goals and constraints that could be used as a guide to guide to collaboration activities.

• Protocol Matching (PM)
  • Goal: Make a recommendation for a standard, rule-based representation of eligibility criteria and patient preferences.
  • Constraints:
    • The eligibility criteria representation should
      • PM.C1. facilitate search and comparison of eligibility criteria
      • PM.C2. enable indexing and construction using caBIG Common Data Elements (CDEs)
      • PM.C3. be expressible as RIF rules
      • PM.C4. enable validation through generation of proofs
      • PM.C5. be interoperable with RDF/OWL data
      • PM.C6. enable use of multiple terminologies for eligibility concepts (disease, drugs, etc.)
      • PM.C7. enable use of multiple patient information models (especially BRIDG) including EHR data
      • PM.C8. be sophisticated enough to express eligibility criteria from the test data sets derived from caBIG trial matching applications (caMatch, Love/Avon AOW, caEHR)
      • PM.C9. enable evaluation of criteria in a way that is scaleable enough to be used in a production setting (e.g. as defined by performance requirements for Love/Avon AOW)
      • PM.C10. enable caEHR use cases (as defined in CRFQ SFM)
      • PM.C11. enable similar use cases such as guidance applicability and bio-survellance
  • The patient preference representation should:
    • PM.C12. enable matching and ranking based on factors such as location, treatment, adverse events
• Access Control Policy Evaluation (AC)
  • Goal: Make a recommendation for a standard, rule-based representation of access control policy (security, privacy, consent).
  • Constraints:
    • The policy representation should:
      • AC.C1. be sufficiently expressive to accommodate the kinds of security, privacy, and consent policies that are described in HITSP use cases (e.g. as in TP20 and XSPA XACML and SAML use cases) and IHE profiles (e.g. XDS.b, XCA, BPPC).
      • AC.C2. be expressible as RIF rules
      • AC.C3. enable validation through generation of proofs
      • AC.C4. be interoperable with RDF/OWL data
      • AC.C5. enable use of multiple information models (especially BRIDG) including EHR data.
      • AC.C6. enable use of terminologies that are utilized by HITSP and IHE use cases/profiles (e.g. SNOMED CT, STM E1986, HL7 RBAC Healthcare Permissions Catalog).
      • AC.C6. enable evaluation of policies in a way that is scaleable enough to be used in a production setting.

Status

• 2010-01-25 [Joshua]: I have contacted several groups that are involved in caBIG and protocol matching:
  1. Former caMatch development team and NCI CBIIT systems/QA teams: I'm working with them to find the data set that was initially used to test caMatch. This could be used to generate test data for the rule-based implementation.
  2. The current BreastCancerTrials.org team: They are willing to meet with members of the COI team on Wednesday, Jan. 28th. They might be able provide information their current efforts with the TrialCode application, enhancements to caMatch, and test data sets.
  3. The current Love/Avon AOW team: They are also creating a test data set for the new application. We may be able to use that. I'm trying to set up a meeting.
• 2010-01-26 [Joshua]: At the COI call today, we discussed some potential, concrete next steps:
  • Adapting the COI demo to work with the caMatch test data sets.
  • Using rule-based representations of policies that are described in the HITSP and IHE examples to demonstrate validation and traceability.

Protocol Matching

Approach

• Task 1: Formulate RIF rule representation of eligibility criteria and patient preferences gathered from caMatch, Love/Avon AOW, caEHR (e.g. ASPIRE). These rules should reference CDEs.
• Task 2: Formulate RDF/OWL representations of patient information. Primarily, an OWL representation of BRIDG should be used.
• Task 3: Demonstrate indexing, searching, comparison of eligibility criteria using SPARQL queries and classification of CDEs.
• Task 4: Demonstrate validation of eligibility criteria through proof generation to address common authoring problems.
• Task 5: Demonstrate scaleable evaluation of eligibility criteria by a rules engine (either through native RIF rules, or translation to other expression language).
• Task 6: Demonstrate support for multiple terminologies (SNOMED CT, LOINC, NCIt) and information models (mapping of BRIDG to SDTM, HL7 CDA, etc.).

Background

caMatch

caMatch is the application that powers BreastCancerTrials.org (BCT), which is a patient-centric clinical trial matching application. BCT started out as a prototype created by patient advocates and UCSF. NCICB (now NCI CBIIT) enhanced the application and built out caMatch. The initial pilot phase was limited to trials in the San Francisco Bay Area. The scope has since been expanded to the national scale. It currently contains trials entered by the NCI PDQ staff. The Love/Avon Army of Women (AOW) collaboration with caBIG probably won't use caMatch directly as the matching engine. But many of the requirements are the same. Therefore, the COI group should use caMatch as a reference point and source of test cases. It will also be useful to establish a relationship to the Love/Avon AOW team to evaluate their requirements.

Resources:

• A comprehensive overview of caMatch/BCT can be found here.
• The GForge (software) project for caMatch is here.
• The matching algorithm is implemented by the Java class here.
• The technical guide is here.
• The UML model (in Enterprise Architect format) is here.
• The caMatch code base includes a full eligibility criteria matching test suite. The test cases are documented here.

The Breast Cancer Center of Excellence (http://www.bccoe.org/projects.htm) has created a UI for constructing eligibility criteria. From the web site: “TrialCode - A software application developed by the BCT team to capture complex eligibility rules by linking data elements with Boolean operators. The system renders the rules in a structured format usable by the NCI's caMATCH clinical trials matching system, which greatly facilitates authoring of structure eligibility criteria for the BCT matching system.”

Access Control Policy Evaluation

Patient confidentiality is one of the major concerns for the secondary use of patient clinical information. The very success of a national EMR system would greatly complicate the task of ensuring patient privacy. The sensitivity towards confidentiality and the strategies for managing patient consent vary to a large degree based on a host of factors ranging from usage purposes, care environment to regional and cultural context. The current patient consent management paradigm and systems often fail to distinguish the content of a piece of patient information from the context of pertaining to its access policies. The need for handling the change of this context is left unmet. We herein propose a conceptual and technical framework for managing patient confidentiality and consent based on the emerging Semantic Web technology. This framework enables the explicit annotation of patient information both at the content and context level. Privacy policies and patient consent management strategies can be specified according to the patient's data's content, or its context, or a combination of both. Access to a piece of confidential information is controlled based on independently verifiable facts, proofs and trusts. Furthermore, integrity constraints can be imposed to ensure the consistency and validity of the privacy policies in a distributed and dynamic data sharing environment.

Resources

1. https://wiki.nci.nih.gov/display/EAWiki/Line+of+Business+-+caEHR
2. http://bighealthconsortium.org/
3. https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/SI_Main_Page
4. https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/SI_Conop_Init4_W3C
5. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xspa