Clinical Data Normalization / Practical Modeling Issues Representing

Clinical Data Normalization / Practical Modeling Issues Representing

Clinical Data Normalization / Practical Modeling Issues Representing Coded & Structured Patient Data SHARPn Face to Face Meeting June 11, 2012 Stanley M Huff, MD Chief Medical Informatics Officer #1 Acknowledgements

Tom Oniki Joey Coyle Craig Parker Yan Heras Cessily Johnson Roberto Rocha Lee Min Lau Alan James Harold Solbrig Many, many, others #2

Why do we need detailed clinical models? #3 A diagram of a simplified clinical model #4 What if there is no model? Site #1 Dry Weight: 70 kg Site #2 Weight: 70 kg

Dry Wet Ideal #5 Relational database implications Patient Identifier Date and Time Observation Type Observation Value

Units 123456789 7/4/2005 Dry Weight 70 kg 123456789 7/19/2005 Current Weight

73 kg Patient Identifier Date and Time Observation Type Weight type Observation Value

Units 123456789 7/4/2005 Weight Dry 70 kg 123456789

7/19/2005 Weight Current 73 kg How would you calculate the desired weight loss during the hospital stay? #6 More complicated items:

Signs, symptoms Diagnoses Problem list Family History Use of negation No Family Hx of Cancer Description of a heart murmur Description of breath sounds Rales in right and left upper lobes Rales, rhonchi, and egophony in right lower lobe #7

What do we model? All data in the patients EMR, including: Allergies Problem lists Laboratory results Medication and diagnostic orders

Medication administration Physical exam and clinical measurements Signs, symptoms, diagnoses Clinical documents Procedures Family history, medical history and review of symptoms #8 How are the models used in an EMR? Data entry screens, flow sheets, reports, ad hoc queries Basis for application access to clinical data Computer-to-Computer Interfaces Creation of maps from departmental/foreign system models to the standard database model

Core data storage services Validation of data as it is stored in the database Decision logic Basis for referencing data in decision support logic Does NOT dictate physical storage strategy #9 How Would the Models Be Used Globally? They are the pattern for clinical data in many different contexts Messages for electronic data exchange (HL7, Script, DICOM) Models for EMR data Reference for data used in clinical decision support Payload in standard services (patient data access)

Target for structured output of NLP Normalization target for secondary data use Others # 10 Clinical modeling activities

Netherlands/ISO Standard CEN 13606 United Kingdom NHS Singapore Sweden Australia - openEHR Canada US Veterans Administration US Department of Defense Intermountain Healthcare Mayo Clinic HL7 Version 3 RIM, message templates

TermInfo CDA plus Templates Detailed Clinical Models greenCDA Tolven NIH/NCI Common Data Elements, CaBIG CDISC SHARE # 11 Clinical Information Modeling Initiative Mission Improve the interoperability of healthcare information systems

through shared implementable clinical information models. Huff # 12 Clinical Information Modeling Initiative Goals Shared repository of detailed clinical information models Using a single formalism Based on a common set of base data types With formal bindings of the models to standard coded terminologies Repository is open and models are free for use at no cost Huff # 13

Progress on a strategy for open sharing # 14 Access to the models Browser and download site http://intermountainhealthcare.org/CEM/Pages/ LicenseAgreement.aspx # 15 Model Subtypes Created Number of models created - 4384 Laboratory models 2933 Evaluations 210

Measurements 353 Assertions 143 Procedures 87 Qualifiers, Modifiers, and Components Statuses 26 Date/times 27 Others 400+ Panels 79 # 16 Tools - Browser Browsers/Editors Daedalus authoring, real time links to terminology (not finished) Compiler

Syntax check Verification of terminology links (value sets) Outputs Compiled representation for run time use Multiple outputs (future) # 17 The Clinical Element Model # 18 The Logical Structure is Preeminent A formalism is needed to enable discussion of modeling issues. However, the specifics of a given formalism is not the key issue. The logical structure of the data, relationships and

associations between data elements, and binding to standard terminologies are the most important things. What are the issues of style that we can agree on? # 19 Mods and Quals of the Value Choice # 20 Simplifying the Graphical Representation # 21 A Panel containing 2 Observations

