+------------------+---------------------------------------------------+
| Date, Time &     | *June 30, 2005* from 12:00 AM to 5:00 PM EST      |
| Location:        |                                                   |
|                  | *PharMA*                                          |
|                  |                                                   |
|                  | *1100 15^th^ Street, NW, 9^th^ Floor*             |
|                  |                                                   |
|                  | *Washington, DC*                                  |
|                  |                                                   |
|                  | 12:00 pm                                          |
+------------------+---------------------------------------------------+

Attendees:

+-----------------------------------+-----------------------------------+
| Sue Dubman (NCICB)                | Gary Secrest (J&J/SAFE)           |
|                                   |                                   |
| Peter Covitz (NCICB),             | Betsy Fallen (Merk)               |
|                                   |                                   |
| Brenda Duggan (NCICB)             | John Speakman (MSKCC)             |
|                                   |                                   |
| Christo Andonyadis (NCICB),       | Bill Rosen (Pfizer)               |
|                                   |                                   |
| Lloyd Johnson (FDA)               | Guy Tallent (SAFE),               |
|                                   |                                   |
| Janet Gentry (FDA -- CDER)        | Smita Hastak (ScenPro)            |
|                                   |                                   |
| Bobbie Witczak (FDA -- CDER)      | R. Mark Adams (Booz Allen),       |
|                                   |                                   |
| Randy Levin (FDA),                | Zahid Rathore (Booz Allen),       |
|                                   |                                   |
| Bill Barrick (NIAID),             | Kevin Vigilante (Booz Allen),     |
|                                   |                                   |
| Julie Evans (CDISC),              | Greg Broland (Booz Allen)         |
|                                   |                                   |
| Kamal Narang (CTIS)               | Anthony Hess (IBM)                |
|                                   |                                   |
| Kim Johnson (Duke)                | Joel Dubbels (IBM)                |
|                                   |                                   |
| Norman Goldbarb (First Clinical   | Kathy Martin (IBM)                |
| Research)                         |                                   |
|                                   | Elise Blaese (IBM)                |
| Christina DeFlippo (J&J)          |                                   |
|                                   | Chuck Jaffe (SAIC)                |
| Edmond Versroete (J&J Centocor)   |                                   |
+-----------------------------------+-----------------------------------+

Meeting Materials Distributed:

+-----------------------------------------------------------------------+
| -   CRIX Presentation (June 30^th^)                                   |
|                                                                       |
| -   *Janus Overview Presentation (June 30^th^)*                       |
|                                                                       |
| -   *Business Modeling Subcommittee Update*                           |
|                                                                       |
| -   *Strategic Planning Subcommittee Update*                          |
|                                                                       |
| -   *Janus Requirements Workshop Agenda*                              |
+-----------------------------------------------------------------------+

Sue Dubman provided introductions for the participants. Sue reiterated
the importance of attending these face to face meetings and reminded the
participants that if they are unable to attend then they should send a
designated replacement. In an effort to maintain high participation in
the meetings, NCICB will try to schedule the CRIX meetings around other
known meetings for the group. Participants were asked which locations
would be preferable for having future face to face meetings. Chicago and
New York City were two suggestions. Another suggestion was to leverage
one of the upcoming caBIG™ meetings to accommodate participant's
schedule and reduce related travel. A key consideration to planning
future meetings is FDA participation. It may be difficult for FDA to
participate in person if the meetings are not held in the Washington, DC
area.

The agenda for this meeting included:

-   CRIX Subcommittee Updates

-   Introduction of the Janus/CRIX initiative

-   Workshops to collect Janus Requirements.

The discussion, decisions and action items from this meeting are
summarized below.

**[CRIX Subcommittee Update]{.underline}**

Each of the three subcommittees (Business Modeling, Strategic Planning,
and Architecture/Standards) provided an update on activities and
progress since the March kick-off.

***CRIX Business Models Subcommittee Update***

Based on what was discussed at the last executive steering committee
meeting, the subcommittee reported on its progress in the analysis of 5
areas which should provide a perspective on the business model for CRIX.

-   Firebird/SAFE Pilot -- what is it?

