OECD Workshop on Pharmacogenetics

Transcription

1 OECD Workshop on Pharmacogenetics CG Development of international data standards to support the acquisition, exchange, submission and archiving of clinical-genomic data Rome, Italy October 17, 2005 Amnon Shabo (Shvo), PhD IBM Research Lab in Haifa EHR IBM Research Lab in Haifa

2 IBM Research Worldwide Estab Employees: 440 Estab Employees: 1750 Estab Employees: 210 Estab Employees: 110 Projects where Haifa HCLS group is involved Estab Estab Employees: 40 Estab Employees: 270 Estab Employees: 80 Employees: 180 2

3 Haifa Research Lab HCLS Focal Areas CGv2 Clinical Genomics Solutions MCM Medical Content Manager John Johnson Management Consol Admin Server HL7 Interface Agent DICOM Interface Agent User specific Interface Agent Sally Johnson Mary Johnson Fred Johnson RMI/IIOP Common phenotype (e.g., asthma) Genealogical/Family Data CM API CM API CM API SME IHII..CGACTGA....CGATTGA.. Genotype data for patient set..cgattga....cgaatga.. Public data sources Interoperable Health Information Infrastructure Targeted at regional and national EHR initiatives In collaboration with Almaden Research Center and HCLS Genes and markers uniquely associated with disease: predisposition and drug targets TSM Tape Tape Tape CM Raid Drive (local cache) CM API Health Standards Practice HL7 / IHE / CEN / DICOM / HIPAA Offering Education & Services My HL7 roles: Co-chair and facilitator of Clinical Genomics SIG Co-editor of CDA Release Two (Clinical document) 3

4 Agenda / Key Points Health Information Standards - should be based on a central Health Reference Information Model (RIM) Clinical Genomics & Clinical Trials Standards - should implement the encapsulate & bubble-up paradigm The Final Frontier: EHR Electronic Health Record - personalized longitudinal and cross-institutional EHR - personal genetic data should be part of the EHR - inter/national Health Information Infrastructure is focused on EHR - the inevitable sustainability model: Independent Health Records Banks 4

5 Types of Health Informatics Standard Artifacts Codes & Identifiers (SNOMED, ICD, LOINC, CPT, GenBank, etc.) Messages (HL7, DICOM, X12) Clinical Documents (HL7-CDA) Records (CEN, ISO, OpenEHR, HL7-Functional Model) Integration profiles (IHE: implement best-practice workflows) Claims (HIPAA / X12, HL7-Attachements) Others: Knowledge Representation (e.g., Clinical Guidelines - GLIF); Context Synchronization (CCOW) 5

6 HL7 The Dominant SDO Focus on the 7 th layer in ISO OSI (Open Systems Interconnection) V2 V3: Quantum Leap V2 allows site-specific impl. A few thousands of members; all major vendors represented; a few major providers; like the shift all from major structured US Gov. to agencies; OO 25 international affiliates; academic groups; professional programming societies (its specs bubble up to ISO) V2 messaging specifications ANSI standards since 1994 ADT, Billing, Observations, Medications, Allergies, Vaccinations, etc V2.XML is under ballot (XML Encoding Rules for V2) V3 specifications Dedicated Data Types (e.g., CD Concept Descriptor w/ qualifiers) Mandatory & Central RIM Reference Information Model New specs: CDA, Public Health Reporting, Clinical Trials, Clin. Genom. 6

7 HL7 s mission is clinical interoperability To provide standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services. Functional interoperability Source: HL7 Mission statement (1997) interoperability : ability of two or more systems or components to exchange information and to use the information that has been exchanged. Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] Semantic interoperability 7

8 To achieve semantic interoperability we need standard specs derived from a Central Health RIM: EHR Clinical Guidelines Pharmacy Clinical Trials Health RIM Clinical Documents? Bioinformatics Data Models Clinical Genomics Orders & Observations Imaging Central Health RIM (e.g., an extended HL7 V3 Reference Information Model): Bio- & medical-informatics standard specs are derived from the same RIM 8

