DOC

2010-01-21 RCRIM WG Minutes Phoenix - HL7 RCRIM Working Group

By June Warren,2014-05-28 14:17
14 views 0
2010-01-21 RCRIM WG Minutes Phoenix - HL7 RCRIM Working Group

    HL7 RCRIM Working Group Meeting Minutes

    January 21, 2010

Thursday Q1 Q4

    Attendees

    First Name Last Name Affiliation E-mail Address Mary Cauley Lilly mkcauley@lilly.com Christel Daniel Cristel.daniel@crc.jussieu.fr Robert Dolin Semantically Yours, BobDolin@gmail.com

    LLC

    Julie Evans CDISC jevans@cdisc.org Myron Finseth Medtronic myron.finseth@medtronic.com William Friggle Sanofi Aventis William.Friggle@sanofi-aventis.com Patricia Garvey FDA patricia.garvey@fda.hhs.gov Scott Getzin Eli Lilly and Company sgetzin@lilly.com Allen Glover Covance allen.glover@covance.gcom William Gregory Pfizer gregow@pfizer.com Joyce Hernandez Merck joyce.hernandez@merck.com Marcelina Hungria Image Solutions, marcelina.hungria@imagesolutions.c

    Inc.(ISI) om

    John Kiser Abbott Laboratories john.kiser@abbott.com Diasuke Koide University of Tokyo koide-tky@umin.net Wayne Kubick Lincoln Technologies wayne.kubick@lincolntechnologies.co

    (CDISC) m

    Pierre-Yves Lastic Sanofi Aventis pierre-yves.lastic@sanofi-aventis.com Mary Lenzen Octagon mlenzen@octagonresearch.com Barrie Nelson Amgen barrien@amgen.com Alejandro Pica European Medicines Alejandro.pica@ema.europa.eu

    Agency

    Mitra Rocca FDA Mitra.Rocca@fda.hhs.gov Jason Rock Global Submit jason.rock@globalsubmit.org Steve Sandberg Mayo ssandberg@mayo.edu

    Clinic/Foundation

    Kris Spahr Merck & Co., Inc. kristofer_spahr@merck.com John Speakman NCI john.speakman@nih.gov Lise Stevens FDA lise.stevens-Hawkins@fda.hhs.gov Jessie Tannenbaum

    Chris Tolk CDISC ctolk@cdisc.org

    Clyde Ulmer FDA

    Gary Walker Quintiles gary.walker@quintiles.com Mead Walker Mead Walker dmead@comcast.net

    Consulting

    Steve Ward Lilly stw@lilly.com

    Taku Watanabe PMDA watanabe-taku@pmda.go.jp Julia Zhang Genzyme Julia.Zhang@genzyme.com I. CDISC Content to Message Work Session Jason Rock

    Jason Rock reviewed high level goals for the FDA’s Janus program, which

    will be supported by the new standard, including an example of a

    Page 1 of 5

    HL7 RCRIM Working Group Meeting Minutes

    January 21, 2010