-   Stakeholder Analysis -- who benefits from it?

-   Price Model Analysis -- fee for service? Per transaction? Membership
    fee?

-   Vendor Support Analysis -- if we were to set up Firebird as initial
    module of CRIX what vendors would we approach to set up the service
    bureau? How would we work with them to get RFI/P responses?

-   Paying for services -- how do we pay for services? What are the
    issues (for and against) for people participating in those
    activities?

*Firebird/SAFE Pilot Feedback*

-   Stakeholder groups vary widely. Participants in the pilot and
    prospective users have different perspectives on the process and the
    use of Firebird/SAFE.

-   Workflow processes for different sponsor organizations. For example,
    it was suggested that the rules around proxy relationships are
    different in each organization. Also, sequencing differences are
    significant. Input by NCI and pharma have provided the basis for a
    flexible Firebird design but there is a need to confirm capabilities
    meet the needs of other NIH institutes.

> ***Action Item**:* Conduct a use case session with other government
> groups and ensure that it is flexible enough for other NIH
> institutions.

-   Constructive feedback from user group indicates that the
    Firebird/SAFE program is viewed in a positive way by the user
    community. Operational challenges identified were in user training,
    installation and credentialing. It was also noted that the latest
    installation of credentials using the USB port is improved and
    installs in just a few minutes. The operational pilot, now underway,
    will identify solutions to the operational challenges.

-   The future direction of IT security means organizations will provide
    credentials and certificates directly from trusted root sources. It
    was the consensus of the group that we be looking at SAFE as one of
    many X509 certificates. This question hits to the heart of why SAFE
    was formed. SAFE wraps additional polices around the basic X509v3
    specification to ensure that credentials issued by DHHS can be used
    with the SAFE community or can bridge to SAFE credentials used by
    industy.

    -   The use of a cross certification bridge will enable
        organizations to trust certificates issued by other
        organizations that issue certificates at the same level of
        assurance.

    -   A key goal of caBIG^TM^ and CRIX is interoperability. Thus,
        there is a requirement to cross certify with SAFE.

    -   Cybertrust, VeriSign, GeoTrust are, (or are becoming)
        SAFE-compliant and will be sources of SAFE compliant
        certificates.

-   Lessons learned from the Technical Pilot:

    -   The Firebird beta implementation was based on smart cards with
        smart card readers. This required additional hardware to be
        installed on the target machine, which left a bit to be desired.
        The new USB fobs are quick and easy to install for machines that
        are not locked down.

    -   Systems at some sites were "locked down" so there was no port to
        install hardware or utilize a USB fob. Firebird workflow will
        need to accommodate signatures via one or more centrally located
        systems that can accept the SAFE hardware.

    -   Macintosh support is needed and is coming soon, according to
        SAFE. Progress will depend on Microsoft Certificate Manager
        (part of OSX). NCICB and SAFE consortium members might need to
        reach out to Apple to get their support.

-   Adoption of Firebird and the investment in certificates and
    associated support will be enhanced as more and more applications
    leverage the certificates.

    -   Connection with Clinical Laboratory Improvement Amendments
        (CLIA) -- lots of information that can be used as a codified
        list of information.

    -   A possible use of Firebird is to "certify" investigators. This
        is a recommendation of the CTWG (Clinical Trials Working Group)
        that was recently approved by NCAB (National Cancer Advisory
        Board).

*Stakeholder Analysis*

-   The intent was to identify what the benefits were for each group
    that will use Firebird in its current form and what value
    incremental changes will provide. Twelve stakeholder groups where
    identified: CCOP, CRO (Contract Research Organization),
    Investigators, NCI, Bio-Pharma, Regulators (FDA, OHRP), SPOREs,
    Cooperative Groups (Holding INDs), Coordinating Centers for a
    multi-site network, Academic Research Centers, Subjects/Patients,
    International Sites, Non-Academic Stakeholders.

-   Identified incentives and disincentives for the use of the system
    (For example, changes may need to be made to work processes that
    could be seen as short term disruptions that would ultimately lead
    to benefits).