9 HL7 RIM The USAM Model 9

10 Entity Class Code Living Subject Person Organization Material Place... Performer Author Witness Subject Destination... Participation Type Code Observation Procedure Supply Medication Financial... Act ClassCode Entity Role Participation Act classcode : CS code : CV determiner_cd : CS statuscode : CS plays scopes 0..* 1 classcode : CS code : CV effectivetime : IVL<TS> 0..* participates 0..* typecode : CS time : IVL<TS> statuscode : CS in an act 0..* 1 classcode : CS code : CD moddcode : CS statuscode : CS activitytime : GTS 1 1 source target HL7-RIM: Core Classes Role Class Code Patient Provider Employee Specimen Practitioner * 0..* ActRelationship typecode : CS 10

11 CDA Information Model (Release Two ANSI approved in May 2005) Participations IBM Research Lab in Haifa Clinical Document Related Documents Non-XML or Structured Body Assortment of Entries (V3-RIM classes) Observation Linked HL7 Artifacts Medication Procedure Encounter 11 Record Target Custodian Narrative Content Model Nested Sections w/narrative Recursive relation of Entries CDA Header CDA Body CDA Entries Ext. Ref.

12 Human readable machine processable Clinical Document Structured to Narrative Links <text> <caption>complications</caption> <content> <content ID="a1"> Thrombocytes were taken on the second day after transplantation and the count of Thrombocytes was not less than 25k during the transplantation </content> </content> </text> <Observation> <moodcode V="EVN"/> Anchors To be pointed by the clones Optional nesting content tags to nail down specific narrative pieces: <content ID="a2">not less than 25k during</content> <originaltext><reference url="#a1"/></originaltext> <code displayname="thrombocytes" System="SNOMED"/> <value low= 25 lowclosed = true unit= k > <originaltext>not less than 25k</originalText> </value> <effectivetime value="second day post-bmt" /> </Observation> Direct Excerpts From the narrative 12

13 Agenda / Key Points Health Information Standards - should be based on a central Health Reference Information Model (RIM) Clinical Genomics & Clinical Trials Standards - should implement the encapsulate & bubble-up paradigm The Final Frontier: EHR Electronic Health Record - personalized longitudinal and cross-institutional EHR - personal genetic data should be part of the EHR - inter/national Health Information Infrastructure is focused on EHR - the inevitable sustainability model: Independent Health Records Banks 13

14 The HL7 Clinical Genomics SIG Efforts Tissue Typing Genetic Family BRCA Storyboard Profile History Storyboard CG requirements CG requirements Genotype Shared Model CG requirements CG requirements Cystic Fibrosis Storyboard? Clinical Statement Shared Model Pharmacogenomics Storyboard 14

15 HL7 Clinical Genomics Specs (DSTU) DSTU = Draft Standard for Trial Use (collaborations with early adopters) The Genotype / Genetic Profile Modela Encapsulate & Bubble-Up paradigm Bridging HL7 and bio-informatics markups Family History Standardization of Patient s Pedigree for risk assessment of cancer patient 15

16 The Genotype Model - Focal Areas: IBM Research Lab in Haifa Expression Data The Genotype and its Alleles Sequence and Proteomics Sequence Variations Clinical Phenotypes 16

17 Coexistence of HL7 schemas and Bioinformatics Markup: Enabling the Encapsulate & Bubble-up paradigm Genomic Data Sources Bridging is the challenge Clinical Practice Encapsulation by predefined constrained genomic schemas HL7 CG Messages with mainly Encapsulating HL7 Objects Knowledge (KBs, Ontologies, registries, Evidence-Based, Papers, etc.) EHR System Decision Support Applications HL7 CG Messages with both encapsulating and Specialized HL7 Objects Bubbling up the clinically-significant raw genomic data into specialized HL7 objects and link them with clinical data from the patient EHR Bubbling-up is done continuously by specialized DS applications 17

