CG WG Call Notes leading to 2015 January WGM

Proposed Agenda

• Discuss a revision to the Clinical Genomics Statement Domain Information Model

Attendees

• Amnon Shabo (Shvo), Lam Siew, Jonathan Holt, Grant Wood, Jeffery Karp

Draft Minutes

• Develop the association class between the GeneticObservation and Phenotype that was labeled as 'future work'.
• Possible attributes:
  • The type of the association, e.g., causality (pathogenic or benign)
  • The status attribute of the Phenotype class is suggested to be part of the association class

Proposed Agenda

• Miscellaneous

Attendees

• Amnon Shabo (Shvo), Mollie Ullman-Cullere, Larry Babb, Lam Siew, Jonathan Holt (Vanderbilt)

Draft Minutes

• Briefed on the workshop in Mayo
• Decided to approach Domain Experts Steering Division to either have a new PSS for the consolidated CG DAM project or revise project 705 - HL7 CG-omics Domain Analysis Model
• Decided to start the consolidation of the Clinical Sequencing DAM and the CG DIM document towards balloting them, hopefully starting in January 2015
• The CG DIM will remain quite generic, but the use of it will be illustrated by placing data on its objects/attributes from examples described in the various use cases of the DAM

Proposed Agenda

• Consolidate the CG DIM and Clinical Sequencing DAM into a single CG DAM
  • Best is to refocus our frozen project no. 705 "HL7 CG-omics Domain Analysis Model" to be CG DAM or deprecate the three DIM/DAM projects and start a new DAM project
• IOM data mapping
  • Grant's proposal: "The record stored in the EHR should not be test-based, especially for large gene panels and whole exome/genome testing. Rather, it should be based on specific disease and medication assessment"; Scott's addition: "what about age based panels?"
    • Amnon: should keep data aligned with the 'clinical genomics statement' (CGS) structure that include all the above components and dictate certain starting point; then, in human readable reports or in a summary layer of the EHR, it should be possible to analyse CGS instances relating to an individual, and show significance to a certain disease, medication, care goal/plan, etc.
  • Larry's response: "first represent the list of data elements in an object model form so that we all can see the relationships, cardinality, constraints and other hidden qualities that are not evident in the list form"; "It would also require us to agree on precise definitions of the data elements and the context in which they are intended to be used"
    • Amnon: I believe that the "object model" Larry is proposing to develop is the Clinical Genomics DIM (standards-independent)
  • Grant: " The IOM would like to have an agreement by the Action Collaborative members on a solution by December, so that a pilot can be planned. All they want from us is to demonstrate by December that HL7 can provide the final standard. So a DSTU for the pilot is all we need."
    • Amnon: We could upgrade one or more of our specifications to be aligned with the CG DIM and advance them to DSTU (if not already in this status)

Attendees

• Amnon Shabo (Shvo), Mollie Ullman-Cullere, Larry Babb, Perry Mar, Jonathan Holt (Vanderbilt)

Draft Minutes

• Amnon reviewed his comments above
• Larry emphasized that the IOM initiative has a narrower scope than HL7 Clinical Genomics, and it is driven by a number of use cases such as pharmacogenomics
  • The IOM would like to move relatively fast in terms of being able to suggest standard specifications to be used in EHR systems coping with the selected use cases
• Mollie thought we should build on previous efforts
• Larry argued that simply expanding existing specs like the v2 messages might not work well
• Amnon suggested we finalized the CG DIM and then work with our various teams to try to align the HL7 specs they develop with that DIM and present whatever become available to IOM
• Discussed the role of standard specs, for interoperability, persistence, conceptual modeling, etc.
• Perry added (through email) the following clarifications on the principles of modeling:
  • A conceptual model can be geared for application to various types of targets depending on the objective.
  • One possible type of target would be a database, which would determine how the information would actually be stored in an information system. In that case, your conceptual model (conceptual schema) would be designed for that purpose, with a consideration of what you want to have stored in your database.
  • There are other possible types of targets, though, for example a message design, which doesn't speak to how you will store any of the data in your database; this is similar to what HL7 does with using DIM/R-MIM/HMD/XML Schema for a message design process.
  • You don’t even have to gear the conceptual schema for any further target, for example just a domain analysis model to describe the conceptual structure of the domain of discourse. The objective in terms of what the role of the model is essentially determines how it should be constructed.
  • The three levels of models are a conceptual schema (containing what types of facts you want to track), a logical schema (structured for a given type of target in terms of general data model, e.g. a relational database, an hierarchical database, and object-oriented database, etc.), and a physical schema (structured for a particular implementation target, e.g., Oracle, Microsoft SQL Server, Intersystems Cache, etc.).