-   Developed a consensus view based on the feedback from the individual
    groups.

-   Most, if not all stakeholders saw basic benefits from the core
    Firebird application.

-   Clinical study sponsors, CTEP, NCI, and industry, benefited the most
    from the current form of Firebird.

*Pricing Model Analysis*

-   A key objectives is that cost should be reasonable when spread
    across the community. The group looked at 5 different scenarios that
    varied from basic fee for service to per-transaction model and
    discussed pros and cons of each scenario. The options discussed
    included:

    -   Sponsors pay for the investigators on trials

    -   Discounts for academic institutions

-   The best model at this point in the analysis may be a combination of
    membership and some sort of transactional or fee-for-service pricing
    structure because a membership fee alone does not take into account
    large transactional activity from bigger participants.

-   At some point based on volume, the participants should be able to
    move to reduced or a flat usage fee.

-   Discussion of transactions and associated costs:

    -   What constitutes a transaction? One possibility is that a
        transaction is each time an investigator registers or updates.

    -   A problem with the strictly transaction fee model is that fees
        cannot be accurately predicted and for budget planning users
        would want to know up front how much it will cost to use the
        system.

    -   We might want to consider transaction ranges which could allow
        for effective planning and budgeting.

-   The analysis did not go into specific details of transactions, but
    did ask what stakeholder groups were consumers vs. suppliers of
    information. Consumers were seen as the ones who were deriving the
    most benefit.

-   Next Steps:

```{=html}
<!-- -->
```
-   Need to begin work on third party hosting options, governance models
    and fee structures.

-   Further analysis of the incentives and disincentives for paying for
    the service

-   Need to start planning a transition process for when this system
    goes into production.

***CRIX Strategic Planning Subcommittee Update***

-   The planning subcommittee has not had a face to face meeting yet.
    Scheduling has been difficult; however there was a teleconference
    this week.

-   The Strategic Planning Subcommittee is charged with addressing the
    following four questions:

    -   Does the functionality of the existing Firebird application meet
        the needs of all stakeholders?

    -   What additional features/capabilities are needed to go into
        production?

    -   What operational issues might influence the value and usefulness
        of FIREBIRD?

    -   What are the expectations of the CRIX users regarding the
        management of and costs to use the Firebird system?

    -   What is the value proposition for Firebird?

    -   What additional functionalities are most important to produce a
        minimum suite of CRIX components?

-   Proposed next steop is to interview Firebird stakeholders to:

    -   Identify additional capabilities that are "must haves" for
        Firebird to go into production

    -   Define/assess value propositions for different stakeholders to
        determine best business model for ongoing support and
        enhancement of Firebird as well as willingness to pay

    -   Identify operational issues surrounding Firebird implementation
        and identify potential solutions to issues

-   There was discussion around a proposed 16 week analysis. This was
    considered too long and the Planning Subcommittee will be coming up
    with a faster process for obtaining the above information.

-   This will be an iterative process: develop capabilities, see how
    well they work and make appropriate changes as needed. Large-scale
    considerations are critical as is the continual and agile
    development methodology. The group also discussed the need to
    combine analysis with incremental development to leverage
    information from beta test cycles.

-   It was noted that it is better to deliver a solution, with a
    flexible architecture, that may need changes, than to spend a lot of
    time developing a monolithic, highly planned and brittle system,
    which would need costly modifications.

-   Work has been conducted with CRIX planning members, as well as the
    operations research office at NCI, where they can conduct user
    assessments (including usability testing).

-   Next Steps:

    -   The planning group will work closely with business processing
        subcommittee to ensure existing data collection on user needs is
        leveraged and that focus is on the minimum set of requirements
        to get Firebird into production.

    -   Need to identify other groups to help with testing the
        capabilities and providing feedback on Firebird usability.
        Perhaps include oncology cooperative groups, additional academic
        institutions, additional industry sponsors, other NIH
        institutions to get feedback to determine if we are on the right
        track. This feedback is necessary to determine if what is being
        built can be put into production.

***Standards/ Architecture Subcommittee Update***

-   Reviewed Firebird, caCORE, common security model (CSM), Janus and
    other technologies.

