Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this


  1. 1. Computer-Based Patient Records and Medical Informatics Standards Yuval Shahar M.D., Ph.D. Medical Decision Support Systems
  2. 2. The Medical (Patient) Record • A historical record of patient care • A communication tool among care providers • A research and knowledge-gaining tool • A teaching tool • An operational tool (e.g., order entry) • A business tool (e.g. to support billing) • An administration record (e.g., to manage resources) • A legal record with considerable longevity
  3. 3. Electronic Medical Record (EMR) • AKA: Computer-Based Patient Record (CPR) • Provides multiple advantages vs. manual records: – Record can be used by multiple personnel at the same time – Record is accessible from anywhere (even from home) – Clear, well-organized, legible documentation – Data can be reused for other purposes – Data can be integrated from multiple sources transparently – Data can be validated automatically – Enables multiple automated research and decision-support functions (analysis, machine learning and data mining, automated diagnosis, reminders, guideline-based care) – Decision support can be integrated with use of the patient record
  4. 4. EMR: Costs • Large initial set-up investments – Hardware, software, training, support, maintenance • Significant workflow changes • Significant organizational changes • Difficult data entry relative to handwriting • Potential catastrophic failure – Note: paper records also have “down” times
  5. 5. Integration of EMR and Decision Support Modules • Decision support is most effective when integrated with an EMR – The most likely opportunity for providing decision support is when the physician is assessing the patient record or entering an order – All or most relevant patient data can be accessible to the DSS and do not require separate entry – Physician should always be able to override the recommendation and, if relevant, provide feedback
  6. 6. Order Entry • A major function of an EMR system, allowing care providers to enter clear, legible orders for patient care anytime, anywhere • Supports validation of order, issuing of alerts, suggestion of relevant information and knowledge, and even actions • Quick effect on physician ordering behavior
  7. 7. EMR and Knowledge Sources • The most effective time to provide access to knowledge is when the care provider is browsing the patient record • A query can be formulated in a context-sensitive manner with respect to the patient record, thus anticipating the physician’s needs – Note: Queries often have relatively expected structure and content (e.g., which drug is useful for condition X in context Y; What are side effects of drug Z when used in manner W; What clinical guidelines are most relevant for disease D in patients of type P)
  8. 8. EMRs: Major Issues • Data Entry – Data capture: the scope of the data that is or can be represented in the EMR – Data input: coded data are difficult to input by physicians; text is less useful for processing – Errors can be reduced by multiple validity checks
  9. 9. Validity Checks During Data Entry in an EMR • Range checks (Hemoglobin in [0..30] Gr/Dl) • Pattern checks (a telephone number pattern) • Numeric and other inter-data constraint checks (total of WBC differential is 100%) • Consistency checks (pregnant male??) • Temporal-abstraction checks (weight cannot change by 50 Kgs in 2 days) • Spelling checks
  10. 10. Physician-Entered Data • The main challenge to EMR developers! – Patient histories, physical findings, interpretations, diagnostic and treatment plans • Several very different entry methods – Transcription of dictated or written notes – Structured encounter forms from which notes are transcribed and even encoded – Direct entry of data by physician via computer • Speech recognition might alleviate some of the difficulties
  11. 11. Security Issues in EMRs • Authorization – Is my dentist allowed to see my gynecological record? – Which fields of my record can my or another GP view? – Who has asked to view my records last month? • Authentication – Is this user really my physician? • Encription – Can an eavesdropper understand the message sent to my doctor? • Eventually, security depends on people
  12. 12. The Need for Standards • EMRs and almost any other information-oriented system in a clinical environment cannot be used without well-defined standards for representing and communicating information • Data need to be exchanged between multiple, heterogeneous systems and might be used by very different applications • Standards are needed for several different uses: – Identifying patients, providers, health-care plans, employers – Transferring patient data across different systems – Representing medical knowledge that can be reused
  13. 13. How are Standards Developed? • Ad hoc – A group of interested people and organizations agree on an informal specification (ACR/NEMA DICOM) • De facto – A single vendor creates standard through monopoly (Microsoft Windows) • Government mandate – Agency creates a standard and legislates it (HCFA UB92 claim form) • Consensus – A group of volunteers work openly to create standard (HL7).
  14. 14. Examples of Information- Standards Organizations • American National Standards Institute (ANSI) – Private, nonprofit – Accredits organizations that create standards • Technical Committee 251 (CEN TC 251) – The European Standardization Committee’s technical committee for medical informatics standards • American Society for Testing and Materials (ASTM) – Largest non-government source of standards in the USA – ASTM committee E31 is responsible for development of medical information standards
  15. 15. Terminologies and Controlled Vocabularies • Precoordinated – All concepts encoded beforehand – no possibility of creating new terms • Postcoordinated – New combinations can be formed from existing terms to describe new concepts
  16. 16. International Classification of Diseases (ICD) – Intended mostly for talking about dead people (reporting mortality statistics to the WHO) – Strict hierarchy with core 3-digit codes, possibly 4th digit – ICD-9 (1977) common; inadequate for clinical reporting – ICD-9-CM (Clinical Modifications) adds extra levels of details by 4th and 5th digits, popular in USA – ICD-10 (1992) exists, but no clinical modifications yet
  17. 17. Codes in The International Classification of Diseases (ICD-9 CM( 724 Unspecified disorders of the back 724.0 Spinal stenosis, other than cervical 724.00 Spinal stenosis, unspecified region 724.01 Spinal stenosis, thoracic region 724.02 Spinal stenosis, lumbar region 724.09 Spinal stenosis, other 724.1 Pain in thoracic spine 724.2 Lumbago 724.3 Sciatica 724.4 Thoracic or lumbosacral neuritis 724.5 Backache, unspecified 724.6 Disorders of sacrum 724.7 Disorders of coccyx 724.70 Unspecified disorder of coccyx 724.71 Hypermobility of coccyx 724.71 Coccygodynia 724.8 Other symptoms referable to back 724.9 Other unspecified back disorders
  18. 18. Diagnosis-Related Groups (DRGs( • A USA (Yale( abstraction of the ICD-9-CM codes • A small number of codes grouping multiple diagnosis codes by similar expected costs of hospitalization • Modifies the major diagnosis by associated conditions, severity, and procedures to determine specific DRG code
  19. 19. Current Procedual Terminology (CPT( • Encodes diagnostic and therapeutic procedures • Adopted in the USA for billing and reimbursement • Similar to DRG, classifies procedures by cost and reasons • CPT-4: The main code used for reporting physician services to government and private insurance reimbursement
  20. 20. Diagnostic Statistical Manual of Mental Disorders (DSM( • Published by the American Psychiatric Association • Provides nomenclature as well as definitions (diagnostic criteria( of psychiatric disorders • Coordinated with ICD; e.g., DSM-IV is coordinated with ICD-10
  21. 21. Systemized Nomenclature of Medicine (SNOMED( • Developed by the American College of Pathologists • Evolved from SNOP, A multi-axial system for describing pathological findings by postcoordination of topographic (anatomic(, morphologic, etiologic, and functional terms • SNOMED III: 11 axes, more than 130,000 terms • SNOMED-RT (Reference terminology( created to encourage more consistent use of terms • Main problem: Too expressive—several ways of defining the same term (e.g. acute appendicitis(
  22. 22. Read Clinical Codes • Developed by James Read during the 1980s • Adopted by the British National Health Service (NHS( in 1990 • Version 3 is a multiple hierarchy, and version 3.1 added ability for postcoordination of modifiers • Work undergoing to map to SNOMED
  23. 23. The Unified Medical Language System (UMLS( • A project of the National Library of Medicine (within the National Health Institutes [NIH]( • Main resource: The Metathesaurus – contains over 330,000 terms – relates terms from over 40 different sources • Supports searching the medical literature • Uses Medical Subject Headings (MeSH( which are used to index medical literature
  24. 24. Logical Observations, Identifiers, Names and Codes (LOINC( • A naming system developed by McDonald and Huff for tests and observations (now includes also vital signs, ECG, etc( • Uses six semantic axes to encode the test, such as substance measured (urine( and analysis method used • Coordinated development with the European Clinical Data Exchange Standard (EUCLIDES( standard
  25. 25. Data Interchange Standards • Allow a sender to transmit data (a transaction set) to a receiver in unambiguous fashion • Closely related to the Open Systems Interconnection (OSI) 7-layer communication model of the International Standards Organization (OSI) – Physical, data link, network, transport, session, presentation, and application (semantic-specification) layers • Typically use position dependent or tagged field format
  26. 26. Example Data-Interchange Standards • ACR/NEMA – American College of Radiologists with the National Electronic Manfacturers Association – Current version: DICOM 3.0; uses an object oriented model and supports ISO communications • ASTM E31 – Published E1238, Standard Specification for Transferring Clinical Observations Between Independent Systems – E1460: Defining and Sharing Modular Health Knowledge Bases is the Arden Syntax for Medical Logical Modules
  27. 27. Health Level 7 (HL7) • Today, includes more than 500 industrial and academic organizational members and over 1800 individual members • Name refers to OSI application layer 7 • A standard for exchange of data among different hospital computer applications • Built upon ASTM 1238 and other protocols • Version 3 (1999) is object oriented and uses a Reference Information Model (RIM)
  28. 28. Functions of a Health-Care Information System (HCIS) (I) • Patient management – Admission, Discharge, Transfer (ADT) – Patient tracking • Departmental management – Ancillary departmental systems support clinical departments; laboratory, radiology, pharmacy, blood bank and medical records are most commonly automated • Care delivery and Clinical documentation – Mostly order entry and results reporting
  29. 29. Functions of a Health-Care Information System (HCIS) (II) • Clinical decision support – Built upon other HCIS components and need to be integrated with them (e.g. during order entry) • Financial and resource management – Typically the first functions to be centralized • Managed-care support – Integrated Delivery Networks (IDNs) start focusing more on patient health maintenance rather than cutting costs of treating sick patients – Thus, provider-profiling systems, contract management systems and more sophisticated modules
  30. 30. Three Classic HCISs (1) • The HELP system at the University of Utah – Developed by Warner et al. at LDS Hospital – Incorporated decision support logic modules from the start; these react to data and issue reminders, alerts, and advices – Uses the HELP Frame Language – Eventually led to Medical Logical Modules and the Arden Syntax
  31. 31. Three Classic HCISs (2) • The Center for Clinical Computing (CCC) system at Beth Israel Deaconess Medical Center – Developed by Bleich and Slack as a centralized system in Beth Israel Hospital, Boston from 1978 – Intensively used – Includes knowledge access to MedLine via the PaperChase module, as well as email – Ambulatory system supports problem lists and clinic notes – Uses a MUMPS database, used as the clinical-data repository, and the ClinQuery online data warehouse – Very little decision-support functionality
  32. 32. Three Classic HCISs (3) • The DIOGENE System at Geneva Canton University Hospital – Developed by Jean-Raoul Scherer and colleagues from 1971 – Migrated from a centralized to distributed architecture – Supports all administrative and clinical functions – Reports are printed; physicians write orders by telephoning an operator who types the order while physician dictates, views typing on computer screen, and gives verbal consent.