# 22 The Use of Qualifiers SystolicBPObs data SystolicBP 138 mmHg quals BodyLocation BodyLocation data Right Arm

PatientPosition PatientPosition data Sitting # 23 The Use of Modifiers (subject) Blood Type BloodTypeObs data O negative

mods Subject Subject data Self (patient) Blood Type BloodTypeObs data O positive mods Subject

Subject data Fetus # 24 The Constraint Definition Language (CDL) CDL is GE and Intermountains context-free grammar for specifying instances of the Abstract Constraint model. CDL is not a schema for dictating the physical structure of data instances. The Core Model (reminder) # 26

Clinical Element Abstract Constraint Model Constrains the Abstract Instance Model to represent the semantics of a particular type of data CDL and CEML are two implementations of the Abstract Constraint Model. Theyre just grammars for saying this Constraint Model e.g., for Heart Rate: Constrain type = Heart Rate Model Constrain key = Heart Rate Constrain data type = Phys. Quantity

Constrain set of valid quals = {body location} Constrain set of valid mods = {subject} The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { key code(HeartRate_KEY_ECID); data PQ; qualifier BodyLocation bodyLocation card(0..1); modifier Subject subject card(0..1); constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); } The Heart Rate Measurement Constraint Model in CDL

model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); data PQ; qualifier BodyLocation bodyLocation card(0..1); modifier Subject subject card(0..1); constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); } The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); constrains key to be Heart Rate Measurement

data PQ; qualifier BodyLocation bodyLocation card(0..1); modifier Subject subject card(0..1); constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); } The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); constrains key to be Heart Rate Measurement data PQ; constrains data to be of type PQ qualifier BodyLocation bodyLocation card(0..1); modifier Subject subject card(0..1);

constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); } The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); constrains key to be Heart Rate Measurement data PQ; constrains data to be of type PQ qualifier BodyLocation bodyLocation card(0..1); constrains valid quals to be {body location}, constrains cardinality to be 0-1 modifier Subject subject card(0..1); constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID);

} The Body Location Constraint Model in CDL model BodyLocation is component { key code(BodyLocation_KEY_ECID); data CD code.card(0..1) code.domain(BodyLocation_VALUESET_ECID); qualifier BodyLaterality bodyLaterality card(0..1); qualifier BodySide bodySide card(0..1); } The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); constrains key to be Heart Rate Measurement

data PQ; constrains data to be of type PQ qualifier BodyLocation bodyLocation card(0..1); constrains valid quals to be {body location}, constrains cardinality to be 0-1 modifier Subject subject card(0..1); constrains valid mods to be {subject}, constrains cardinality to be 0-1 constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); } The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); constrains key to be Heart Rate Measurement data PQ;

constrains data to be of type PQ qualifier BodyLocation bodyLocation card(0..1); constrains valid quals to be {body location}, constrains cardinality to be 0-1 modifier Subject subject card(0..1); constrains valid mods to be {subject}, constrains cardinality to be 0-1 constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); constrains valid values of a heart rate body location } The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); constrains key to be Heart Rate Measurement data PQ;

constrains data to be of type PQ qualifier BodyLocation bodyLocation card(0..1); constrains valid quals to be {body location}, constrains cardinality to be 0-1 modifier Subject subject card(0..1); constrains valid mods to be {subject}, constrains cardinality to be 0-1 constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); constrains valid values of a heart rate body location } The Heart Rate Measurement Constraint Model in CDL model HeartRateMeas { constrains type to be Heart Rate Measurement Model key code(HeartRate_KEY_ECID); constrains key to be Heart Rate Measurement data PQ;

constrains data to be of type PQ qualifier BodyLocation bodyLocation card(0..1); constrains valid quals to be {body location}, constrains cardinality to be 0-1 modifier Subject subject card(0..1); constrains valid mods to be {subject}, constrains cardinality to be 0-1 constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID); constrains valid values of a heart rate body location } Controlled Terminology Codes! Specific Cases in Modeling # 38 Disclaimer: This is our current best

thinking. Some models have not been used in a production system yet. Some models may change when we have more production experience. # 39 Assertion versus Evaluation Styles # 40 Data Entry Styles Hair Color Hair Color Brown Brown