-   The technical subcommittee has been limiting its activities since it
    is dependent on the other groups to develop business plans and
    requirements that would underlie the standards.

    -   NCI and FDA, under the auspices of the Inter-Agency Operational
        Task Force (IOTF), are piloting a Clinical Data Repository (CDR)
        based on the Janus/CDISC model.

-   There was additional discussion regarding security requirements, who
    would enter data in to CRIX and who would view it.

**[Janus/CRIX Overview]{.underline}**

-   There are four development projects under CRIX today:

    -   Firebird

    -   Safe

    -   CRIX CDR (Clinical Data Repository)

    -   Electronic IND submissions

> These were identified as part of the IOTF with FDA

-   

-   NCI has partnered with IBM and CTIS for the CRIX CDR/Janus pilot.
    Sue Dubman and the IBM team presented a briefing overview of the
    Janus/CRIX CDR initiative.

    -   The intent is to have a single, standards-based single reporting
        mechanism at NCI. This was a recommendation of the CTWG and
        approved by NCAB.

    -   The intent is also to have a standards-based data import
        facility for CRIX/Janus. The CDISC ODM and SDTM define.xml will
        be implemented for the pilot.

    -   Tools for review and analysis will also be evaluated as part of
        the pilot.

    -   The pilot implementation is to be based on the Janus data model
        defined under a CRADA between the FDA and IBM. In addition, the
        pilot will identify gaps between current NCI reporting systems
        (namely, CDUS and Theradex/CTMS) and the Janus model.

    -   The data access layer will be based on a reference
        implementation of the CDISC/HL7 BRIDG model in NCI's caBIO. Only
        the portion of the data access layer that is needed to
        demonstrate several use cases will be implemented.

-   The plan is leverage tools and capabilities from NCI and caBIG^TM^,
    whereever possible.

-   Time frame for the pilot implementation is approximately 5 months.

-   IBM will not implement a full 21 CFR Part 11 compliant system for
    the Janus/CRIX CDR pilot.

```{=html}
<!-- -->
```
-   Key concerns or issues identified include:

    -   How will BRIDG timelines impact Janus/CRIX CDR pilot? caBIO
        clinical trials work builds off of the BRIDG model and the IBM
        team will leverage and extend the model.

    -   Adverse event reporting will need to be incorporated into CRIX.
        Where possible, CRIX should leverage work from the CTMS Serious
        Adverse Events SIG and the development by COH.

    -   Where possible, CRIX should leverage secure data exchange
        capabilities developed in the Regulated Information Exchange SIG
        of the caBIG^TM^ Architecture workspace.

    -   Due to IP (intellectual property) and patient privacy
        considerations, special focus and emphasis needs to be on
        security of stored information as well as secure transfer of
        information between sites.

-   Moving forward, the role of the CRIX steering committee on the
    Janus/CRIX initiative is to represent and serve as liaisons to the
    community (industry, academia, other NIH institutes, FDA, etc).
    NCICB's goal is to get input from all stakeholders and move forward
    with an iterative, rapid development process.

**[Janus Workshop]{.underline}**

IBM conducted three concurrent breakout sessions to solicit requirements
for leveraging the Janus data model to support CRIX. The three breakout
sessions were focused on:

-   Business Requirements Issues

-   Design Issues

-   Functional Requirements.

The table below identifies the participants in each of the three
sessions:

+-----------------------+----------------------+----------------------+
| Business Requirements | Anthony Hess (IBM),  | Betsy Fallen (Merck) |
|                       |                      |                      |
|                       | Sue Dubman (NCICB)   | Christina DeFlippo   |
|                       |                      | (J&J)                |
|                       | Randy Levin (FDA)    |                      |
|                       |                      | Zahid Rathore (Booz  |
|                       | Guy Tallent (SAFE)   | Allen)               |
|                       |                      |                      |
|                       | Norman Goldbarb      | Kevin Vigilante      |
|                       | (First Clinical      | (Booz Allen),        |
|                       | Research)            |                      |
|                       |                      | Chuck Jaffe (SAIC)   |
+-----------------------+----------------------+----------------------+
| Design Issues         | Joel Dubbels (IBM)   | Kamal Narang (CTIS)  |
|                       |                      |                      |
|                       | Christo Andonyadis   | Gary Secrest         |
|                       | (NCICB),             | (J&J/SAFE),          |
|                       |                      |                      |
|                       | Peter Covitz         | Smita Hastak         |
|                       | (NCICB),             | (ScenPro),           |
|                       |                      |                      |
|                       | Julie Evans (CDISC), | Edmond Versroete     |
|                       |                      | (J&J Centocor),      |
|                       | Bill Barrick         |                      |
|                       | (NIAID),             | R. Mark Adams (Booz  |
|                       |                      | Allen),              |
+-----------------------+----------------------+----------------------+
| Functional            | Kathy Martin (IBM)   | Bobbie Witczak (FDA  |
| Requirements          |                      | -- CDER)             |
|                       | Elise Blaese (IBM)   |                      |
|                       |                      | Kim Johnson (Duke)   |
|                       | Sue Dubman (NCICB)   |                      |
|                       |                      | John Speakman        |
|                       | Brenda Duggan        | (MSKCC)              |
|                       | (NCICB)              |                      |
|                       |                      | Greg Broland (Booz   |
|                       | Lloyd Johnson (FDA)  | Allen)               |
|                       |                      |                      |
|                       | Janet Gentry (FDA -- | Bill Rosen (Pfizer)  |
|                       | CDER)                |                      |
+-----------------------+----------------------+----------------------+

***Business Issues Breakout Group***

-   Discussed what regulations would apply (HIPAA, GxP, and 21 CFR Part
    11).

```{=html}
<!-- -->
```
-   Janus/CRIX system will need to comply with 21 CFR Part 11,HIPAA
    regulations, new rules regarding export of protocols offshore, and
    other applicable state and federal laws.

> ***Action Item:** More research is needed to provide a complete answer
> as to which regulations (including security) the system and users must
> comply with, and priorities for implementation (i.e., required to go
> into production, could be added in a later release).*
>
> ***Action Item:** Need a privacy expert to help identify which data
> elements are affected by privacy regulations.*

-   If a single field in the matrix (below) fits the criteria, then the
    entire system must be compliant with this requirement (such as
    HIPAA)

    -   Capture level information must be defined in the matrix. Need to
        meet the HIPAA regulations for the collaborative research
        environment.

    -   There are 18 fields of Protected Health Information (PHI) which
        cannot be released under certain HIPAA rules.

> **[Note:]{.underline}** Government not currently bound by HIPAA;
> hospitals and healthcare organizations are bound by HIPAA.

+--------------------------------+---+---+---+---+------+-----------+
|                                | > | > | > | > | >    | > Inv     |
|                                |   |   |   |   | Prot | estigator |
|                                | P | S | U | C | ocol | > related |
|                                | a | p | s | l | >    | > in      |
|                                | t | o | e | i |  and | formation |
|                                | i | n | r | n | > de | > (may    |
|                                | e | s | > | i | sign | > contain |
|                                | n | o |   | c | >    | > uns     |
|                                | t | r | I | a |  inf | tructured |
|                                | > | > | n | l | orma | > data)   |
|                                |   |   | f | > | tion |           |
|                                | I | I | o |   |      |           |
|                                | n | n |   | o |      |           |
|                                | f | f |   | b |      |           |
|                                | o | o |   | s |      |           |
|                                |   |   |   | e |      |           |
|                                |   |   |   | r |      |           |
|                                |   |   |   | v |      |           |
|                                |   |   |   | a |      |           |
|                                |   |   |   | t |      |           |
|                                |   |   |   | i |      |           |
|                                |   |   |   | o |      |           |
|                                |   |   |   | n |      |           |
|                                |   |   |   | s |      |           |
+--------------------------------+---+---+---+---+------+-----------+
| 21 CFR Part 11                 | X | X | X | X | X    | X         |
+--------------------------------+---+---+---+---+------+-----------+
| HIPAA/Privacy Regulations      | X | X |   |   |      |           |
| (Need to identify scope)       |   |   |   |   |      |           |
+--------------------------------+---+---+---+---+------+-----------+
| Export Laws                    |   |   |   | ? | ?    |           |
+--------------------------------+---+---+---+---+------+-----------+
| GxP Regulations (Need to       |   |   |   | X | X    |           |
| identify scope)                |   |   |   |   |      |           |
+--------------------------------+---+---+---+---+------+-----------+
| General Security               |   |   |   |   |      |           |
+--------------------------------+---+---+---+---+------+-----------+
| Corporate Security             |   |   |   |   |      |           |
+--------------------------------+---+---+---+---+------+-----------+
| Freedom of Information /       |   |   | X | X |      |           |
| Confidentiality                |   |   |   |   |      |           |
+--------------------------------+---+---+---+---+------+-----------+