Napoleon’s March graphic (which doesn’t require the new standard) See

    slides.

    CDISC Message Workshop.ppt

    Pierre-Yves Lastic intervened to present some of the key questions that the workshop is intended to address, so the attendees could better understand the objectives for today’s meeting. (see slides)

    CDISC.ppt

    Jason Rock next presented a high-level overview of messages, which require a trigger event, receiver/sender responsibilities and a transmission wrapper. Documents are human readable, persistent, whole, viewed in a particular context and manageable.

    Question: Do these characteristics of a document apply to a clinical data transfer.

    Response: we shouldn’t get hung up on these definitions, but just accept them.

    Bob Dolin: There are other criteria for a document.

    One approach is to build your own RMIM and ballot that. Then implementers can define a message. If you go the CDA route, there are limits, but can be more easily implemented. You need to decide up front on the best approach for this application:

    Do you need a precise RMIM for implementation or do you want to go with CDA where there is an established base?

    One approach is to define requirements and see whether these are best met by CDA or Message.

    Comment: Could also create a structured document that does not follow CDA.

    Question: How does it affect interoperability when messages like CTRR and CDA docs like Subject data contain the same data.

    Response: It’s not a problem to include, say, lab data in a CDA R3

    document. In theory, it shouldn’t matter.

    Mead Walker: You should see a convergence of CDA and messages within the next 3 years. Recommend the group should implement according to their own familiarity.

    Bob Dolin: A document has no inherent dynamic model, but there is some type of communication vehicle and dynamic framework (it’s external to the document). CDA R2 was built deliberately with a broad model so it could be flexibly used. Orders & Observations is considering whether to take a similar approach with messages. Any additional constraints would be

    Page 2 of 5

    HL7 RCRIM Working Group Meeting Minutes

    January 21, 2010

    expressed as a template. The templates give you fine-grained control. A challenge with CDA R2 doesn’t have all RIM classes (e.g., financial) – so

    you can’t express them. What other classes are missing? And how do

    you deal with dynamic aspects (such as generating data clarification forms)? Need to create a corresponding template (for each possible type of question?). Perhaps RPS addresses the dynamic aspects. QRDA quality reporting document architecture is a new draft standard that (level 2) may be oriented toward sending aggregate data, similar to the clinical research use case when an entire body of data for a study at a time. It all comes down to how well does CDA meet our requirements? Why not documents for all? Slide. Jason Rock proposed reasons why the other models could be messages instead of documents. Again, Bob Dolin said the decision should be based on whether CDA meets requirements or whether we should create our own RMIM.

    Jason Rock reports that the current Subject data version that’s being tested is CDA. Question how can it be in testing if the committee isn’t aware of it. Response all documents are available on the wiki Bob Dolin I thought the current ballot was going to be withdrawn. It hasn’t been published yet, but the plan is to go through all the comments on whether it will be withdrawn.

    Question (Bob Dolin): can you reassure that when it is issued it will follow the current CDA standard? Response (Jason Rock): the committee agreed to postpone a decision until we go through all the comments. It’s essential for RCRIM members to carefully participate in this reballot decision process after they achieve an understanding that CDA does best meet requirements.

    Bob Dolin: While you can make substantive changes under a DSTU, generally this only happens with consensus. Since this ballot seems to have been approved with some misunderstandings, my guess is the TSC would not approve publishing as is. Jason reiterated there has been no request to publish yet.

    Bob Dolin gave a brief sketchpad overview of the model: Document Header, Document Body with nested sections. One key section is the narrative block (text field) where human readable text is placed. This is all you use for simple documents, but sometimes you want to code the text, and this is where the clinical statement model comes in. Clinical statement reflects a big chunk of the TIM. So if narrative makes a diagnosis, you can formally represent the details in the clinical statement. CDA was originally designed to be patient by patient. But can include more than one patient in a document now. A different CDA IG would show how to send the aggregated data.

    <ClinicalDocument>

     <Section>

    Page 3 of 5

    HL7 RCRIM Working Group Meeting Minutes

    January 21, 2010

     <Text> This is the narrative, which is what can be seen in a web

    browser. Possibly could write an XSLT transform to move the coded entries into

    this.

    <Entry> Repeatable encoded elements as observations. All of these are on the right hand side clinical statement portion of the model

    which has observations, procedures, substance administration, supplies, etc. That’s where the actual data will fit.

    CDA presents data in CRF-like format. But the standard does not currently address how a sponsor transforms CRF data to analysis format, and then back to CDA CRF format, so FDA can unfold this in exactly the same way when they receive it. FDA will have their own way of transforming from raw CRF to domain tabulations. But CDA does still include V3 semantics, so interoperability goals will be met. But these are constrained for the templates, and templates don’t exist for everything.

    Lise Stevens: Are we really doing templates at that level of detail? Templates haven’t created for the myriad types of clinical data that we

    collect, and probably never will

    Note: Perhaps this needs to be incorporated into CDISC CSHARE requirements.

    Bill Friggle showed an example of a draft HL7 document annotated with CDISC SDTM variable names. JASON ROCK has been working with Sanofi on testing using sample data from SDTM to be represented as HL7 subject data messages. Caveat: this is very raw, but a place to start the discussion about what it means to go from SDTM to HL7. Question How will controlled terminology be managed?

    Response (Lise Stevens): Look at FDA website for SPL, which is an example of how all of the relevant implementation information will be published. The CDISC message will follow the same process. Note: need to reconcile these linkages with EVS and CSHARE. FDA uses schema trons for validating documents as they come in according to business rules. But these would all have to be defined. CDISC mapping could be included as a comment within a particular block of XML text. But these would be thrown out when loaded into the database. So there are risks that the transformation from raw to SDTM at the sponsor will not match the transformation from HL7 to SDTM at the FDA.

    FDA wants to have others involved in the testing, but sponsors haven’t stepped up. But it seems that the creation of mapping is more than a testing exercise it’s a necessary part of design and development as well.

    We examined examples from Demographics, Lab, vital signs, adverse events, exposure data. Question about datatypes, since SDTM has only 3

    Page 4 of 5

    HL7 RCRIM Working Group Meeting Minutes

    January 21, 2010

    datatypes and HL7 standard will use many more precise types of datatypes. This is another conversion that will need to be handled. Current process of testing has been:

    1. FDA identified 2 sample studies in SDTM format to use for testing

    2. SDTM is loaded into new Janus 2 database (showing SDTM can be

    loaded)

    3. Database extract is created in HL7 subject data standard

    4. Loaded this HL7 into the database to produce SDTM

    5. Then exported from database again and compared with

    consistency with 1

    6. Jason sends sample output from 3 to Sanofi-Aventis to review,

    which generates questions and clarifications.

    FDA has followed a similar process for ICSR testing.

    Comment (Julia Zhang): Since you could map to HL7 from any format, there’s no need to start with SDTM, is there? Does this mean SDTM is

    going away? Answer: There will be many different ways to implement. Bill Friggle: Two main questions: Do we have a place for everything in the SDTM in the HL7 standard?

    Can we do everything that is expected of us by FDA? Is there new information that we currently don’t have access to. What about supplemental qualifiers, the Findings About domain and related records? Perhaps you would eliminate many supplemental qualifiers by using the clinical statement to create separate sub-observations instead. Jason Rock’s “Workflow” slide: The first thing you do is send a study

    design message. This is a process change, and we need to start thinking about process implications to build industry readiness. The next step is participation, but this needs to be harmonized with CTR&R, which contains similar information.

    Scott Getzin “volunteered” to create a storyboard for conducting CTR&R and participation messages.

    Message currently relies on USUBJID to tie a subject to a study. This won’t work when a USUBJID is repeated for a subject enrolled in multiple studies the STUDYID portion won’t correspond to the current STUDY. This will have to be addressed.

    CTLAB is designed for a different use case, with more specific classes than CDA. So it isn’t being used.

    End of Document

    Page 5 of 5

Report this document

For any questions or suggestions please email
cust-service@docsford.com