Brown Blonde Blonde Evaluation Styles Red Red Finding Brown hair Brown hair Assertion Style Blonde hair Red hair # 41 Assertion Vs Evaluation Evaluation Style HairColorObs

data Hair Color Brown Assertion Style HairColorObs data Assertion Brown Hair Color # 42 Assertion Vs Evaluation Both evaluation and assertion styles are accurate and

unambiguous Evaluation style is more common as a data entry mode Assertion style allows each assertion to become a present/absent column for statistical analysis Evaluation style is our preferred storage form when the value represents an attribute of the patient Storage of assertion style instances is best for reasons, complications, final diagnoses, etc. Conclusion: You need to support both styles and be able to convert between them # 43 Deprecated representation Single Code Style HairColorObs

Brown Hair Color Only the code (HL7) or key (CEM) has a value It is implied that this means that the patient has brown hair color Implying meaning is usually a bad idea # 44 Subject # 45 Subject Evaluation Style Fetal Blood Type FetalBloodTypeObs

data O negative Blood Type BloodTypeObs data O negative mods Subject Subject data

Fetus # 46 Subject Assertion Style #1 FetalBloodTypeObs data Fetal Blood Type O negative Assertion BloodTypeObs data Assertion

Blood Type O negative mods Subject Subject data Fetus # 47 Subject Assertion Style #2 Assertion BreastCancerInMotherObs data

Breast Cancer in Mother Assertion BreastCancerObs data Breast Cancer mods Subject Subject data Mother

# 48 Subject as a Compound Statement Subject Subject items Relationship data Relationship Maternal Aunt PersonIdentity

Person Identity items PersonName data PersonName Clara Barton # 49 Representation of Family History BreastCancerObs Assertion

Breast Cancer data mods Subject Subject items Relationship data Relationship Family (ancestor) # 50

Pre Vs Post Coordinated Subject Pre coordinated Easier for data entry Can lead to combinatorial explosion Post coordinated Easier to coordinate findings between patient and related party Easier to extend model with additional qualifiers Consistent with family history Allows detail on the identity of the subject

Easier to misuse data (mistake cancer in mother for cancer in patient) Conclusion: Support both pre and post coordinated subject styles , but use post coordinated model for storage # 51 Negation and Uncertainty # 52 Data Entry Styles Medical History Yes No Unk

(handles pertinent negatives) Diabetes Renal Disease Cancer Hx Finding Diabetes Diabetes Renal Disease Cancer (repeating field) # 53 Negation

Diabetes DiabetesObs data Yes (Implicit that this means diabetes is present.) Assertion FindingObs data Diabetes mods NegationIndicator

data Negation Present # 54 Pre Coordinated Negation Assertion FindingObs data No Diabetes (Leads to combinatorial explosion)

# 55 Negation and Uncertainty Assertion FindingObs data Diabetes mods NegationIndicator data Present Uncertainty

Uncertainty data Negation Probable Use of Negation and Certainty are mutually exclusive sets. Negation is only present/absent. All other degrees of probability are represented as values of Certainty. # 56 Combined Negation and Uncertainty Assertion

FindingObs data Diabetes mods CombinedUncertainty data Negation Probably Not Possible values for CombinedUncertainty: Not present, present, maybe, maybe not, probably, probably not, might, might not, likely, unlikely, very unlikely, very likely.

# 57 Conclusions on Negation Picklist style selection of findings does not allow for the representation of pertinent negative findings Pre coordinating negation with findings leads to combinatorial explosion in many situations It is difficult to avoid using pre-coordination for some common phrases, No Salmonella, Shigella, or Campylobacter identified. You can separate pure negation from uncertainty, or combine them into one field. Combining negation and uncertainty into one field will probably prevent entry of some nonsensical expressions. # 58 Done and Not Done

Appendectomy AppendectomyProc data Done (Implicitly this means appendectomy was done.) Procedure Procedure data Appendectomy mods

DoneNotDoneIndicator data DoneNotDone Done # 59 Done and Not Done Recording of whether actions or events occurred or not has a similar structure to negation, but the values are Done and Not Done. Theoretically, it is possible to use both Negation, and Done/Not Done in a single statement. For example: The patient had