18 Encapsulate & bubble-up (cont.) DNA Lab Genetic Counseling HL7 CG Messages with an AlleleSequence HL7 Object encapsulating the raw sequencing results Encapsulation by static predefined BSML schema Sequencing Example Decision Support Applications EHR System HL7 CG Messages with both encapsulating and Specialized HL7 Objects Bubbling-up is done dynamically by specialized applications, e.g., GMS (sequence analyzing program) 18 Bubbling up the clinically-significant SNP data into HL7 SNP and Mutation objects and link them with clinical data from the patient EHR

19 The Genotype Model Encapsulating Obj. Genotype Expression Note: HL7 Clinical Genomics SIG Note: All derivation associations represent the process of bubbling up the clinicallysignificant portions of the the raw genomic data embedded in the encapsulating (POCG_RM000024) Use this association when the Document: Genotype Local CMET Description expression data set is not at the Subject:Genomic Data Rev: POCG_RM Date: September 9, 2005 allelic level and is the classes (i.e., Sequence and ExpressionProfile) into the HL7 specialized classes component3 0..* expression translational result Determinant Bio of both alleles. (e.g., SequenceVariation or DeterminantPeptide). Facilitator: Amnon Shabo (Shvo), IBM Research in Haifa, typecode*: <= COMP In this case, populate the Bubbled-up Obj. Individual Genotype value attribute with the reference Sequence 0..1 scopedrolename 0..1 patient gene code, while the Genotype ClinicalPhenotype 0..* CMET: (PAT) ExpressionProperty subject typecode*: <= REFR code attribute should be set to performer R_Patient typecode*: <= SBJ NON_ALLELIC. classcode*: <= OBS [clinical] Allele GenotypeLocus Polypeptide contextcontrolcode: CS CNE [0..1] <= OP Note: moodcode*: <= EVN (COCT_MT050004) classcode*: <= OBS pertinentinformation 0..* clinicalphenotype 0..* clinicalphenotype The term Genotype refers to ALL genomic pertinentinformation code: CD CWE [0..1] <= ActCode moodcode*: <= x_actmooddefevnrqoprmsprp aspects of a specific chromosomal locus. typecode*: <= PERT typecode*: <= PERT text: ED [0..1] 0..* id: II [0..1] value: ANY [0..1] performer code: CE CWE [0..1] (e.g., ALLELIC, NON_ALLELIC) 0..* genotypelocus derivation 0..* expressionproperty text: ED [0..1] typecode*: <= DRIV effectivetime: IVL<TS> [0..1] Note: DeterminantPeptide 0..* Note: Haplotype value: CD [0..1] A related gene that is on a classcode*: <= OBS performer The code attribute could hold codes like (Can hold a gene code, when no alleles are associated, different locus, and still moodcode*: <= EVN Polypeptide NORMALIZED_INTENSITY, P_VALUE, etc. i.e., code=non_allelic) has significant interrelation id: II [0..1] classcode*: <= OBS The value attribute is populated based on the selected code methodcode: SET<CE> CWE [0..*] with the source gene (similar text: ED [0..1] moodcode*: <= EVN and its data type is then setup accordingly during instance to the recursive association effectivetime: GTS [0..1] derivation id: II [0..1] creation. Here are a few examples: component1 component2 componentof 0..* haplotype value: CD [0..1] typecode*: <= DRIV text: ED [0..1] 0..* Note: of an IndividualAllele). typecode*: <= COMP typecode*: <= COMP typecode*: <= PERT (peptide code, drawn from reference 0..* determinantpeptide A related allele that is on a effectivetime: GTS [0..1] typecode*: <= COMP 0..* locusassociatedobservation performer If code = NORMALIZED_INTENSITY, then value is different locus, and still databases like value: CD [0..1] of type PQ and holds Expression the actual numeric value representing the 0..* clinicalphenotype has significant interrelation those used in the Polypeptide class) (protein code, drawn from SwissProt, normalized intensity. LocusAssociatedObservation with the source allele, e.g., methodcode: SET<CE> CWE [0..*] PDB, If howver the code = QUALITATIVE_EXPRESSION, then value is classcode*: <= OBS ClinicalPhenotype multi allelic phenotype or 0..* determinantpeptide PIR, HUPO, etc.) type ST and holds either PRESENT or ABSENCE. moodcode*: <= EVN derivation5 translocated duplicates methodcode: SET<CE> CWE [0..*] id: SET<II> [0..*] 0..* typecode*: <= DRIV derivation3 0..* polypeptide of the gene. Note: The full description of the Attributes allowed vocabularies for codes and its code: CD CWE [0..1] <= ActCode performer This is a computed outcome, i.e., typecode*: <= DRIV respective values could be found in the specification. text: ED [0..1] the lab does not measure the actual effectivetime: GTS [0..1] Note: protein, but secondary processes EXPRESSION DATA value: ANY [0..1] Code: COPY_NUMBER, ZYGOSITY, DOMINANCY, GENE_FAMILY, populate this class with the methodcode: SET<CE> CWE [0..*] Expression 0..* etc. For example, if code = COPY_NUMBER, then the value is of reference translational protein. classcode*: <= OBS 0..* individualallele type INT and is holding the no. of copies of this gene or allele. performer typecode*: <= REFR moodcode*: <= x_actmooddefevnrqoprmsprp performer 0..* 0..* polypeptide SEQUENCES & PROTEOMICS id: II [0..1] IndividualAllele Note: Polypeptide code: CE CWE [1..1] <= ActCode 0..* individualallele component5 classcode*: <= OBS The term 'Individual Allele' doesn't refer necessarily (the standard's code (e.g., MAGE ML identifier) Sequence 0..* expression typecode*: <= COMP SequenceProperty moodcode*: <= x_actmooddefevnrqoprmsprp to a known variant of the gene, rather it refers to the Constraint: AlleleSequence.value text: ED [0..1] component2 id: II [0..1] personalized data regarding the gene that might well 0..* sequence classcode*: <= OBS classcode*: <= OBS Constrained to a restricted effectivetime: GTS [0..1] typecode*: <= COMP text: ED [0..1] contain personal variations w/unknown significance. component4 moodcode*: <= x_actmooddefevnrqoprmsprp BSML content model, moodcode*: <= EVN value: ED [1..1] effectivetime: GTS [0..1] typecode*: <= COMP id: II [0..1] specified in a separate code: CD CWE [0..1] <= ActCode (the actual gene or protein expression levels) value: CD [0..1] (allele code, drawn from HUGO, GenBank, Locus link, Refseq, etc.) code: CD CWE [1..1] (the sequence standard code, e.g. BSML) schema. 0..* text: ED [0..1] methodcode: SET<CE> CWE [0..*] 0..* determinantpeptide methodcode: SET<CE> CWE [0..*] text: ED [0..1] (sequence's annotations) value: ANY [0..1] performer component3 DeterminantPeptide effectivetime: GTS [0..1] pertinentinformation derivation2 typecode*: <= COMP value: ED [1..1] (the actual sequence) typecode*: <= DRIV Constraint: GeneExpression.value typecode*: <= PERT methodcode: SET<CE> CWE [0..*] (the sequencing method) 0..* sequenceproperty Constrained to a restricted 0..* clinicalphenotype MAGE ML or MIAME content component1 component6 pertinentinformation 0..* Note: model, specified in a typecode*: <= COMP typecode*: <= COMP typecode*: <= PERT 0..1 sequence There could be zero to many derivation1 pertinentinformation performer separate schema. ClinicalPhenotype 0..* clinicalphenotype IndividualAllele objects in a typecode*: <= DRIV typecode*: <= PERT derivation4 specific instance. A typical case typecode*: <= DRIV ClinicalPhenotype Note: would be an allele pair, one on the paternal chromosome and Expression class refers one on the maternal chromosome. to both gene and protein 0..1 locusassociatedobservation A third allele could be Note: expression levels. Expression Data Related present if the patient has This recursive association LocusAssociatedObservation three copies of a chromosome as enables the association of an 0..* sequencevariation in the Down s Syndrome. RNA sequence derived from More alleles could be present if a DNA sequence and a SequenceVariation Note: 0..* sequencevariation somatic mutations are represented. Note: polypeptide sequence derived Code: CLASSIFICATION, etc. The code attribute indicates in from the RNA sequence. For example, if code = what molecule the variation occurs, SequenceVariation Allele 0..* clinicalphenotype CLASSIFICATION, then the value is of type CV and is holding either i.e., DNA, RNA or Protein. classcode*: <= OBS KNOWN or NOVEL. moodcode*: <= x_actmooddefevnrqoprmsprp ClinicalPhenotype id: II [0..1] code: CD CWE [0..1] <= ActCode text: ED [0..1] 0..* clinicalphenotype effectivetime: GTS [0..1] 0..* assignedentity pertinentinformation ClinicalPhenotype value: ANY [0..1] performer typecode*: <= PERT (The variation itself expressed with markup like BSML or drawn from an external classcode*: <= ORGANIZER typecode*: <= PRF moodcode*: <= EVN 0..1 scopedrolename CMET: (ASSIGNED) R_AssignedEntity [universal] (COCT_MT090000) Note: The code attribute could hold codes like TYPE, POSITION.GENOME, LENGTH, REFERENCE, REGION, etc.. The value attribute is populated based on the selected code and its data type is then setup accordingly during instance creation. Here are a few examples: If code = TYPE, then the value is of type CV and holds one of the following: SNP, INSERTION, DELETION, etc. if code = POSITION, then value is of type INT and holds the actual numeric value representing the variation position along the gene. if code = LENGTH, then value is of type INT and holds the actual numeric value representing the variation length. If code = POSITION.GENE, then value is of type CV and is one of the following codes: INTRON, EXON, UTR, PROMOTER, etc. If code = POSITION.GENOME, then value is of type CV and is one of the following codes: NORMAL_LOCUS, ECTOPIC, TRANSLOCATION, etc. reference like LOINC or dbsnp.) interpretationcode: SET<CE> CWE [0..*] <= ObservationInterpretation methodcode: SET<CE> CWE [0..*] Sequence Variation (SNP, Mutation, derivation typecode*: <= DRIV 19 Polymorphism, etc.) If the code = REFERENCE, then value is type CD and holds the reference gene identifier drawn from a reference database like GenBank. The full description of the allowed vocabularies for codes and its respective values could be found in the specification. SequenceVariationProperty classcode*: <= OBS moodcode*: <= EVN code: CD CWE [0..1] <= ActCode text: ED [0..1] value: ANY [0..1] performer 0..* SEQUENCE VARIATIONS 0..* sequencevariationproperty Variation Attributes Translocation classcode*: <= OBS moodcode*: <= EVN id: SET<II> [0..*] effectivetime: GTS [0..1] value: ED [0..1] definition typecode*: <= INST 0..* TagSNP performer classcode*: <= OBS moodcode*: <= DEF componentof typecode*: <= COMP Haplotype classcode*: <= OBS moodcode*: <= EVN 0..* translocation id: II [0..1] component text: ED [0..1] effectivetime: GTS [0..1] typecode*: <= COMP value: CD [0..1] pertinentinformation typecode*: <= PERT ClinicalPhenotype componentof typecode*: <= COMP 0..1 haplotype 0..1 tagsnp 0..1 haplotype Note: The presence of this class indicates that the source SNP object is a tag SNP (note that it has a DEF mood). Constraint: Haplotype.code Designating maternal or paternal haplotype. 0..* clinicalphenotype Haplotype component1 typecode*: <= COMP ObservedClinicalPhenotype CMET: (ACT) A_SupportingClinicalInformation [universal] (COCT_MT200000) 0..* observedclinicalphenotype Note: A phenotype which has been actually observed in the patient represented internally in this model. SNP Note: This CMET might be replaced with the Clinical Statement Shared Model for richer expressivity, when the that mode is approved (currently in ballot). Haplotype Entry Point: Locus component2 typecode*: <= COMP KnownClinicalPhenotype classcode*: <= OBS moodcode*: <= DEF code: CD CWE [0..1] <= ActCode text: ED [0..1] effectivetime: GTS [0..1] uncertaintycode: CE CNE [0..1] <= ActUncertainty value: ANY [0..1] Note: These phenotypes are not the actual phenotypes for the patient, rather they are the known risks of this mutation. Constraint: ClinicalPhenotype At least one of the target acts of the three component act relationships should be populated, since this is only a wrapper class. 0..* knownclinicalphenotype component3 typecode*: <= COMP 0..* externalobservedclinicalphenotype ExternalObservedClinicalPhenotype classcode*: <= OBS moodcode*: <= EVN id*: II [1..1] (The unique id of an external observation, e.g., residing in a problem list or in the patient's EHR) effectivetime: GTS [0..1] Note: An external observation is a valid Observation instance existing in any other HL7 compliant artifact, e.g., a document or a message. Note: code should indicate the type of source, e.g., OMIM text could contain pieces from research papers value could contain a phenotype code if known (e.g., if it s a disease, then the disease code) Polypeptide Clinical Phenotype Note: Shadowed observations are copies of other observations and thus have all of the original act attributes as well as all outbound associations. They are used for convenience of drawing only.