-   What is the scope that we are looking at?

    -   CRIX/Janus only receives de-identified data. Although individual
        institutions may have a mirror image on-site, it will be their
        responsibility to de-identify data prior to transmission.
        However, even if data is de-identified at the source, HIPAA
        considerations may impact how data can be displayed and to whom.

-   Global solution -- data can come from anywhere, be consumed
    anywhere, and be accessed anywhere

    -   Should assume global data and global users for the mission. What
        is the architecture to support other regulatory agencies in
        other countries?

    -   Global data: Global investigators, Global users, Global patients

-   Collaborative research environment

    -   Trading partner agreements must be in place

    -   CRIX/Janus CDR will be developed to be caBIG^TM^ "silver level"
        compatible so that it can take advantage of new caBIG^TM^
        capabilities as they become available.

```{=html}
<!-- -->
```
-   Discussion on authentication standards that are to be adhered to:

    -   21 CFR part 11 is a mandaory requirement for the production
        system

    -   SAFE, security that is sponsor driven (FDA, NCI), requires
        something you have (such as a SMART card) and something you know
        (such as a PIN) in order to gain access

    ```{=html}
    <!-- -->
    ```
    -   Do we need anything more than 2 factor authentication? No, it
        appears that this is level is the agreed upon comfort level.

```{=html}
<!-- -->
```
-   Need flexibility to be built into the security model. For example

    -   Protocol by protocol basis.

        -   Groups, roles, rights, permissions, audit

        -   Addition, deletion, edits

        -   Who controls the protocol, and under what condition is the
            information released?

    -   Down to field level (extremely simple in concept, but very
        complex in implementation)

    -   Ability to lock out everyone, except certain people within a
        single organization.

-   Access to data -- how is it controlled? What level of access is
    needed?

    -   Whoever owns the IND and/or NDA currently have (and should
        continue to have) the ability to determine level of
        authentication

    -   Access within the organization depends on: organization, role,
        data type by SDTM, domain (use case), Protocol, and data
        lifecycle (before/after submission)

    ```{=html}
    <!-- -->
    ```
    -   Hierarchies of data types are required, even within professional
        categories. (For example, chemists within a pharma firm can not
        see all chemistries -- very closely controlled).

    -   Domain level of security is not enough.

    -   Access must be controlled at least at the row level.

-   Audit trail and journaling. Need to track changes to the system and
    who access the system. Document all signature related items. Track
    queries.

    -   What time stamp will be used? Local time and GMT reference?

    -   Access to system (who, when)

    -   Change (who, what, when, reason, old, new value)

    -   Loading data (who, when, data size, "checksum for file loaded")

    -   Signing of data and signature verification (who, what, when,
        why)

    -   Download/extract (same as loading data)

    -   Access (view, search) to data -- option -- protocol of data
        domain at minimum

-   Next steps: pull a straw man and avoid reinvention of the
    wheel...pick and choose from what already exists.

***Design Issues Breakout Group***

-   The discussion of the design breakout group focused on:

```{=html}
<!-- -->
```
-   caBIG^TM^ Compatibility Guidelines and caBIO

-   BRIDG (Biomedical Research Integrated Domain Model)

-   Clinical Trials Object Model (CTOM).