abdominal surgery but it was NOT an appendectomy. # 60 History Of # 61 History Of issues A clinician can observe a sign or perform a procedure and record the event in the EHR. The patient or family can report a symptom or procedure occurred. It is essential to distinguish these two cases. When you query for existence of a given disease you want consistency of representation between direct observations

and historical observations. # 62 Consistency of Representation Assertion FindingObs data Vomiting (Observed by a clinician) FindingObs data Assertion History of Vomiting

(Reported by the patients mother) As data ages, the observed information becomes the same as reported information. If you ask the database Did the patient have vomiting?, you want True to be returned in either case. # 63 Attribution Recording the source of information Who, when, where Database add/modify/delete timestamps are handled separately from clinical processes Attributions pertain to actions or events Attributions are represented as a special

class of qualifiers # 64 General model for act attribution State the act (action or event) Observed, reported, ordered, counter signed, transcribed State the attribution information Who Participation (observer, reporter, receiver) Role (mother, physician, nurse, student) When (exact or fuzzy time) Where Geograpical place Network place Could be different for patient than for clinician

Reason for the action Reason for order, reason for cancel, reason for hold # 65 Differences for Observed and Reported Observed Action (Observed) Observer Timestamp Reported Action (Reported)

Reporter Receiver Timestamp Observer, reporter, and receiver could be programs or electronic data stores # 66 Attribution - Observed Action Observed data Observed quals

Participant Participant data Observer quals Role Role data Physician # 67

Attribution - Reported Action Reported Reported data quals ReportTime ReportTimeObs data 11/09/2007 Reporter

Participant items Role Role data Mother Receiver Participant items Role Role data

Clnician # 68 Assertion with Attributions Assertion VomitingObs data Vomiting mods Subject Subject data

Patient quals Observed Reported (As previously defined) # 69 Attributions Attribution information unifies the historical and observational data. Attribution allows status change information to be carried in the instance of data.

Specific models for particular kinds of attributions allows participants, roles, locations, and reasons to be specified. # 70 Pain and Pain Severity # 71 Pain Assertion and Qualifiers Assertion PainObs data Pain

quals Body Location BodyLocation data Abdome n PainQuality data Dull Pain Severity PainSeverity

data Pain Quality Moderate # 72 Pain Scale PainScale PainScaleObs data Mild, 3 # 73

Pain Modeling Issues Pain severity is not usually measured unless there is pain. A pain severity of (None, 0) is the same as no pain. In common practice Pain Severity Scales are thought of as independent observations, not qualifiers of pain. Conclusion: We allow the pain severity scales as independent observations. However, the pain assertion model is more expressive. # 74 Semantic links # 75

How much data in a single record? Chest pain made worse by exercise Two events, but very close association Normally would go into a single finding Ate a meal at a restaurant and 30 minutes later he felt nauseated, and then an hour later he began vomiting blood. Discrete events with known time and potential causal relationships May need to be represented by multiple associated findings Semantic links are used to represent relationships between distinct event instances # 76

Semantic Links (from Roberto Rocha) Diagnostic Procedure Observation In comparison to a PA view is compared to the study of 6.2.92, there previous examination dated has been a slight increase in the degree 10-22-91. of cardiomegaly. Diagnostic Procedure Surgical

Procedure The previously described area of consolidation in the left upper lobe has improved. Observation Post-operative changes consistent with coronary artery bypass. There is persistent bilateral apical pleural thickening and superior paramediastinal streaky opacities. Representation of Semantic Links

InstanceId 1 (123) Nausea Relationship followed-by InstanceId 2 (987) Vomiting Semantic links can also have certainty and attribution Certainty (certain, possible, probable, not likely) Attribution (who or what asserted the relationship, when, and why?) # 78

Questions? # 79 Information Model Ideas V2 | CEM Standard LRA Terminologies V2 XML HTML CEMs V3 XML V3 Next DCMs Repository

Realm Realm of Shared Specific UML Realm Translators Specific Specializations CDA Models in Realm Translators Specific Specializations Realm Translators

Specific openEHR a Single Specializations Templates Specific Specializations Formalism Specializations Archetype openEHR CDA Archetypes OWL CEN LRA SOA