20 The Genetic Profile Model (since ballot #10) Genetic Profile Genotype or nesting Genetic Profile Observed or known clinical phenotypes 20

21 The Family History Model (initial version) Clinical Data Recursive Relation Patient Relative HL7 Vocabulary= FAMMEMB Genotype CMET 21

22 How the Genotype fits in a F.Hx XML? Taken from a patient pedigree, the portion related to patient s daughter (in collaboration with Partners HealthCare & other HL7 CG SIG members) Bubble up To phenotype and beyond. Point back Need to assure uniqueness across the various type encapsulated data Click here to browse the entire XML 22 Click here for the same sample with sequence data

23 Sequence Sample XML Notes: The use of the BSML 'seqref' attribute is to point to the sequence where this SNP occurs - value is the sequence id value. 23

24 The CDISC Standardization Activities in Clinical Trials Taken from the CDISC Web Site 24

25 The HL7 RCRIM CT Laboratory Model Clinical Trial Non-Genomic results associated with BaseBattery Site Investigator Subject Accession Specimen Associate the Genotype CMET To BaseBattery Or to Accession Protocol 25

26 HL7 RCRIM-Clinical Genomics Joint Effort to address the need for information standards in FDA VGDS The Clinical Genomics SIG develops the Genotype Model The RCRIM TC develops Pharmacogenomics Message based on the CDISC Clinical Trials models The Pharmacogenomics Message utilizes the Genotype Model to convey genetic/genomic data The Pharmacogenomics Message will be proposed as the data standard in the FDA Guidance for VGDS Voluntary Genomic Data Submission The Agency has heard that pharmaceutical sponsors have been reluctant to embark on programs of pharmacogenomic testing during FDA-regulated phases of drug development because of uncertainties in how the data will be used by FDA in the drug application review process. ( 26

27 Agenda / Key Points Health Information Standards - should be based on a central Health Reference Information Model (RIM) Clinical Genomics & Clinical Trials Standards - should implement the encapsulate & bubble-up paradigm The Final Frontier: EHR Electronic Health Record - personalized longitudinal and cross-institutional EHR - personal genetic data should be part of the EHR - inter/national Health Information Infrastructure is focused on EHR - the inevitable sustainability model: Independent Health Records Banks 27

28 EHR Standards ISO assessment Previous attempts to develop a definition for the Electronic Health Record have foundered due to the difficulty of encompassing all of the many and varied facets of the EHR in a single comprehensive definition. 28

29 The HL7 EHR Functional Model DSTU 29

30 EHR Informational Models CEN TC251 EN EHR Model EHR Extract Folder Composition Entry/Item/Cluster 30

31 IHE (Integrating the Healthcare Enterprise) XDS New Profile Leading a document-centric view of EHR! 31

32 What s the Problem? (1) So, we integrated all medical records we even standardized & indexed them (!) and the patient is now requesting care: How does the current healthcare provider make sense out of the pile of medical records and have better medical reasoning? Those medical records could be numerous, using different standards, different codes, different units, could contain contradictory info., etc. Possible solution: A lifetime electronic health record 32

33 Main Features of a Lifetime EHR A persistent entity (not a query result!) Always available to authorized parties Continuously being updated Embeds the standardized medical records (preferably by value) Includes folders of topical & non-redundant information built on data from the standardized medical records & health records Folders are based on data from standardized medical records, captured as transactions into the EHR and extracted as EHR Extracts 33

34 The EHR Conceptual Structure IBM Research is creating infrastructure for these processes. Summative Info (Lists of current diagnoses, medications, sensitivities, etc., & folders of diseases, events, genomics, etc.) evidence evidence Temporal Data (Attested and Standardized Medical Records as well as other sources such as self documentation) evidence evidence evidence E H R Ongoing Extraction, reasoning and summarization 34

35 UK NHS NPfIT Personal Demographics Tracing Service Security Pointers to Patient Information Simplified Conceptual Architecture E- Booking/ E- Booking/ ETP ETP Other National Services Secondary Uses Workflow/ & Rules Transaction Management, Validation and Routing Integration Event Engine Layer Local Applications Core National Services National Services Broker Transaction Transaction and and Messaging Messaging Spine Spine HealthSpace Browser based access Network Non-secure Non-secure Infrastructure domain domain Integration Event Engine Layer Local Applications Personal Spine Information Services The Data Spine Local Domains Patient Centric Systems Other participants NHS local applications 35

36 The USA NHII The NHII 2004 Meeting NOTE: It s based on an index without meta-data, as opposed to the registry model! Taken from Dr. Yasnoff Presentation, NHII

37 The USA NHII The NHII 2004 Meeting Key point: Network of networks not clear how it works and how do we uniquely identify a patient! Taken from Dr. Yasnoff Presentation, NHII

38 What s the Problem? (2) Problem: Who could possibly sustain longitudinal EHRs throughout the lifetime of its subjects?! Argument: No single healthcare provider can or should sustain lifetime EHRs : Involves specialization in archiving IT, not in health Current situation occasionally leads to ethical conflicts Possible solution: Multiple competing Independent Health Records Banks, regulated by new legislation 38

39 Possible Models for EHR Sustainability e.g., UK, Canada, Mexico, e.g., Finland, The Netherlands Government Centric Regional Centric Non-Centric: Independent EHR Banks e.g., USA Provider Centric e.g., Web sites Consumer Centric 39

40 The Conceptual Transition Provider Provider Operational IT Systems Archive- Medical Records Healthcare Consumer Operational IT Systems Operational IT Systems Provider Archive- Medical Records Standard-based Communications Independent Health Records Bank Provider Independent Health Records Bank Provider 40 Operational IT Systems Archive- Medical Records Current constellation New Legislation New constellation Operational IT Systems Standard-based Communications

41 The IHRB Vision The medico-legal copy of a medical record solely resides in an IHRB Healthcare Providers IHRBs are Independent of healthcare providers, insurers and gov. agencies Clinical Data Consumers Current EHR Multiple competing IHRBs, regulated by international law Independent Health Records Banks 41

42 The End Thanks for your attention! Questions? Comments: IBM Research Lab in 42