```{=html}
<!-- -->
```
-   Peter Covitz gave an overview of the caBIG^TM^ compatibility
    guidelines and caBIO. Peter also discussed the \"Regulated
    Information Exchange\" SIG in caBIG^TM^ as an important place to
    have discussions related to the work of CRIX. Warren Kibbe is the
    lead for the Regulated Information Exchange SIG. This SIG could use
    the use-cases and experience gained by the CRIX participants, just
    like the data models from caBIG^TM^ are informing the Janus project.

-   A question was posed about whether or not the development state of
    caCORE toolkits would be an issue when the work on the Janus project
    starts. A significant upgrade to the caCORE toolkit (caCORE SDK
    1.0.3) is planned for release at the end of July. This release will
    correct important defects found in the current version of the
    toolkit.

-   Peter also outlined the process for creating CDEs and getting them
    into the system.

-   BRIDG (Biomedical Research Integrated Domain Model) is an abstract
    data model which will eventually converge with the caBIO-related
    clinical trials data model.

    -   Vision: a shared domain model of regulated clinical research.

    -   Goal: to define a single, common computable protocol
        representation that supports the entire life-cycle of clinical
        trials protocol

    -   Stakeholders: CDISC, HL7, NCICB, FDA, and caBIG.

    -   Key objective: One overarching standard that supports data
        interchange for healthcare information and clinical trials
        research data

        -   Ensure interoperability with the various CDISC standards, as
            well as interoperability between CDSIC and the HL7 Reference
            Information Model (RIM)

    -   BRIDG represents convergence of CDISC and HL7 standards

        -   HL7 is about interchange of messages, while CDISC is about
            standards and domain knowledge.

        -   CDISC data standards are the basis for the BRIDG model
            Implemented in the HL7 RIM for HL7 messaging

        -   All of the requirements of SDTM are being modeled into
            BRIDG, so that BRIDG should not introduce changes to the
            existing SDTM.

```{=html}
<!-- -->
```
-   Discussion on merging caBIG^TM^ and CDISC projects.

    -   caBIG identified best of breed models in the CDISC standards and
        HL7 messages. Joint modeling sessions have been ongoing. 350
        elements between the HL7 and CDISC, now whittled down to
        something agreed upon by HL7, etc.

    -   CDISC DSAM = HL7 DAM = caBIG Structured protocol representation
        (caSPR) = BRIDG

    -   Needs to be drilled down to specific domain classes, and to have
        more dynamic models defined, including activity diagrams and use
        cases. Next task is to make the attribute names to be less
        RIM-like and more domain-related.

-   It was suggested that if Pfizer has come up with standardized
    representation of their statistical analysis- data elements for
    statistical activities that perhaps the representation could be used
    to define a UML representation useful for the Janus implementation.

> Requirements -\> Domain Analysis Model -\> BRIDG (UML Class diagram)
> -\> HL7 Clinical Trials DMIM -\> RMIM & message types

-   CTOM (Clinical Trials Object Model) is a reference implementation of
    the BRIDG model in the \"Execution mode\" (vs. plan mode). BRIDG,
    like RIM, is envisioned to capture what was planned and as well as
    what was executed in the same set of classes; while the CTOM concept
    only handles what was executed -- what data was collected for
    clinical trials -- at this time.

-   Where do we go from here:

-   The clinical trials UML Class Diagram (work-in-progress) slide
    enables us to see how Janus maps to both the requirements (from
    other groups) and the model.

> ***Action Item**: Smita Hastak will supply a spreadsheet with a
> high-level analysis, which can be useful for executing this process.*

-   The requirements and models being developed will feed back to BRIDG,
    while the Janus/CRIX CDR pilot will focus on satisfying the
    requirements from this first set of use cases. Using this approach,
    we will find out how Janus maps to those initial requirements and be
    able to identify where we need to extend the pilot. It also allows
    us to identify where the overlap is with CTOM.

-   We aspire to maintain the caBIO APIs that are being generated by the
    CTOM effort.

-   The caCORE tool kit work is done once and then re-wiring is done
    once...generates one set of APIs.

