Electronic Medical Records

1. Electronic Medical Records

2. Topics • Introduction • A medical record • HIPAA • Security and Privacy • Accountability, Confidentiality, and Ethics • Workplace considerations

3. A medical record • Everything about you performed by a care provider • Doctor, nurse, phlebotomist, radiology technician • Every activity • Exams, meds, lab tests, x-rays • Paper form • Electronic

4. It’s about data and knowledge • Aggregation of data about the consumer from all points of care in order to provide a complete, dependable, accurate, and timely view of the person and health-related events • Continued extraction of knowledge from data and immediate and direct application of that knowledge in the process of care • A comprehensive EHR system with embedded decision support is the enabler.

5. Example • Vital Signs tracked and graphed • Chief Complaint/History of Present Illness with clinically-defined templates for a variety of medical and surgical specialties • Exam with clinically-defined templates • Diagnosis with ICD-9-CM database and billing • Prescriptions with a database • Plan with customizable point-and-click templates with appropriate findings • Progress Notes that automatically generate notes • E / M Level recommendations • Images, imported digital pictures, scanned images, anatomical drawings • Labs and results with HL7 interfacing that can be electronically transferred • Allergy Assessment • Referrals • Immunization

6. HIPAA • What is HIPAA? • Health Insurance Portability and Accountability Act • Primary goal – to assist in the portability of health insurance and to reduce the administrative cost of healthcare • What does this have to do with medical record security?

7. HIPAA Regulates • ensuring portability of health insurance • standards for electronic data interchange and code sets • health care identifiers • protecting against fraud in government funded health programs • protecting patient privacy and securing of health data

8. HIPAA • Standards of electronic data interchange • Aha! Electronic Medical Record • Protect patient confidentiality interests • Aha! System security

9. Security, Privacy, Confidentiality • Privacy – The Right • Right of the individual to have anonymity • Confidentiality – The Expectation • Obligation of the user of an individual’s information to respect and uphold that individual’s privacy • Security – The Mechanism • Policies, procedures, mechanisms, tools, technologies, and accountability methods to support Privacy

10. Privacy • Consent is required • Minimum Necessary • Patient Rights • Inspection, Proposing Amendment, Disclosure Accounting • Exceptions • Public Health, Legal Obligations for Disclosure

11. Privacy • Consent + Minimum Necessary • Your data will not be presented in a way where you can be identified • If we mask your name, but leave your address, age, and gender, you can be identified • Example of privacy abuse

12. Security – The Three “A”s • Authentication • You are who you say you are • Authorization • You can see and do what you are permitted by policy to see and do • Accountability • You are held responsible for what you see and do

13. Authentication • Passwords – simplest form of authentication • Can be very secure, but one breach can spread rapidly • Can be too secure – if you forget your password

14. Authorization • I’m a valid user or the system, and I’ve been authenticated. I want to see EVERYTHING on EVERYONE!!! • The system can define who is authorized to see and do what

15. Authorization Models • User Based • I have certain authorization rights based on who I am as an individual • Role Based • I have authority based on my role e.g. doctor vs. nurse vs. lab technologist • Context Based • Who you are + Where you are + What you are + When you are What you are

16. Authorization Challenge • We do not want to prevent anyone from providing care • Authorization in many cases is based on relationship to the patient • Providers declare a relationship when a patient is accessed • person_provider_relationship • All patient data access is logged!!! • person_provider_activity

17. Accountability • You are held responsible for what you see and do • Difficult to develop systems-based ways of ensuring accountability • An ethics problem • Security can help ensure accountability • Audit Logging – “We know where you’ve been” • Password policies • Alert capabilities

18. Ethics and Morals • One definition • Morals – choice between right and wrong • Ethics – choice between right and right • Example 1 • Famous person in hospital, and you’re curious about their lab results • Example 2 • Back to the banker example

19. Workplace Ethics • Many people may have access to patient data • Trust • Knowledge of Rules • Awareness of Consequences

20. A Problem • FAXing a document to a remote location • Anyone in the office can potentially see patient data • The office assumes all responsibility if they are a trusted business partner

21. Other Means of Security • Physical Access • Secured Areas – locked rooms • Technology Solutions • An ORACLE instance can be locked out • Users of other ORACLE instances on the same machine cannot gain access

22. Technology Solutions • Data Encryption • Data Aging – remove data after a certain time • Data Transmission Security – can’t move what isn’t authorized • Local Authentication • Includes time-out function

23. Who is responsible? • Healthcare provider is ultimately responsible • But, the IT supplier that has a systems solution will have a competitive advantage • So, at Cerner we have enhanced our systems to be “HIPAA compliant” • Authentication • Authorization • Access logging

24. Workplace Ethics II • Access to over 1500 clients from my desk • High-privilege accounts, required for troubleshooting • Back-end data access – we can see most anything • Client-specific security measures • We MUST follow ALL policies • Who we are, what are we doing, what did we do • My own client security anecdote…. • Can we look up data on celebrities? Family members?

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

26. Electronic Medical Record • 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

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

28. What must be in place • Data standards • Reference Information Model • Common data elements • Common data types • Common terminology • Clinical templates • Ability to share data and knowledge • Data interchange standards • Common content architecture standards • Common minimum set of functions for the EHR • Infrastructure to support required connectivity • Common methods of knowledge representation

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

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

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

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

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

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

35. 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-careplans, employers • Transferring patient data across different systems • Representing medical knowledge that can be reused

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

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

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

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

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

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

42. 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)

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

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

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

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

47. 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)

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

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

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