CMETs, HMDs CDISC Archetypes Models RMIMs SHARE CEN Payload Initial Loading of Repository Archetype # 80 Other issues Levels of models boundary between what is in file and what we represent in tables or some other kind of knowledge representation. Models in files to the level of different attributes and then further constraints in tables? Could these models be represented in OWL, DL and other semantic web tools? Examples using coded ordinal data type Yes/no questions are really a different user entry style for assertion

models More examples with Family History Better slides for semantic links Specific examples of Hx of Discussion of other modifiers planned procedures, goals, etc. Examples of Relative Temporal Context Implementation choices in object oriented languages # 81 Other issues Show how the hierarchy of CEMs could produce the Act hierarchy in the HL7 RIM Inheritance of qualifiers and attributions between panels and statements Common qualifiers across models and within the same family of models Status, body location, changes (in vision, appetite, etc.)

Dont want hard hierarchies, but want common query and behaviors across different models Co-occurrence constraints CHOICE in Qualifiers Items that could be numeric or conceptual (frequency of after meals XOR every 4 hours Use of aggregate data # 82 Other issues Storage of data that does not conform to the model Alternative data (data type does not match) Unrecognized qualifier Too many qualifiers - cardinality of qualifier is not

allowed Support for calculated values Relative temporal context Practical compromises Allowing value sets with low, med, high, not assessed # 83 Other Issues Types of collections

Statements Complex statements orders Panels Apgar scores, Treadmill test Folders, sections, and other arbitrary collections (from CEN 13606) # 84

Recently Viewed Presentations

  • Visual Planning Systems STRATEGIC VISIONING What is Strategic

    Visual Planning Systems STRATEGIC VISIONING What is Strategic

    Orientation Services Strategic Visioning Orientation Services Strategic Visioning Workshop Get in-depth experience with the Strategic Visioning process and tools through our public workshop or customized, in-house training. Strategic Visioning Orientation Services Coaching Get help from our network of consultants as...
  • Youth to Adult Transition Program

    Youth to Adult Transition Program

    Youth to Adult Transition Program Facts - Program often referred to as "YTAC" which stands for Youth Transition Assessment Committee (committee established in 1992, prior to the formation of the actual program, to ensure the review and transition of youth...
  • Introduction to Health Policy Jack Needleman, PhD FAAN

    Introduction to Health Policy Jack Needleman, PhD FAAN

    Jack Needleman, PhD FAAN Professor and Chair Department of Health Policy and Management UCLA Fielding School of Public Health Presented at Kaiser Permanente Health Policy Elective
  • Frequency words - Teachit Languages

    Frequency words - Teachit Languages

    Time markers tous les jours = every day beaucoup = a lot souvent = often quelquefois = sometimes de temps en temps = from time to time rarement = rarely
  • SEVEN BASIC QUALITY TOOLS - MM 27 Unsoed

    SEVEN BASIC QUALITY TOOLS - MM 27 Unsoed

    Tambahkan suatu catatan pada histogram tersebut, yang menunjukkan siapa yang mengumpulkan data kapan dan dimana, serta masukkan informasi tambahan apa saja yang diperlukan untuk pengenalan data tersebut. Cantumkan. Diagram Pareto.
  • The 14 Amendment to the U.S. Constitution th

    The 14 Amendment to the U.S. Constitution th

    Arial MS Pゴシック Times New Roman Executive 1_Executive The 14th Amendment to the U.S. Constitution PowerPoint Presentation Slavery in the Constitution Dred Scott case Civil War Amendments Failure of Civil War Amendments 14th Amendment 14th Amendment Do these laws violate...
  • Earthworm Excretory system - WordPress.com

    Earthworm Excretory system - WordPress.com

    New Vocabulary Coelom - Body cavity, space Nephridia - unit of the excretory system in earthworms 'stome' - mouth like opening Earthworm belongs to Phylum Annelida (higher invertebrates) Excretory systems consists of nephridia which are small, coiled tubes along the...
  • Absolute cardiovascular disease risk assessment and early ...

    Absolute cardiovascular disease risk assessment and early ...

    Aim. To demonstrate the clinical application of absolute cardiovascular disease (CVD) risk assessment. The aim of this lecture is to show you how and why absolute cardiovascular disease risk assessment could (and should!) be performed in clinical practice.