-   The timeline for completing the Janus model will be established
    after all the requirements are defined and prioritized. It is also
    suggested that the Janus data model be treated as a prototype until
    some data can be loaded into the model, and the model validated.
    Additional mappings to the model should be captured as the next
    phase of the project.

    -   In order to freeze the model in the next 3 weeks, NCI is
        reviewing the model with others, and making sure that the
        skeleton is sufficiently extensible, with other NCICB clinical
        trials projects. NCICB is also looking at the other caBIG^TM^
        Workspaces for data models (e.g., caTIES and caTISSUE) where
        hooks can be identified to their data models. This approach has
        been successful so far and ensures that the separate models are
        interoperable.

    -   Will need to do the Object-Relational (OR) mapping from the CTOM
        to the Janus ERD. This will provide the platform to build the
        interfaces back to caCORE.

        -   JANUS schema / CTOM will be tracked via a tool (e.g., a
            spreadsheet) and used to create a hibernate file for
            implementation.

        -   In order to get the APIs to work, the OR mapping has to be
            in a specific format to ensure that the middleware can talk
            to the database at runtime. Take the spreadsheet (or
            whatever) to create the mapping that the runtime mapping
            requires (e.g., XML file format).

    ```{=html}
    <!-- -->
    ```
    -   IBM would need the generated artifacts from the model (for
        example an implementation of CTOM generated from the caCORE
        SDK),

-   Issues/Concerns that need to be addressed by the design group:

    -   Clinical data warehouses exist at many sites. How do we
        interface with those warehouses?

    -   Many architectural and security issues that need to be
        addressed.

    -   How do we ensure interoperability?

```{=html}
<!-- -->
```
-   Next Steps:

    -   Distribute CTOM slides and mapping spreadsheet to IBM
        development team (Joel)

    -   Generate a hibernate file from CTOM and get that to IBM
        development team.

    -   Compare that hibernate with the spreadsheet

    -   Get the requirements which will describe which objects we need
        to focus on.

    -   Make the changes and test the interfaces.

***Functional Requirements Breakout Group***

-   The objective of this session was to understand workflow/logistics
    and data access requirements. The functional requirements for Janus
    was discussed in terms of role-based users requirements:

    -   Which user roles needed access?

    -   What data is accessed by the user role?

    -   How will the data be used by each user role?

> These role-based user requirements will be used to develop use cases
> for prototyping the Janus/CRIX repository.

-   IBM started the session by discussing the purpose which was to
    gather data usage scenarios that could lead to functional
    requirements from representative end users for the Janus system. The
    initial discussion focused on the question of which points in the
    clinical trial process is the Janus system intended to support.

-   Once data is forwarded to the sponsor and has been through the
    quality assurance process, the site never touches the sponsor data.
    So initially the group felt that the Janus/CRIX initiative offered
    little or no utility to the site that is conducting the trial.
    However, further discussion by the group exposed some possible use
    cases including:

    -   access to data across sites while trials were on-going, for
        example, to identify SAE's or cases where the trial appears to
        be so ineffective it can be discontinued.

    -   query meta data to obtain contact information based on
        information about the trial

    -   investigator access to FDA comments / reviews

-   The group decided that it would be beneficial to include others in
    the exercise and that the best way to accomplish this is to have the
    IBM / NCI team visit several sites.

> ***Action Item**: Arrange site visits, possibly in conjunction with
> already scheduled meetings.*

-   Next Steps:

    -   Identify appropriate resources and conduct workshops to detail
        use cases

    -   Conduct a phone calls to gather initial ideas and thoughts

    -   Conduct additional meetings and have site visits to get the
        information that is needed.

    -   Develop high-level presentation to outline next steps, goals,
        mission, and vision.

**Wrap Up Session**

The wrap up session included readout by each of the breakout group on
accomplishments and next steps. Other discussions focused on how to
better engage industry in the Firebird implementation. The question was
asked: "What is the biggest barrier for industry to implement CRIX?"
Responses revolved around expenses to re-tool databases, migrate data,
etc. This points to the need for CRIX, like caBIG^TM^, to focus on the
interoperability with existing, legacy capabilities.