1 / 84

SHARPn Face to Face Meeting June 11, 2012 Stanley M Huff, MD Chief Medical Informatics Officer

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. Tom Oniki Joey Coyle Craig Parker Yan Heras Cessily Johnson Roberto Rocha Lee Min Lau

risa
Télécharger la présentation

SHARPn Face to Face Meeting June 11, 2012 Stanley M Huff, MD Chief Medical Informatics Officer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

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

  3. Why do we need detailed clinical models?

  4. A diagram of a simplified clinical model

  5. Dry Wet Ideal What if there is no model? Site #1 70 70 kg Dry Weight: Site #2 70 70 kg Weight:

  6. Patient Identifier Patient Identifier Date and Time Date and Time Observation Type Observation Type Weight type Observation Value Observation Value Units Units 123456789 123456789 7/4/2005 7/4/2005 Weight Dry Weight Dry 70 70 kg kg 123456789 123456789 7/19/2005 7/19/2005 Weight Current Weight Current 73 73 kg kg Relational database implications How would you calculate the desired weight loss during the hospital stay?

  7. 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” More complicated items:

  8. All data in the patient’s 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 What do we model?

  9. 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 How are the models used in an EMR?

  10. 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 How Would the Models Be Used Globally?

  11. 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

  12. Clinical Information Modeling Initiative Mission Improve the interoperability of healthcare information systems through shared implementable clinical information models.

  13. 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

  14. Progress on a strategy for open sharing

  15. Browser and download site http://intermountainhealthcare.org/CEM/Pages/LicenseAgreement.aspx Access to the models

  16. 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 Model Subtypes Created

  17. 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) Tools - Browser

  18. The Clinical Element Model

  19. 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? The Logical Structure is Preeminent

  20. Mods and Quals of the Value Choice

  21. Simplifying the Graphical Representation

  22. A Panel containing 2 Observations

  23. The Use of Qualifiers SystolicBPObs SystolicBP 138 mmHg data quals BodyLocation BodyLocation Right Arm data PatientPosition PatientPosition Sitting data

  24. The Use of Modifiers (subject) Blood Type BloodTypeObs O negative data mods Subject Subject Self (patient) data Blood Type BloodTypeObs O positive data mods Subject Subject Fetus data

  25. CDL is GE and Intermountain’s 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 Constraint Definition Language (CDL)

  26. The Core Model (reminder)

  27. Clinical Element Abstract Constraint Model Constrains the Abstract Instance Model to represent the semantics of a particular type of data 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} CDL and CEML are two implementations of the Abstract Constraint Model. They’re just grammars for saying this

  28. 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); }

  29. 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); }

  30. 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); }

  31. 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); }

  32. 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); }

  33. 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); }

  34. 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); }

  35. 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 }

  36. 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 }

  37. 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!

  38. Specific Cases in Modeling

  39. 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.

  40. Assertion versus Evaluation Styles

  41. Brown Blonde Red Data Entry Styles Hair Color Brown Hair Color Brown Blonde Red Evaluation Styles Brown hair Finding Brown hair Blonde hair Red hair Assertion Style

  42. data data Assertion Vs Evaluation Evaluation Style HairColorObs Hair Color Brown Assertion Style HairColorObs Assertion Brown Hair Color

  43. 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 Assertion Vs Evaluation

  44. 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 Single Code Style HairColorObs Brown Hair Color Deprecated representation

  45. Subject

  46. Subject – Evaluation Style Fetal Blood Type FetalBloodTypeObs O negative data Blood Type BloodTypeObs O negative data mods Subject Subject Fetus data

  47. Subject – Assertion Style #1 Assertion FetalBloodTypeObs Fetal Blood Type O negative data Assertion BloodTypeObs Blood Type O negative data mods Subject Subject Fetus data

  48. Subject – Assertion Style #2 Assertion BreastCancerInMotherObs Breast Cancer in Mother data Assertion BreastCancerObs Breast Cancer data mods Subject Subject Mother data

  49. data items items data Subject as a Compound Statement Subject Subject Relationship Relationship Maternal Aunt PersonIdentity Person Identity PersonName PersonName Clara Barton

  50. data items data mods Representation of Family History BreastCancerObs Assertion Breast Cancer Subject Subject Relationship Relationship Family (ancestor)

More Related