HL7 Clinical Genomics – RIM Constraining Issues May 2008

1. HL7 Clinical Genomics –RIM Constraining Issues May 2008 The HL7 Clinical Genomics SIG Amnon Shabo (Shvo), PhD HL7 Clinical Genomics SIG Co-chair and Modeling Facilitator HL7 Structured Documents TC CDA R2 Co-editor CCD Implementation Guide Co-editor

2. To achieve semantic interoperability… …we need standard specs derived from a Central Health RIM: Clinical Guidelines EHR Pharmacy Health RIM Clinical Trials Clinical Documents Encapsulate & bubble-up Clinical Genomics Our solution: Imaging Bioinformatics Data Models Orders & Observations But how do we cope with the challenge of personalized healthcare? Need to bring mass genomic data into healthcare oriented standards!

3. The HL7 v3 DSTU GeneticLocus Model - Focal Areas: Expression Data The Locus and its Alleles Sequence and Proteomics Sequence Variations Clinical Phenotypes

4. The Underlying Paradigm:Encapsulate & Bubble-up Genomic Data Sources Bridging is the challenge… End user Applications for clinical practice & research HL7 CG Messages with encapsulated data associated with HL7 clinical objects (phenotypes) Knowledge (KBs, Ontologies, registries, reference DBs, Papers, etc.) HL7 CG Messages with mainly Encapsulating HL7 Objects Encapsulation by predefined & constrained bioinformatics schemas EHR System Bubbling-up is done continuously by specialized Decision Support applications Decision Support Applications Bubble up the most clinically-significant raw genomic data into specialized HL7 objects and link them with clinical data from the patient EHR

5. The Refinement Process Starts in the RIM Genericontology The core classes: AnEntityplaysaRolewhichParticipatesin anAct So why not a genomic specialization? Where do we draw the line and stop specializing? Observation Act Specialization DiagnosticImage Observation Specialization PublicHealthCase Observation Specialization

6. Refining a RIM Class in a Static Model Examples from the RCRIM CT Lab Model: classCode attr. • This process of refinement is needed in Clinical Genomics • Clinical Genomics brings new & unique concepts into HL7 • Therefore we proposed new RIM classes but got rejected e.g., SequenceVariance with attributes like position, length, etc. • We then developed the GEN code hierarchy instead… OBS OBS OBS Clone B. Name BaseBattery BaseUnitaryResult ToxicityGrade code attr. LOINC code for Test Battery/Panel LOINC code for Test LOINC

7. The GEN Hierarchy (in ActClass vocabulary)

8. The GEN Hierarchy (in ActClass vocabulary) • The GEN code hierarchy was accepted by RIM Harmonization already in July 2006! • It indentifies core classes of the genomic models • Enables further specialization of classes like sequence variationby using the code attribute • It allows CDSS to implement the bubble-up paradigm, • i.e., creating and looking for genotypephenotype associations • We need minor refinements of this hierarchy, e.g.: • Add ALLELE code to the GEN hierarchy • This is also addressing Bob Dolin’s ballot comment about SEQVAR for IndividualAllele wild type which is not an appropriate code • PHN (Phenotype) is a genomic-related observation (edit GEN definition)

9. Special Focus: The Phenotype Class Code • Signifies that an observation is a phenotype • Typically is associated with a source genomic observation • But not necessarily • A genomic observation could be associated with other genomic observations or with other observations not necessarily classified as phenotypes • The IBM Clinical Genomics solution (e.g., the Hypergenes project - http://www.hypergenes.eu/) relies on the GEN hierarchy and performs semantic computation based on those codes • In the decision support API we develop, we use the class codes to understand the type of information • Prepare the ground for a “disease model” expressed in RIM speak so that patient data could be better checked against it

10. General Vocabulary Issues • What are the clear-cut criteria that distinguish between ActClass and ActCode, preferably in a way that a designer of a clinical decision support application could use them programmatically? • ActCode should specialize ActClass but current guidance and the actual values in the two vocabularies sometime blur the differences between the two, e.g.: • _MedicationObservationType act code doesn’t specialize any act class • SpecimenTransportact code doesn’t specialize any act class • If indeed one specializes the other, why not merge them into one coherent vocabulary where sub-typing will become explicit? • The fields classCode, [clone name] and code will bind to the appropriate layer in this proposed consolidated vocabulary

11. What if GEN is Moved to ActCode… • In lack of class code & clone name - need to rely on the code attribute, however… • This poses the following problems: • Code attribute is often drawn from external terminology • Giving up class code & clone name leads to loss of granularity in the data represented by the class • Inferring the generic GEN code from a value in the code attribute might not be easy, especially if drawn from external terminology

12. Clone Business Names DO Carry Semantics • Current guidance: Clone business names should not carry semantics • Rebuttal: These names are meaningful to committee members and are balloted and approved by the HL7 membership • An example – CDA AuthoringDevice vs. Device • The CDA R2 AuthoringDevice and Device clones have the same class code (DEV) and the same binding of the code attribute (EntityCode). • In fact, they have the very same set of attributes refined exactly the same (cardinality, coding strength, vocab, etc). • The only way to distinguish between the two is through the clone name (unless you rely on the traversal path). • The two clones are semantically distinct: AuthoringDevice has to do with the authoring of the document and Device has to do with some specimen mentioned in the body of the document. • In addition, the clone AuthoringDevice does carry semantics which cannot be found in either EntityClass or EntityCode vocabularies. ???

13. Clone Business Names (cont.) • The CDA R2 Encounter and EncompassingEncounter have the same class code (ENC) and the same binding of the code attribute (ActEncounterCode). Semantically they're distinct: the EncompassingEncounter is the encounter documented in the CDA instance and the other clone represents an encounter you may refer to in the body of the document. • A different example of the clone business name semantics is from Patient Administration (Emergency Encounter) model: the clone ValuablesLocation has class code<=OBS, no code attribute and value attribute that is not bound to any vocabulary (it also has mood & negation attributes). Obviously, the semantics carried by ValuablesLocation cannot be found under OBS but also cannot be found in both ActClass and ActCode vocabs. ???

14. Formalize Clone Business Names… • Formalize the clone business name into a vocabulary domain, intertwined in the consolidated ActClass/Code • Adding a definition for each clone name is already done in the walk-through of each model, and possibly in the glossary • In this way, we can relate to clone names as codes in the cascading 'identification' of a class • This could ease the burden of class identification by the class code attribute, if indeed the wish is to keep the ActClass as minimal as possible

15. Thank You for Your Attention… • Questions? • Comments: shabo@il.ibm.com IBM Research Lab in Haifa