Presentation on how to chat with PDF using ChatGPT code interpreter
Iehr ciif sdk-slides-draft-h
1. Open Source EHR Custodial Agent (OSEHRA) Architecture Committee Stephen Hufnagel PhD, Chair & Health Architecture Interagency Group (HAIG) Nancy Orvis, MHA, CPHMS and Paul Tibbits, M.D., DoD and VA Co-Chairs Current version is always available at: http://www.osehra.org/node/47/content/documents October 9, 2011 DRAFT-H Software Development Kit (SDK) for Interoperable EHR (iEHR) Common Information Interoperability Framework (CIIF) CALL FOR PARTICIPATION Please send updates and suggestions for improvement to HufnagelS@OSEHRA.org
2. ACKNOWLEDGEMENT This iEHR-CIIF SDK started with the most excellent Canada Health Infoway “ Electronic Health Record Blueprint ” as a foundation; the SDK is being adapted to meet the US OSEHR, DoD and VA interoperable EHR situation and needs. https://www.infoway-inforoute.ca/working-with-ehr/knowledgeway/knowledge-center/657 A five color star “branding” indicates that a slide was adapted from Canada Health Infoway’s EHR Blueprint
3.
4.
5.
6.
7.
8.
9.
10. iEHR-CIIF SDK Scope WORK PROCESS INFORMATION SYSTEM TECHNOLOGY framework V1 framework V2 iEHR-CIIF CONCEPTUAL LAYER ADDRESSES BUSINESS CONTEXT (Mission, objectives, stakeholders, benefits) iEHR-CIIF Implementations framework V2 framework V1 framework V2 Conceptual framework V2 framework V2 framework V2 Logical Physical YES YES YES YES YES YES
11. Architecture Perspectives CONTEXT Business Architecture Clinical Work Process Architecture Potential Applications Integration & Deployment Models System Architecture Information Architecture iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
12. Architecture Perspectives CONTEXT Business Architecture Clinical Work Process Architecture Potential Applications Integration & Deployment Models System Architecture Information Architecture iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
14. Healthcare Industry Provides $ Patient Planning & Resources VHA, MHS, IHS, SSA, State Agencies, etc. Clients/Patients Providers Tax $$$ Planning & Resources Pharmacy Laboratory Diagnostic Hospital Emergency Specialist Clinic Homecare Community Care Center Elected Federal Government Federal Agencies and States Emergency Services iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
15. International Industry: IT Spending Comparisons IT spending as a % of total expenditures SOURCE: Gartner Group – as reported in the Health Services Restructuring Commission’s (www.hsrc.gov.on.ca) report: Ontario Health Information Management Action Plan, June 1999 This slide needs to be updated or removed This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
16. Mean Hospital: IT spending in Canada <2% SOURCE: 2003 Report on I.T. in Canadian Hospitals: Top issues, applications and vendors. Canadian Healthcare Technology, 2003. CIHI NHex 2002 (Hospital Expenditures) IT budgets as a % of total hospital budget This slide needs to be updated or removed This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
17.
18.
19.
20. iEHR-CIIF: Key Concepts iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
21.
22.
23. EHR Information Infrostructure (EHRI) The EHR Infostructure is a collection of common and reusable component-services in support of a diverse set of health information management applications. It consists of interoperable software-solutions for the EHR, semantically-interoperable data and terminology for the EHR and secure information-exchange standards for the EHR. iEHR-CIIF WORKING DRAFT: not for wide distribution or official use See notes page
24.
25. Key iEHR-CIIF Architecture Concepts This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page Interoperable EHR SOLUTION (iEHR-CIIF) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application iEHR-CIIF Locator Longitudinal Record Services (LRS) Common Information Interopérability Framework (CIIF) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services
26. iEHR-CIIF Framework Recommended Approach: A DoD. VA & Purchased Care EHR Service iEHR iEHR iEHR iEHR iEHR iEHR iEHR This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Information Interopérability Framework (CIIF) Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Information Interopérability Framework (CIIF)
27. iEHR-CIIF Infostructure: Conceptual Architecture This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page ORGANISATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information POINT OF SERVICE Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Physician/ Provider Business Rules EHR Index Message Structures Normalization Rules Security Mgmt Data Privacy Data Configuration Physician/ Provider Physician/ Provider Lab System (LIS) Lab Clinician Radiology Center PACS/RIS Radiologist Pharmacy System Pharmacist Public Health Services Public Health Provider Longitudinal Record Services (LRS) CIIF Secure Communications Bus Common Services Client Registry Provider Registry Location Registry Terminology Registry
28.
29. Generations of EHR Capabilities Full Functionality Minimal Gen 4 The Colleague Gen 2 The Documentor Gen 3 The Helper Gen 5 The Mentor Availability of Products 1993 1998 2005 2010 2015+ Gen 1 The Collector Source: Gartner (December 2005) End of 2009 This slide needs to be updated See notes page
30.
31. Great Impact on links between components (e.g., interoperability) Little Impact on links between components (e.g., Interoperability) Little impact on components Great impact on components Architectural Innovation Radical Innovation Incremental Innovation Modular Plug-&-Play Innovation Future-State-Architecture GOAL OBJECTIVE A change-immune domain-specific component-architecture emphasizing interoperable standards-based services, resulting-in simpler, loosely-coupled, and less-costly module-level innovation. PROBLEM Little innovation, long lead times and high costs resulting from complex highly-coupled components End Architectural Vision for Semantic Interoperability Start
32. iEHR ‘Cherry’ Architecture March 2011 Version 10/15/11 See notes page Common Interface Standards Presentation (Common GUI) Common Data Centers Common Services Broker (includes Enterprise Service Bus (ESB) and Infrastructure Services) Presentation Layer Team Systems Capabilities Team Enterprise Architecture Team Data Inter- operability Team Mission Requirements & Performance Outcomes Team Business Process Team Common Information Interoperability Framework (CIIF) Common Information Model, Common Terminology Model, Information Exchange Specifications, Translation Service Common Data Standards: SNOMED CT and Extensions, LOINC and RxNorm DoD Only VA Only Joint DoD/VA Pharmacy Disability Evaluation Dental Care Personal Health Record Inpatient Orders Mgmt Consult & Referral Mgmt Immunization Laboratory Emergency Dept Care Nursing Home Rehabilitative Care Long Term Care Transient Outreach DoD Unique (16) VA Unique (6) Common (Joint) Applications & Services (30) Battlefield Care Pediatrics Military Readiness Obstetrics Enroute Care Veterinary Operating Room Mgmt Blood Mgmt Document Mgmt Applications and Services Common DoD-VA Requirements: HL7 EHR-S Functional Model with DoD and VA vetted Extensions (SV-4) Common DoD-VA Integrated Health Business Reference Model (OV-5) Common DoD-VA “To Be” Process Flow Model (OV-6C) Common DoD-VA Measures of Effectiveness, Measures of Performance and key Performance Parameters Occupational Health (VA) Pharmacy Mail Order Common Interface Standards
35. Pharmacy Delivery Use Case – The CIIF Leads the Way Rules Engine Mediation Services Translation Services Common Information Interoperability Framework (CIIF) Common Information Model, Common Terminology Model, Information Exchange Specifications, Translation Service Common Data Standards: See notes page
37. iEHR-CIIF Serving Healthcare Service Delivery Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Information Interopérability Framework (CIIF) This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Poin of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Information Interopérability Framework (CIIF) Diagnostic Hospital Emergency Specialist Clinic Homecare Clients/Patients Community Care Center Emergency Services Pharmacy Laboratory Diagnostic Hospital Emergency Specialist Clinic Homecare Clients/Patients Community Care Center Emergency Services Pharmacy Laboratory
38.
39.
40.
41. iEHR-CIIF Serving Public Health Service Delivery POINT OF SERVICE Hospital, Community, etc… EPR Physician Office EMR EHR Viewer Physician/ Provider Physician/ Provider Physician/ Provider Lab System (LIS) Lab Clinician Radiology Center PACS/RIS Radiologist Pharmacy System Pharmacist Other PH System(s) Public Health Providers Public Health Surveillance Portal PHS Systems Operational data CM OM AM IM* PHSA This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information Business Rules EHR Index Message Structures Normalization Rules Security Mgmt Data Privacy Data Configuration Longitudinal Record Services (LRS) CIIF Secure Communications Bus Common Services Client Registry Provider Registry Location Registry Terminology Registry Immunization “ Registry “ Reference Management PHS Data Warehouse Services Case Management Alert Notification Services Messaging Content & Knowledge Management Security & Privacy Services
42.
43. iEHR-CIIF Serving Telehealth Scheduling ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Health Information Business Rules EHR Index Message Structures Normalization Rules Security Mgmt Data Privacy Data Configuration Longitudinal Record Services (LRS) CIIF Secure Communications Bus Common Services POINT OF SERVICE Referring Physician Site Attending Physician Site Physician/ Provider Physician/ Provider TSA Database Telehealth Scheduling Application (TSA) Shared Health Record Drug Information Diagnostic Imaging Laboratory Provider Registry Location Registry Terminology Registry Client Registry This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page Patient Info End-user Info Event History Clinical Profile Scheduling Video Session
44. iEHR-CIIF Framework: Tele-Consultation Local Electronic Medical Record Live Video-Conferencing Session Tele-Consultation Devices Data Telehealth Application Telehealth Application Local Electronic Patient Record iEHR-CIIF WORKING DRAFT: not for wide distribution or official use This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF)
45. iEHR-CIIF Framework: Tele-Homecare Local Electronic Medical Record Tele-Homecare Data Feed Tele-Consultation Devices Homecare Application Server Homecare Client Application iEHR-CIIF WORKING DRAFT: not for wide distribution or official use This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF)
46. iEHR-CIIF Framework: Tele-Triage Tele-Triage Application Personal Health Record Application EHR Viewer iEHR-CIIF WORKING DRAFT: not for wide distribution or official use This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) Patient Info End-user Info Event History Clinical Profile Scheduling Video Session
47. Clinical, Business & Socio-economic Drivers for Interoperable EHR SOLUTIONs iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
48.
49. How Is Value Delivered By An iEHR? # of Data Domains Included (Encounter Summaries, Lab, DI, Drugs, etc.) Extent of the Care Continuum Involved (PCP office, Hospital, Long Term Care Homecare, etc.) Local Care Area Natural Referral Area Point of greatest value The value of the iEHR for clients, families and their providers increases with the completeness of the information contained as well as the level of standardization of the data This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page
50. Why Pursue The iEHR-CIIF: Circle of Care Pharmacy Laboratory Diagnostic Hospital Emergency Homecare Community Care Center Clinic Emergency Services Specialist Clinic See notes page
51.
52.
53.
54. Different Approaches To Achieving iEHR-CIIF iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
55. iEHR-CIIF: How Do We Do This? Sharing Information From Multiple Systems Pharmacy Laboratory Diagnostic Hospital Emergency Homecare Community Care Center Clinic Emergency Services Specialist Clinic Clients/Patients INTEGRATED VIEW
56.
57.
58. The Integration Challenge of Interoperable EHR Solutions iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
59. Integrating Heterogeneous Systems Pharmacy Laboratory Diagnostic Hospital Emergency Homecare Community Care Center Clinic Emergency Services Specialist Clinic Clients/Patients
60. Integrating Heterogeneous Systems: Hospital Pharmacy Laboratory Diagnostic Homecare Community Care Center Clinic Emergency Services Specialist Clinic Hospital Emergency Clients/Patients ADT Order/ Results Electronic Patient Record Specialized Care Pharmacy Scheduling Laboratory Clinical Data Repository Radiology PACS Emergency Human Resources Hospital Emergency Finance, inventory, payroll
61. Integrating Heterogeneous Systems: Hospital Pharmacy Laboratory Diagnostic Homecare Community Care Center Emergency Services Specialist Clinic Hospital Emergency Clinic Clients/Patients Clinic Scheduling Accountiing/ Billing Electronic Medical Record
62. Locations of Electronic Clinical Data Today: Number of Systems to Integrate Pharmacy Laboratory Diagnostic Hospital Emergency Homecare Community Care Center Clinic Emergency Services Specialist Clinic This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] Clients/Patients
63.
64. Recommended Approach: The Cost of Integration As A Key Driver iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
65.
66.
67.
68. Architecture Perspectives CONTEXT Business Architecture Clinical Work Process Architecture Potential Applications Integration & Deployment Models System Architecture Information Architecture iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
69.
70. iEHR-CIIF Reference Architecture iEHR-CIIF Reference Architecture POINT OF SERVICE POS APPLICATION SIGNIFICANT REUSE HERE Life Of The Lamberts CIIF Comm Step Put New Patient EHR IP Add New Patient EHR IP EHR IP EHR IP Clinical Events Clinical Events Clinical Events New Family Physician Activity Clinical Activity Clinical Activity Clinic Visit Admission New Family Physician Activity Encounter Encounter COPD Storyboard Storyboard Storyboard iEHR-CIIF WORKING DRAFT: not for wide distribution or official use This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Physician/ Provider Physician/ Provider Physician/ Provider Lab System (LIS) Lab Clinician Radiology Center PACS/RIS Radiologist Pharmacy System Pharmacist Public Health Services Public Health Provider
71. Documenting EHRi Services Requirements iEHR- CIIF Reference Architecture POINT OF SERVICE Physician Office EMR EHR Viewer EHR Viewer Physician/ Provider Physician/ Provider Physician/ Provider Physician Office EMR Lab Clinician Hospital, LTC, CCC, EPR Radiologist EHR IP Data EHR IP Data EHR IP Data EHR IP Data EHR IP Data ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information Business Rules EHR Index Message Structures Normalization Rules Security Mgmt Data Privacy Data Configuration Longitudinal Record Services (LRS) CIIF Secure Communications Bus Common Services EHR IP EHR IP EHR IP EHR IP EHR IP IP “Put” IP “List” IP “Get” IP “List” IP “Get” EAI IP EAI IP CIIF EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP Provider Registry Location Registry Terminology Registry Client Registry EAI IP EAI IP EAI IP EAI IP This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
72.
73.
74.
75.
76. Architecture Perspectives CONTEXT Business Architecture Clinical Work Process Architecture Potential Applications Integration & Deployment Models System Architecture Information Architecture iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
77. EHR Infostructure: Services Drill-Down ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information POINT OF SERVICE Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Physician/ Provider Business Rules EHR Index Message Structures Normalization Rules Security Mgmt Data Privacy Data Configuration Physician/ Provider Physician/ Provider Lab System (LIS) Lab Clinician Radiology Center PACS/RIS Radiologist Pharmacy System Pharmacist Public Health Services Public Health Provider Longitudinal Record Services (LRS) CIIF Secure Communications Bus Common Services Client Registry Provider Registry Location Registry Terminology Registry This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
78. EHR Infostructure: Standards Based Connectivity ORGANIZATIONAL INFOSTRUCTURE POINT OF SERVICE Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Physician/ Provider Physician/ Provider Physician/ Provider Lab System (LIS) Lab Clinician Radiology Center PACS/RIS Radiologist Pharmacy System Pharmacist Public Health Services Public Health Provider EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR SCP Standards Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information Business Rules EHR Index Message Structures Normalization Rules Longitudinal Record Services (LRS) EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP Provider Registry Location Registry Terminology Registry Client Registry EAI IP EAI IP EAI IP EAI IP Security Mgmt Data Privacy Data Configuration EAI IP EAI IP CIIF Secure Communications Bus Common Services This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
79. EHR Infostructure: Secure Communications Bus This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Secure Communications Bus Secure Communications Bus MESSAGING Transformation Services Routing Services Encrypt/Decrypt Services En/Decoding Services Parser Services Serialization Services PROTOCOL App Protocol Services Network Protocol Services
80. EHR Infostructure: Common Services This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Security Mgmt Data Privacy Data Configuration Common Services COMMON SERVICES INTEROP Interoperability Services Search/Resolution Services INTEGRATION Service Catalogue Services Broker Services Mapping Services Queuing Services CONTEXT Session Mgmt Services Caching Services Identity Protection Services Identity Mgmt Services Anonymization Services User Authentication Services Consent Directives Mgmt Services Encryption Services Access Control Services Secure Auditing Services Digital Signature Services General Security Services SUBSCRIPTION Alert/Notification Services Pub/Sub Services MANAGEMENT Management Services Configuration Services GENERAL Auditing Services Log Mgmt Services Policy Mgmt Services Exception/Error Handling Services PRIVACY & SECURITY
81. EHR Infostructure: Longitudinal Record Services (LRS) This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Business Rules EHR Index Message Structures Normalization Rules Longitudinal Record Services (LRS) Longitudinal Record Services (LRS) DATA Key Mgmt Services ETL Services BUSINESS Data Quality Services Domain Business Components (Registries, EHR, Domains, User, Context) EHR Index Services Orchestration Services Normalization Services Business Rules Services Assembly Services Data Services Replication Services
82.
83.
84. Centralized Service Approach CROSS-ORGANIZATIONAL INFOSTRUCTURE ORGANIZATIONAL INFOSTRUCTURE POINT OF SERVICE Organization A Organization B Organization C This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] iEHR-CIIF Locator Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) Common Interoperable Information Infrastructure (CIIF)
85. Distributed Service Approach CROSS-ORGANIZATIONAL INFOSTRUCTURE ORGANIZATIONAL INFOSTRUCTURE POINT OF SERVICE iEHR-CIIF Locator Synchronization Organization A Organization B Organization C This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] iEHR-CIIF Locator iEHR-CIIF Locator Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) Common Interoperable Information Infrastructure (CIIF)
86. iEHR-CIIF Locator: LRS Integrated Approach POINT OF SERVICE CROSS-ORGANIZATIONAL INFOSTRUCTURE ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services EHR Data & Services Data Warehouse Registries Data & Services Business Rules EHR Index Message Structures Normalization Rules Longitudinal Record Services (LRS) Client Registry Provider Registry Location Registry Terminology Registry CIIF This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] iEHR-CIIF Locator
87. LRS Integrated Services Approach CROSS-ORGANIZATIONAL INFOSTRUCTURE ORGANIZATIONAL INFOSTRUCTURE POINT OF SERVICE Client Registry Synchronization Organization A Organization B Organization C Registries Data & Services Registries Data & Services Registries Data & Services This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Longitudinal Record Services (LRS) Interoperable EHR SOLUTION (iEHR) EHR INFOSTRUCTURE (EHRi) EHR Viewer Point of Service Application Point of Service Application Population Health Data & Services Health Information Data Warehouse EHR Data & Services Longitudinal Record Services (LRS) Common Interoperable Information Infrastructure (CIIF) Common Interoperable Information Infrastructure (CIIF)
88. EHR Infostructure: EHR Data Domain Services This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Shared Health Record Drug Information Diagnostic Imaging Laboratory SHARED HEALTH RECORD DATA Key Mgmt Services BUSINESS Domain Business Components (Registries, EHR, Domains, User, Context) Normalization Services EHRi Interoperability Services Business Rules Services Assembly Services Data Services
89. EHR Infostructure: EHR Viewer This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF EHR Viewer Physician/ Provider EHR VIEWER EHRi Interoperability Services EHR Viewer Business Objects Components Normalization Services End-user Navigation Services Business Rules Services End-user Display Services Data Services
90. EHR Infostructure: Client Registry ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Client Registry Provider Registry Location Registry Terminology Registry This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
91. EHR Infostructure: Why A Client Registry? ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Client Registry Provider Registry Location Registry Terminology Registry Has Mr. Lambert had any ER visits since I’ve last seen him one year ago? EHR VIEWER This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] EHR Viewer Physician/ Provider Patient Info End-user Info Visit History Drug Profile Laboratory Diagnostic Imaging
92. EHRi Client Registry: The Challenge Pharmacy A Lab B ??? C 1: A 123 Robert Lambert 1 Main St 1: B 456 Bob Lambert 1 Main St 1: C 789 Robert Lambert 1 Main St 1: C 987 Robert Lambert 1 Main St 2: B 444 Robert Lambert 2 Elm St 123 Robert Lambert 1 Main St 456 Bob Lambert 1 Main St 444 Robert Lambert 2 Elm St 789 Robert Lambert 1 Main St 987 Robert Lambert 1 Main St EMPI This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
93.
94. EHRi Client Registry: Interoperability Pattern ORGANIZATIONAL Applications Client Registry J1 Client Registry J1.1 Client Registry J1/2 Client Registry J2 ECID: J1 Root ID. Client ID ECID: J2 Root ID. Client ID Active synchronization of travelling clients only Applications This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
95. EHR Infostructure: Provider Registry This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Client Registry Provider Registry Location Registry Terminology Registry
96. EHR Infostructure: Why A Provider Registry? Have any new test results been published for me? EHR VIEWER This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse POINT OF SERVICE CIIF Client Registry Provider Registry Location Registry Terminology Registry Patient Info End-user Info Visit History Drug Profile Laboratory Diagnostic Imaging EHR Viewer Physician/ Provider
97. Provider Registry: Data Sources ORGANIZATIONAL REGIONAL Provider Registry Applications Applications Applications Doctors Dentists Unlicensed Providers EHR SCP Standards Provider Registry EHR SCP Standards Provider Registry This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address]
108. Level of Encapsulation Can Vary: Five Normal Forms of Encapsulated Software 1 2 3 4 5 External access Other data Own data Encapsulated software Programmatic interface Overloaded, incomplete; any data One complete function; any data Own data only Exclusive data Opaque data Source: Gartner See Notes Page This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page
109.
110. First Degree: The EHR Service This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information POINT OF SERVICE Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Physician/ Provider Business Rules EHR Index Message Structures Normalization Rules Security Mgmt Data Privacy Data Configuration Physician/ Provider Physician/ Provider Lab System (LIS) Lab Clinician Radiology Center PACS/RIS Radiologist Pharmacy System Pharmacist Public Health Services Public Health Provider Longitudinal Record Services (LRS) CIIF Secure Communications Bus Common Services Client Registry Provider Registry Location Registry Terminology Registry EHR SERVICE Get Client ID Resolution List Laboratory Orders Get Laboratory Result List Laboratory Results Get Prescription List Medications Stream DI Image List DI Results Get DI Report Get Outbreak Case Data List CD Report Events Get Provider Information List Service Delivery Locations List Encounter Events Get Encounter Summary Get Clinical Dashboard Get Client Demographic
111. Second Degree: Inside The EHR Infostructure See Notes Page This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs. Please send suggested updates to [email_address] See notes page ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information POINT OF SERVICE Business Rules EHR Index Message Structures Normalization Rules Security Mgmt Data Privacy Data Configuration Longitudinal Record Services (LRS) CIIF Secure Communications Bus Common Services Client Registry Provider Registry Location Registry Terminology Registry EHRi SERVICES CR Services PR Services LR Services Terminology Services Detection & Reporting Services Shared Health Record Services Drug Services DI Services Lab Services Normalization Services Assembly Services A & A Services Brokering Services Consent Services Session Services Logging Services Outbreak Services Rules Services Orchestration Services EHR Index Services Any Point-of-Service Application EHR IP
114. Architecture Perspectives CONTEXT Business Architecture Clinical Work Process Architecture Potential Applications Integration & Deployment Models System Architecture Information Architecture iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
115.
116.
117. Key Terms and Concepts … Terminology The approach to common terminology is for both agencies to use SNOMED + Extensions = Lingua Franca for DoD-VA Terminology. The EHRWF will incorporate the CIIF Information and terminology models as the logical data models for our shared (virtual) repositories; thereby, improving semantic interoperability and performance. See notes page
118. Use Case Example: Patient is Admitted with “Cold” Symptoms As-Is = Different Points of Entry Can Have Different Interpretations of “Cold” Cold = Patient is diagnosed with the Common Cold cold = Patient is diagnosed as psychologically unfeeling and distant C.O.L.D. = Patient is diagnosed with Chronic Obstructive Lung Disease MHS VA Private Health Sector & Other The CIIF reduces redundancies, leverages agency resources, provides contextual information, and ensures data integrity across DoD and VA applications, directly improving continuity of care As-Is… To Be… The right diagnosis based on the right data applied in the right context
119. HDD and SNOMED-CT mapping work - Mapping Example (not actual codes) See notes page HDD NCID SNOMED-CT RxNORM MEDCIN CPT CHCS 1 VistA 1 443 <Substance> <acetylsalicylic acid (ASA) ID: 123455> <Orderable drug Brand Name ID> <Aspirin: 82464> 2214 N/A ASP A112 812 <Condition: diagnosis><Cold> N/A 9923 123 Cld CD8 123 <Procedure Test Result Name:> < Red Blood Count> N/A 1324 98231 RBC RBC 923 DoD specific term VA term
120.
121. “ As Is” System Data Interoperability Schematic EHRWF/CIIF System Data Interoperability Schematic System Data Interoperability See notes page for explanation of slide See notes page
122. Architecture Perspectives CONTEXT Business Architecture Clinical Work Process Architecture Potential Applications Integration & Deployment Models System Architecture Information Architecture iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
123. CIIF Integration Layer: Evolutionary Path iEHR=CIIF WORKING DRAFT: not for wide distribution or official use
124.
Hinweis der Redaktion
iEHR is a part of a joint DoD-VA Open Source EHR (OSEHR) Initiative
Full Executive Summary The Common Information Interoperability Framework ( CIIF ) is a federated component of the DoD-VA Interoperable Electronic Healthcare System (iEHR). CIIF can be shared between partners; it is made up of design-time information models, which define the run-time structure and computable meaning of the information exchanged, managed, and/or stored. It includes services such as a Meta Data Registry ( MDR ) and Common Terminology Service ( CTS ). CIIF defines information models and a data-concept dictionary of detailed description of all of the types of data elements used plus the context-sensitive attributes and relationships of those elements. CIIF defines the use of controlled clinical terminologies as part of these models and CIIF includes additional services useful for translation and transformation of legacy information. CIIF can assure syntactic and semantic information interoperability, while supporting privacy (e.g., right to not disclose), confidentiality (e.g., promise to maintain control of information) and security (e.g., a mechanism that assures safety from unauthorized information disclosure) constraints. “ iEHR Common Data ” implies native use of a single logical database, specified by the CIIF. The CIIF design-time Model-Driven Healthcare-Tools manage information and terminology models, a concept dictionary and translation models, information exchange payload models, schemas and schematron. The CIIF design-time components provide metadata services to the run-time CIIF and Built-In-Test-Environment ( BITE ). The CIIF run-time is a set of services, which enable semantic interoperability among healthcare trading partners. CIIF run-time services include data extraction, data translation, information-exchange mediation and BITE. BITE run-time services enable run-time performance and payload-data-integrity testing of iEHR’s ad-hoc trading-partners and plug-and-play applications. BITE uses CIIF MDHT generated Schematron, which is a rule-based validation language. CIIF relies on services, such as Identification, Authentication, Authorization, Access, and Secure Data Transport. An integration-architecture for semantic-interoperability requires common data content, common terminology and common data transport. Healthcare information stakeholders need “ working Interoperability ,” which is an instance of two “trading partners” –- human beings, organizations, or systems, successfully exchanging data or information and coordinating behavior to accomplish a defined task. Level 2 or Level 3 interoperability* may be sufficient for many tasks; while, clinical decision support systems generally require level 4 interoperability. In some cases, such as for bio-surveillance or research, large amounts of level 4 data may be required. * Levels of Interoperability [Center for Information Technology Leadership] 1. Viewable (e.g., paper based) 2. Machine Transportable (e.g., electronic form, such as PDF) 3. Machine readable structured messages with unstructured content 4. Machine interpretable structured messages with standardized content The advantage of the CIIF approach is that it decouples complex implementation schemas, allowing the agencies to choose when and how they upgrade their legacy systems to the EHRWF common GUI, common services, common information structure and common terminology approach. This is a practical path to DoD-VA consolidation, resulting in a single logical Electronic Medical Record for each patient. The approach is based on freely available national and international standards (e.g., SNOMED, LOINC, RxNORM) and allows the reuse and retargeting of existing components, supporting the transition of each agency’s Healthcare Information Technology. Common tools can centrally manage the accumulation of knowledge within the information and terminology models and services. As we go forward, the need for translation services is diminished for partners who elect to implement CIIF natively in their products. Note that there is always a need to harmonize different versions of terminologies, code sets and value sets, which evolve over time. Currently, we know the agency systems, their existing and required information exchanges** and a high level specification of the necessary EHRWF system functions and services (See the HL7 EHR System Functional Model (EHR-S FM)). We need to do simulations and appropriate prototypes to add fidelity to the Interoperability Specifications ( IS ), Performance Parameters and Independent Government Cost Estimates. Not only must we do this for the EHRWF final state; but also, we must simulate and appropriately prototype the legacy systems transition phases from the as-is state through a sequence of transition system states to the EHRWF final state. ** See “ DoD-VA Information Exchange Tool “ and “ DoD-VA Shared Standards Profile ”, maintained by the DoD/VA Health Architecture Interagency Group ( HAIG )
Sales Hint #XX: There is a difference between encounter and episode of care and yes, THM is assisting organizations in changing the clinical practice behaviour of its providers Why high cost, high risk - best hit
Sales Hint #XX: There is a difference between encounter and episode of care and yes, THM is assisting organizations in changing the clinical practice behaviour of its providers Why high cost, high risk - best hit
Will Patients want more accessibility and optimal quality of care; Health authorities recognize the need and benefits; Healthcare organizations are under constant pressures to treat more patients better under fixed budgets; Healthcare professionals grow more attuned to technologies and understand their value-add; Overall, there is a desire and a willingness to collaborate and participate. Capacity Infrastructures are being deployed and increasingly available. Networked application technologies are mature and proven. Capability ARRA mandated as a catalyst to support the creation of interoperable EHR solutions; Expertise exists in DoD-VA to create and deploy the solutions.
It is made up of: Mechanisms to find and uniquely identify people, providers and locations Patient-centric Electronic Health Record (EHR) Presentation solutions and intelligent agents Common services and standards to enable integration and interoperability Workflow and case management Decision support services Services to support health surveillance and research Services to ensure privacy and security Physical infrastructure to support reliable and highly available electronic communications
It is made up of: Registry systems to manage and provide peripheral information required to uniquely identify the actors and resources in the EHR. Specifically, these are patient/person, provider, the location, end users of applications, the terminologies used to describe diseases, acts or others. EHR domain repositories that manage and persist subsets of clinical data pertinent to the clinical picture of a client. A diagnostic imaging PACS solution is an example of a Domain Repository. A Longitudinal Record Service to coordinate the patient centric accesses, updates and location of data across multiple domains and registries. Standardized common services and communication services to sustain the privacy, security and overall interoperability of the different components within the infostructure, as well as to sustain interoperability and a high degree of abstraction between the EHR infostructure and the Point of Service (PoS) applications. Standardized information and message structures as well as business transactions to support the exchange of information in and out of the EHR; An EHR viewer as a generic presentation application allowing end-users to access, search and view relevant and authorized clinical data about clients
How does data get into the EHR? Data is pushed or published into EHR From source systems Viewing data in the EHR Generally from the applications the providers use in their daily context E.g. primary care doctor EPR applications have means to view and navigate the EHR Emergency room doctor from the hospital CDR and EHR
Speed Real-time on read requests: response time under 2 seconds Near real-time on updates Legal Assumption - Exchanges of clinical patient information between systems will be achievable at reasonable speeds while applying consent policies as part of privacy and confidentiality rules and regulations Scalable From growth in number of source systems From growth in point-of-care usage From growth in territory coverage From growth in surveillance usage From growth in administrative usage Reliable (High Availability) Redundancy: Power, Network, Servers (Application & Database), Disks Healthy economic balance in HIS vendor industry It is possible to maintain healthy business dynamics in the HIS vendor industry while insuring the uptake of a central source of EHR data in all regions;
Would it be a lot of work to add a few of the current projects to slide 19? E.g. JIC, and EDIS. Also, perhaps adding theater. While I know these are all in our minds, it may be good to call out some of the current ‘hot topics’ [Kevin Coonan]
Call me cynical, but I think this slide a bit optimistic. While I always found the CPOE on CHCS to be very helpful (seriously, once you knew how to use it, esp. if you had order sets turned on and well managed, it was fast*), I think that most people look at AHLTA and Essentris as “Gen 2”. [Kevin Coonan, 5 Oct 11] *When we get to CPOE, we need to provide an option for shell-like entry using the same syntax as CHCS. People who know this will appreciate the thought, and in the interim we can just use CHCS (eventually we will have to write our own command interpreter).
iEHR/CIIF 3-Tiered Architecture The iEHR architecture is a three tiered architecture with virtual integration layers of services between the “plug-and-play” applications and the Enterprise Service Bus (ESB) and between the ESB and the iEHR’s Federated/ Virtual database. iEHR Common Data implies native use of a single logical database, specified by the CIIF. Services within a standards-based component-architecture encourage lower-cost component innovation without requiring enterprise-wide expertise and extensive testing. Virtualization-Layers of Federated Standards-Based Services support alternate configurations of applications, databases and infrastructure, which may be combinations of COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities. CIIF canonical information and terminology models can be used to map among heterogeneous system information exchanges. By adopting common CIIF data, terminology, and communications standards; multiple organizations can share and ultimately harmonize Electronic Medical Records. Virtualization-Layers of Federated Standards-Based Services make plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeable-components can compete based, on functionality, quality, performance vs. cost, usability and supportability. Built In Test Environment (BITE) identifies faults early, improving robustness and reducing test costs. Component architecture localizes faults; BITE identifies faults early, improving system robustness, patient safety. Model-Driven Health-Tool (MDHT) defines run-time schematron test fixtures. Notional List of iEHR Applications Transient Outreach VA Rehabilitative Care VA Pharmacy Mail Order VA Nursing Home VA Long Term Care VA Profiling DoD En-route care DoD Battlefield Care DoD Registration Special Duty Programs DoD Disease Management Optical Fabrication Patient Education Disability Evaluation Blood Mgmt. Optical Ordering Laboratory Outpatient Orders Mgmt. Patient Education XML Forms Tool Radiology Ancillary Inpatient Orders Mgmt. Patient Self Reporting Documents Mgmt. Environmental Health Private Sector Global Image Access Data Access Dental Care Operating Room Mgmt. Medical Dental Forensics Patient Consent Tele-Consultation Genomics Situational Awareness DoD Alerts and Reminders Personal Health Record Registries Anesthesia Documentation Immunization Neurocognitive Assessment (NCAT/TBI) Emergency Dept. Care Patient Questionnaire Business Intelligence Inpatient Documentation Nutrition Care Consult and Referral Mgmt. Encounter Coding Outpatient Documentation Occupational Health VA Occupational Health DoD Patient Safety Reports Medical Logistics Anatomic Pathology Utilization Mgmt. Clinical Context Mgmt. Clinical Decision Support Inpatient Pharmacy Outpatient Pharmacy Single Sign On (SSO) Scheduling-Appointing Barcoding
NOTE: The database is not in the CIIF but in the Infrastructure Assumptions Will retrofit as capabilities come on line Mapping to legacy will occur Cost estimate for VA mapping of VistA instances is being revisited (Need to setup follow-on meeting in next 2 days Costs are dependent on roll out of capabilities and speed of implementation
Integration of these process REQUIRES a Common Information Model The CIIF enables the orchestration of runtime processes in line with contextual criteria From: David Bass [mailto:david.bass@jpsys.com] Sent: Saturday, August 13, 2011 9:34 PM To: Bishop, Robert J. (St. Petersburg Ofc) Cc: Bass, David C. (SMS) Subject: CIIF Pharmacy candidates My recommendations, from best to worst options, are in this order: 2b (allergies and advents events), 3 (execute interventions), 2a (drug and dosing checks), 1 (prescription transfer), and 4 (outpatient automation) last. Please take everything I’m providing as assumptions based on the material I’ve been exposed to so far; Pharmacy has a lot of moving pieces. Option 1 : Prescription Transfer In Description : Benefits : Proposed external Interface not currently in use in DoD or VA, and not mandated (NCPDP Prescription Transfer 2.0) Volume of business action likely low Could show intake of NCPDP transaction and content and build out of DoD/VA internal values needed to support subsequent internal business processes. Challenges: Need validation that the external interface expected is actually in use by DoD/VA trading partners. (only DoD deals with this at all today) Option 2a : Perform Pharmacy Order Checks (drugs and dosing) Description : A queued prescription is reviewed for validation issues, such as drug-drug interactions and dose range limits. In current-day DoD outpatient process, this includes a consolidated view of edits the prescriber encountered and resolved. Benefits : Can mimic and extend, or provide support to, functionality in PDTS and/or MOCHA Can potentially expand functionality over time, such as directly decomposing supporting documentation sent in formats other than NCPDP. May be able to provide common solution on CPOE side and Pharmacy earlier than otherwise. Do not have to take accountability for logic order checks just correct exchange and combining. Challenges: Interfaces may be greater than desired to address early on. It's not clear what considerations in the CPOE area are not accounted for. Once Inpatient or Clinic Administered Medications are included, this functionality supported must also be available as part of Medication Administration Option 2b : Perform Pharmacy Order Checks (allergies and adverse events) Description : A queued prescription is reviewed for validation issues that include the patients allergies and adverse events related to medication administration. Benefits : Would support an allergy service envisioned for use with the Pharmacy solution that would logically merge DoD and VA data for processing and presentation. Would have extended value as iEHR overall is developed. Terminology appears relatively mature Challenges: It would be ideal to expose this on the CPOE end at the same time, but that seems unlikely. Option 3 : Execute Intervention (External) Description : The Pharmacy make encounter an issue with the prescription or medication or as written and need to ask the prescriber to take action to resolve it. Alternately, at the time of administration, the care team may encounter a problem with the medication as dispensed and ask for intervention by Pharmacy. Benefits : The process does not appear to be supported electronically today (the exception being inpatient medication administration). There are no existing interfaces to disrupt, medication administration notwithstanding. There could be opportunities to alternate terminology used in Pharmacy setting versus clinical setting while retaining semantic interoperability. Challenges: Need to create interfaces where none exist. Addressing Pharmacy-to-Clinician and Care Team-to-Pharmacy at the same time could be challenging Option 4 : Outpatient Automation Communication Description : Pharmacy staff send commands to automation to allow dispense or preparation of a prescription. Some information comes back from the automation. Benefits : All of the interfaces are local No non-pharmacy interfaces involved Opportunity to take pharmacy content and convert it different automation interfaces Challenges: Interfaces may be unique per different devices/models David Bass VHA ESM Business Information Architecture Senior Information Architect (Systems Made Simple/JP Systems) e: [email_address] w: 209-544-1568 c: 530-701-0059
Note the calling out “Immunization ‘Registry’”. (I.e. registries are a by-product of having systematically defined information, not a separate project/software. Immunization registry, cancer registry, acute coronary disease registry, etc. are all just views into the data warehouse. That is one of the ‘features’ I would like to address. By having a real-time data warehouse (static data, optimized for query), we can off-load things like results retrieval, registries, etc. from our transactional system onto a more optimized platform. It also lets us use powerful analytic tools, which we can imbed into the eGUI. So rather than just being able to display someone’s calculated renal function (or creatinine) over time in a simple widget, we use one from an OLAP tool kit, so the user can drill down on values to see the rest of the labs, what the diagnosis at the time was, etc. I can think of dozens of applications for this, and it will be a major feature which I think people will love. We could set up a basic demo of some of my favorite packages (open source) if people want to see what we have been missing. [Kevin Coonan, 5 Oct 11]
Infostructure includes the design of solution architecture, the definition of standards, and the development of integration tools needed to ensure the interoperability of systems Registries are required to uniquely identify healthcare providers, clients/patients and locations of care Drug Information Systems enable physicians to view a patient's complete drug profile online, order a prescription electronically and receive notification of drug interactions automatically. Diagnostic Imaging Systems enable authorized health care providers to view online a patient's test images, such as MRI, and reports, regardless of where the test was conducted and from any location Laboratory Information Systems enable secure online viewing of patients' lab test results by authorized providers, regardless of where tests were completed Telehealth is the use of communications and information technology to deliver health care services over large and small distances, including remote and rural areas. Public Health Surveillance Systems will support the management and control of infectious diseases such as SARS.
Telehealth consultation applications typically involve two or more locations connecting dynamically so that multiple caregivers located in different places can interact through the use of ICTs (Information and Communication Technologies) to provide health services to a client. Telehealth consultation applications come in many different flavors and are all consider eligible from a technology perspective for funding. Telehealth applications will typically include: Basic multimedia computer hardware including casing, processor, RAM, large capacity hard disk, audio soundcard, microphone, screen, graphics adapters, backup devices, camera, second screen (optional) Specialized medical devices to conduct remote telehealth based delivery of service (vital signs, ECGs, diagnostic testing, etc…) Operating system and basic video conferencing software as well as software to interconnect specialized devices and computer Any case or medical record management software to help caregivers record telehealth session events and any relevant clinical data associated to them Internet browser for access to Integrated EHR Clinical Viewer Link to EHR: As EHR Infostructures get built, caregivers acting in remote locations will be able to access the health records of patients they care for from the remote community health centers where they practice. In the early days of the EHR, caregivers will be able to access health records information namely for patients that are provided acute and/or specialized care. Namely the patients traveling to access specialized care or testing procedures. Since the information available in EHR Infostructures in the beginning will mostly come from acute care settings as well as private and public labs and diagnostic centers, it is mostly the patients accessing these services that will have valuable information available for viewing. Telehealth applications, especially the software components as part of a telehealth workstation that handle records keeping, are likely candidates for integration to the EHR infostructure. This would allow telehealth based service delivery events to be recognized as part of the health event index maintained by an EHR for each patient and would also allow any relevant clinical information generated in these telehealth sessions to be recorded and available from the EHR of a patient.
Telehealth consultation applications typically involve two or more locations connecting dynamically so that multiple caregivers located in different places can interact through the use of ICTs (Information and Communication Technologies) to provide health services to a client. Telehealth consultation applications come in many different flavors and are all consider eligible from a technology perspective for funding. Telehealth applications will typically include: Basic multimedia computer hardware including casing, processor, RAM, large capacity hard disk, audio soundcard, microphone, screen, graphics adapters, backup devices, camera, second screen (optional) Specialized medical devices to conduct remote telehealth based delivery of service (vital signs, ECGs, diagnostic testing, etc…) Operating system and basic video conferencing software as well as software to interconnect specialized devices and computer Any case or medical record management software to help caregivers record telehealth session events and any relevant clinical data associated to them Internet browser for access to Integrated EHR Clinical Viewer Link to EHR: As EHR Infostructures get built, caregivers acting in remote locations will be able to access the health records of patients they care for from the remote community health centers where they practice. In the early days of the EHR, caregivers will be able to access health records information namely for patients that are provided acute and/or specialized care. Namely the patients traveling to access specialized care or testing procedures. Since the information available in EHR Infostructures in the beginning will mostly come from acute care settings as well as private and public labs and diagnostic centers, it is mostly the patients accessing these services that will have valuable information available for viewing. Telehealth applications, especially the software components as part of a telehealth workstation that handle records keeping, are likely candidates for integration to the EHR infostructure. This would allow telehealth based service delivery events to be recognized as part of the health event index maintained by an EHR for each patient and would also allow any relevant clinical information generated in these telehealth sessions to be recorded and available from the EHR of a patient.
Telehealth consultation applications typically involve two or more locations connecting dynamically so that multiple caregivers located in different places can interact through the use of ICTs (Information and Communication Technologies) to provide health services to a client. Telehealth consultation applications come in many different flavors and are all consider eligible from a technology perspective for funding. Telehealth applications will typically include: Basic multimedia computer hardware including casing, processor, RAM, large capacity hard disk, audio soundcard, microphone, screen, graphics adapters, backup devices, camera, second screen (optional) Specialized medical devices to conduct remote telehealth based delivery of service (vital signs, ECGs, diagnostic testing, etc…) Operating system and basic video conferencing software as well as software to interconnect specialized devices and computer Any case or medical record management software to help caregivers record telehealth session events and any relevant clinical data associated to them Internet browser for access to Integrated EHR Clinical Viewer Link to EHR: As EHR Infostructures get built, caregivers acting in remote locations will be able to access the health records of patients they care for from the remote community health centers where they practice. In the early days of the EHR, caregivers will be able to access health records information namely for patients that are provided acute and/or specialized care. Namely the patients traveling to access specialized care or testing procedures. Since the information available in EHR Infostructures in the beginning will mostly come from acute care settings as well as private and public labs and diagnostic centers, it is mostly the patients accessing these services that will have valuable information available for viewing. Telehealth applications, especially the software components as part of a telehealth workstation that handle records keeping, are likely candidates for integration to the EHR infostructure. This would allow telehealth based service delivery events to be recognized as part of the health event index maintained by an EHR for each patient and would also allow any relevant clinical information generated in these telehealth sessions to be recorded and available from the EHR of a patient.
Value Drivers: The settings along that continuum that contribute clinical information. The number of data domains included. The extent to which the information is accessible across the referral area. The referral area is determined by the unique characteristics and needs of the patient. The extent to which the data is normalized to a shared and agreed upon set of standards.
I think we may want to this slide to include: VAMC, MTF, hospital ship, MEDEVAC, field hospital, and Tricare community provider. [Kevin Coonan, 5 Oct 11]
I think we may want to this slide to include: VAMC, MTF, hospital ship, MEDEVAC, field hospital, and Tricare community provider. [Kevin Coonan, 5 Oct 11]
Longitudinal View Assumptions Care provider professionals recognize high value in having access to the longitudinal view of the clinical picture of a patient. Enough so to accept changes towards their use of HIS in every day practice of care. The foremosts benefits must be: Better information equal better decisions Saves time – more patient can benefit from care Reduces potential for error Reduces costs Value is tangible and high enough to enable change Care professionals Care organizations management and board of directors Shared across territories Assumptions Legal - State policies towards privacy and confidentiality (i.e. HIA) will be written in a way that does not prohibit cross-organizational use of clinical data; Adaptive to future - Assumptions Net new – Nation wide, region or state wide iEHR-CIIF do not currently exist in Canada or elsewhere in industrialized countries. Healthcare delivery constantly evolving: The future of healthcare in Canada incorporates more specialty care centres in large cities while maintaining high levels of service for rural populations. Expected growth of travelling patients, across regions, across states. Specialty care centres – localized expertise in specific domains Maintain high level of service for rural populations State of readiness of care providers varies greatly Internal interoperability enabled and evolving CDR in early adoption cycle The state of readiness towards integration and interfaces with a regional EHR varies greatly. We expect system interfacing solutions to be omnipresent and CDR solutions to still be in early adoption cycles by the time EHR is ready for mainstream deployment.
Summary only – 18 principles
Summary only – 18 principles
For the drill down slides (esp this slide) we may want to talk about some of the details about overall design. E.g. are we going to let individual apps (capabilities) do their own clinical decision support, workflow, order entry, etc. or are those going to be web services they have to call. I like the centralization of all of this (it is the only way to manage the complexity), but we need to be mindful of the performance implications, esp. if we are having these software packages use the eGUI, rather than their own. (If we centralize the workflow, rules-based expert system, complex event processing, data storage, information display, etc. one might ask just what these expensive software packages are still doing, but let’s leave that until we have some deployed). [Kevin Coonan, 5 Oct 11]
All of the various underlying “CIIF Services” exist to support three services: Encounter Management, Care Plan Service, Health Concern Tracking. Combined with the analytics, these are the pillars/legs of the chair, etc. of a longitudinal clinical information system. These are what healthcare providers do. We document encounters (episodes of care) and their associated procedures, we review data, we make treatment/diagnostic/preventative care plans, we make diagnosis and manage problems. These three services, plus analytics, is what most of the other clinical specialty services will be based on. Sure, the other services are going to be called some, but the bulk of what a cardiologist, neonatal intensive care nurse, paramedic or family physician do are done by these services. I think this provides a very powerful framework to design other services, but also to sell the design. These are core functions that clinicians and administrators can relate to, and they are the API which current legacy, future legacy, outside data, and new capabilities can all map to. If we want to move beyond the traditional paper-based mentality created by Larry Weed in the 1960’s, we have to socialize this approach. It changes how we will build the presentation layer (it now only needs to do four things!), and how we will, over time, stop needing to buy systems to get new capabilities. E.g. on this slide, the “Any Point-of-Service Application” could be reduced to four supporting services which provide a holistic view. In fact, since the three services I mentioned are just different views into the same information model (think of them as three RMIMs from the same DMIM), it really functions as the brokering service when taken as a whole. The sooner we specify (and get running) these services, the better. When you are able to tie the presentation layer to these three services and analytics tools the better. We will always need some sort of infrastructure for things like secure messaging, task management, schedules, and directory (like Exchange/Outlook--although there are better, and easier to work with, open source solutions we could repackage as healthcare specific tools), but I don’t see that as a detractor from the overall paradigm of what clinicians do. Plus, I don’t want to add a fifth (or more) leg to my chair! [Kevin Coonan. 5 Oct 11]
Key Terms and Concepts The components of computable data are an ontology of terms, an information model and a repository, as shown in the slide and discussed below. In VLER, this has already been done for HITSP/ C32 where the ontology is the clinical statement model from HL7 V3, the Information model is defined in the HITSP/ C83 and the payloads are defined by templates and Schematron. There is no repository in NwHIN. An Terminology Model (TM) is a formal representation of non-patient specific healthcare knowledge and clinical propositions represented as a set of concepts, called terms, and the relationships between those terms, often organized as hierarchies. Sets of terminologies may be mapped to alternate sets of terminologies or code sets. These terminology ontologies can be used to define Conceptual, Logical and Implementable Information Models, We plan to build a common terminology model for DoD and VA, based on SNOMED plus extensions, as discussed below. An Information Model (IM) is a non-patient specific structured representation of concepts, relationships, constraints, and rules, which may have associated operations, to specify data semantics for healthcare. An IM may be hierarchical and contains fields for discrete values; fields are defined in a data dictionary (e.g. HITSP Data Dictionary C154) and may be constrained to a value set or code set. An IM may be defined at the conceptual, logical implementable level of abstraction. We plan to build a common logical information model between DoD and VA, based on the Federal Health Information Model ( FHIM ). . A Repository is a database, where healthcare information is stored. A repository contains event-based instances of patient-specific data defined in a data dictionary and constrained by an IM. A repository’s physical schema is defined by logical information model. The DoD and VA plan to share a set of Virtual Remote Repositories ( VRRs ), with common database schemas. Another key logical IM output is the payload schema for information interchanges. To minimize mappings, the VRRs should be defined by the same Ontology, Concepts and Information model as defined for the message payloads.
Key Terms and Concepts Terminology Models (e.g., SNOMED CT, LOINC, RxNORM. CPT) specify standardized nomenclatures of basic concepts that would encompass an entire domain (e.g., human and veterinary medicine). As an example, SNOMED International provides &quot;cross-references&quot; and defines composite concepts by their elementary ones. Combinations of terms using &quot;linkages&quot; and &quot;modifiers&quot; termcodes from module G, also known as the SNOMED compositional properties, provide the flexibility to encode new or evolving medical concepts or the extensive nuances of typical medical observations. CIIF is founded upon SNOMED CT as an organizing framework and SNOMED CT RF2 format and structure for extension scheme (if IP restrictions allow) for other ONC approved standards, and for DOD and VA terminology content where appropriate. CIIF incorporates terminology standards, such as SNOMED CT, LOINC, RxNORM, CPT and common data exchange specifications managed by design-time Model Driven Healthcare Tools ( MDHT s), creating a metadata service, which supports a set of runtime services, which enable information interoperability among disparate sources and users.
Talking Point: Leverage HDD mappings/models to jumpstart DoD/VA model planning & development
As-is and Future State System Data Interoperability The CIIF is an architectural integration framework to define information and terminology models for a Joint EHR, which has semantic data interoperability. We recommend a comprehensive MSG-T (Models, Interchange Standards, Governance, and Terminology) approach. Additionally, the CIIF may provide non-standards based (e.g., custom) adapters to extract data from and load data to local systems. From an implementation perspective, the CIIF may be a logical grouping or orchestration of Enterprise Service Bus ( ESB ) services and system adapters. It should be noted that not only must differing terminology value sets and code sets be mapped; but also, evolving versions of those code sets and value sets must be managed and mapped (e.g., SNOMED, LOINC, CPT, ICD, MEDCIN are periodically updated). This requires that the content of a Common Terminology Service be maintained and managed. Historically, the DoD and VA shared information as shown in the slide. In this slide the legacy CHDR, BHIE and FHIE systems provide the transport mechanism between the Graphical User Interface ( GUI ), Services and Clinical Data Sources of DoD systems and comparable GUI, Services and Clinical Data Sources of VA systems, where: CHDR combines computable drug-drug interaction and allergies data. BHIE provides bidirectional remote data viewing. FHIE provides unidirectional DoD to VA remote data viewing at discharge. The CHDR, BHIE and FHIE systems provide limited information exchanges among a limited number of DoD and VA sites. The EHR Way Forward (EHRWF) initiative plans to move to a common GUI, common services and common information model and terminology as shown in the lower half of the slide. CIIF Boxes represent gateways on the security boundaries of each organization. The Common GUI and Common Services may reside in some new joint security domain (e.g., North Chicago or DISA Data Center). The EHRWF initiative, using the CIIF, will allow the retirement of the legacy CHDR, BHIE and FHIE systems and will allow appropriate computable information sharing with additional partners (e.g., St. Elsewhere in the slide). The CIIF architecture will be designed to comply with the DoD and VA information security requirements and take into account the allowable ports and protocols allowed to transition across the Information Assurance (IA) boundaries. Additionally; as DoD reacts to different IA threats, stricter Information Operations Condition (INFOCON) controls and restrictions will be imposed at the DoD IA boundary. At the highest INFOCON level, there is a possibility that all communications through the DoD IA boundary will be curtailed. The CIIF integration architecture design must take this into account.
Need a “walk-through” description “ Source Systems” to the CR not shown, but assumed to be primary or key point-of-service and claims/insurance systems Drug Info System Repository contains community pharmacy system client identifier numbers or its own internal client ID numbers in this scenario What is a “Clinical Portal”, and for what Physicians (hospital or community or both?)
here are all the other things that can and/or will need to be done to bring this vision to reality – this is where there is some real value for providers
Re: Focal Classes: The issue is less the idea of a focal class than a business focal class. The difference is that when you model the service, you are generally modeling a service that will express the state changes of a business. For example, via analysis, you would find the states of a business focal class (canceled, new, active, signed, finalized in lab orders for example) and the trigger events that would correspond to state changes (&quot;a lab is ordered&quot;, &quot;a lab is canceled&quot;, &quot;a lab specimen is corrupted&quot;, and so on). You could say that a &quot;patient&quot; is a focal class, but a patient ID service generally doesn't express operations to modify the state of that &quot;object&quot;. Rather, a patientID service would generally encompass operations that would express information about the class (reconcileID or lookUpID, eg) rather than tying the service functional components to changes in the state of that class. It is not a subtle distinction - most clinical domains are focused on a focal class (an order, an encounter, an appointment, a schedule, a lab). A business service is focused with exposing that class to the enterprise. Infrastructure services (or the subset information services) are generally function calls or based on exposing sets of information. The functional profiles of the service are generally not focused on the state of the underlying information or in the trigger events that modify the state of that information. They tend to be focused along different lines - typically along the lines of an information profile (a RIM-based patient class, eg, or a CDA-based CCD). The focal class is explicit in a business service, generally implicit in other services.
iEHR/CIIF Architectural Approach The EHRWF and CIIF architectural approach is to organize and manage architectural complexity with a set of constructs, best practices, processes, procedures and categorizations. The MHS-VA exchange architecture’s scope is the interoperability space between system components. Specifically, we must govern high risk areas and appropriately manage the interworking among distributed systems that may involve information exchanges or service interactions and state changes; Note that an Exchange Architecture is not an Enterprise Architecture. We will use the HL7 Service Aware Interoperability Framework ( SAIF ) to document interoperability specifications within our exchange architecture. SAIF combines four sub-frameworks, that together form a basis for defining comparable interoperability specifications (Information and Behavioral Frameworks) and formalizing governance and conformity assessment methods (Governance and Enterprise Conformance and Compliance Frameworks) critical to defining and using interoperability specifications. Specifically, the objective for DoD, VA and purchased care information exchanges is working interoperability. Working Interoperability is “just enough interoperability” for effective information exchange among humans and software components, where all the entities must work together. WI is the unambiguous, predictable, system-mediated exchange of data and/or the coordination of inter-component behaviors. The biggest impediment to working interoperability is implicit assumptions . Working Interoperability depends on effective relationships among the enterprise business perspectives, information perspective (static semantics), computational or behavioral perspective (dynamic semantics), engineering and technology perspectives. The static semantics of the information perspective and dynamic semantics of the Behavioral perspective are necessary; but not sufficient conditions for “Working Interoperability”. WI requires the addition of the enterprise perspective to include the roles, processes, and policies and their traceability to the Information perspective and Behavioral perspective. Governance adds decision and risk management processes. Governance also adds assessment and configuration management (CM) baselines to support the business capability lifecycle. The value proposition of effective WI is having auditable configuration management baselines of well-defined layered interoperability specification with explicit conformance criteria resulting in certifiable levels-of-conformance and traceability. HL7’s SAIF organized these perspectives into an Enterprise Compliance and Conformance Framework ( ECCF ) defining working-interoperability specification-baselines at decision points to determine omissions, risks, and the possible degree of automated interoperability and the difficulty of the transformations that may be required to enable working interoperability. An enterprise architecture (EA) is a rigorous description of the structure of an enterprise. EA describes the terminology, the composition of subsystems, and their relationships with the external environment, and the guiding principles for the design and evolution of an enterprise. This description is comprehensive, including enterprise goals, business functions, business process, roles, organizational structures, business information, software applications and computer systems. Service Aware Interoperability Framework (SAIF), available at http://hssp.wikispaces.com/HL7+SAIF and http://hssp.wikispaces.com/PracticalGuide
Notional CIIF Design-Time Use Case (set of related Scenarios) SCENARIO 1: Add an allergy term to SNOMED CT Dr. Dolittle wishes to add a new allergy concept to the local terminology model. Dr. Dolittle submits a terminology change request to the CIIF Data Board The CIIF Data Board approves the request. Dr. Dolittle submits the new allergy term to SNOMED. Some time later, SNOMED issues a new version of its terminology set, including the new allergy term. The updated SNOMED CT terminology set is installed in the DoD-VA CIIF SCENARIO 2: Dr. Dolittle wishes to get the information and terminology models related to immunizations. SCENARIO 3: A requirements management analyst is preparing a set of capabilities package for the ICIB and needs the data models for each new capability. HELP NEEDED ON GOVERNANCE SCENARIO TO-GO-WITH OR INTEGRATED-WITH DESIGN-TIME SCENARIO Governance We need scenarios to describe how change requests are processed, who prepares and submits budgets, who distributes funds and who reallocates funds when cuts occur.
Services Provided by CIIF Translation – syntactic and semantic data harmonization using standard information models and SNOMED CT and extensions as the CIIF conical terminology and iEHR data stores’ native terminology. Syntactic field mapping and conformance Semantic terminology mediation and value normalization Mediation - a mediation service can handle the transformation from one information-exchange payload-format and transport to another. Built-In-Test-Environment (BITE) - for run-time information-exchange integrity-checking. Common Terminology Services 2 (CTS2) - CTS 2 terminology services Metadata Service – provides information schemas and terminology bindings Services Used by CIIF Identification – Who are you looking for ? Authentication – Who are you ? Authorization – What are you allowed to know or do ? Secure Data Transport - Standards-based information exchanges. RLUS - Retrieve, Locate, Update Service Rules Service – A business rule service enables policies and other operational decisions to be defined, tested, executed and maintained separately from application code. List of strongly CIIF-related foundational capabilities [Mike Lincoln, 8/10/2011] 1. Terminology authoring &quot;workbench&quot; (tooling suite) a. Will use the International Healthcare Terminology Standards Development Organization (IHTSDO) Workbench b. Provides mechanism to author terminology content in parallel using multiple, physically separated experts; provides quality control of authorship c. Provides a central gold-standard central database of terminology content 2. Run-time terminology databases; these are accessed by actual applications a. Distribution/replication mechanism populates run time terminology databases from gold standard central terminology database b. Can exist in regional (e.g., VISN 19), local (e.g., Salt Lake City VAMC), and sub-local forms (e.g., blade server for instantly available, high performance drug terminology services confined to SLC outpatient pharmacy) 3. Common terminology services (CTS) a. Used by gold standard and run-time terminology databases to serve application queries b. Examples of CTS 2 API: &quot;get concept description by keyword&quot; (e.g., physician query to problem list), &quot;get parent concept&quot; (e.g., for data aggregation of entered problems), &quot;get code by concept description&quot; (e.g., get medication codes from medication reconciliation process, pass codes to decision support algorithm for drug-drug-interaction checking). 4. Metadata repository services (e.g., ISO/IEC 11179 compatible) for storing terminology and template metadata a. MDR stores information about the terminology and model standards, but not the actual terminology or models themselves b. MDR are used to organize top-level data about terminology for use by developers, others (e.g., registry developer wants to answer &quot;what code sets should I use for describing patient problems in the spinal cord injury registry?&quot; &quot;How do I access those codes (location, valid API)?&quot; etc) 5. New Term Rapid Turnaround (NTRT) business processes and infrastructure services a. Field submissions are formatted, specified, rolled up, and then finally distributed to central authoring teams b. Authored new or changed content is distributed to run-time terminology databases (a la item 2 above) 6. Repository and authoring suite for Detailed Clinical Models a. Models vs terminology: blood pressure = concept 12345 and systolic cardiac cycle notation = concept 23456; however the model for systolic blood pressure is a controlled and expert-defined combination, namely, blood pressure (12345) has cardiac cycle (23456). b. Will use combination of current Federal Health Information Model (FHIM) tooling and HL7 Detailed Clinical Modeling tools List of CIIF related services and capabilities that may fall primarily under other categories or workgroups: 1. Identity management (would need terminology elements, but probably handled by another group) 2. Analysis and analytics a. Authoring system for analytics and decision support b. Repository for authored decision support c. Run time analytics engine(s), rules engines, etc. 3. Data warehouse (so-called XDR) a. This is a very big thing that will use CIIF services extensively but is not itself CIIF b. Reconnecting legacy applications to XDR is a very expensive and time-consuming effort. NIST 7497 Security Architecture Enabling Services Risk Assessment is a Security and Privacy Principles, which means to identify security and privacy risks to HIE operations based on threats, assets, vulnerabilities, and likelihood of threat success. Entity Identity Assertion (Authentication) is HITSP Construct * SC110 & C19, which ensures that an entity is the person or application that claims the identity provided. Credential Management is a Security Principles, which means to manage the life cycle of entity credentials used for authentication and authorization. Access Control (Authorization) is HITSP Construct * SC108 & TP20, which ensures that an entity can access protected resources if they are permitted to do so. Privilege Management is a Security Principles, which means to manage the life cycle of an entity’s authorization attributes (e.g., roles, permissions, rules) for making access control decisions. Collect and Communicate Audit Trail is HITSP Construct * SC109 & T15, which defines and identifies security-relevant events and the data to be collected and communicated as determined by policy, regulation, or risk analysis Document Integrity is HITSP Construct * T31, which validates that the contents of a document have not been changed in an unauthorized or inappropriate manner. Secured Communication Channel is HITSP Construct * SC109 & SC112, which ensures that the mechanism through which information is shared or transmitted appropriately protects the authenticity, integrity, and confidentiality of transactions to preserve mutual trust between communicating parties. Document Confidentiality is a Security Principles, which means to prevent the unauthorized disclosure of a document that is exchanged or shared. De-identification is a Privacy Principles, which means to remove individual identifiers from a health record, or replace them with other information such as pseudonyms, so that it cannot be used to identify an individual. Non-Repudiation of Origin is HITSP Construct * C26, which provides the proof of the integrity and origin of data in an unforgettable relationship which can be verified by any party. Manage Consent Directives is HITSP Construct * TP30, which ensures that individually identifiable health information is accessed only with an individual’s consent. * HITSP constructs are available at www.HITSP.org
Notional iEHR/CIIF Run-Time Scenario Dr. Dolittle uses iEHR to document an encounter with Pat. PAT is sent to Quest for a special laboratory test. Dr. Dolittle asks Pat to update his demographics on PHR. PHR sends updated PAT demographic information to iEHR. Quest sends a lab results message to iEHR. iEHR sends a consult request message to St Elsewhere. St. Elsewhere sends a clinical summary request message to iEHR. iEHR gets EMR from one-or-more legacy VistA systems. iEHR gets EMR from legacy ALTHA CDR. iEHR gets previous lab results from one-or-more legacy ALTHA/CHCS II system. iEHR sends a clinical summary document to St. Elsewhere. St. Elsewhere sends a “Consult Results” message to iEHR. iEHR/CIIF 3-Tiered Architecture The iEHR architecture is a three tiered architecture with virtual integration layers of services between the “plug-and-play” applications and the Enterprise Service Bus (ESB) and between the ESB and the iEHR’s Federated/ Virtual database. iEHR Common Data implies native use of a single logical database, specified by the CIIF. Services within a standards-based component-architecture encourage lower-cost component innovation without requiring enterprise-wide expertise and extensive testing. Virtualization-Layers of Federated Standards-Based Services support alternate configurations of applications, databases and infrastructure, which may be combinations of COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities. CIIF canonical information and terminology models can be used to map among heterogeneous system information exchanges. By adopting common CIIF data, terminology, and communications standards; multiple organizations can share and ultimately harmonize Electronic Medical Records. Virtualization-Layers of Federated Standards-Based Services make plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeable-components can compete based, on functionality, quality, performance vs. cost, usability and supportability. Built In Test Environment (BITE) identifies faults early, improving robustness and reducing test costs. Component architecture localizes faults; BITE identifies faults early, improving system robustness, patient safety. Model-Driven Health-Tool (MDHT) defines run-time schematron test fixtures. Draft Software Development Kit (SDK) Specifications are needed by Fall 2011 * Built-In-Test-Environment (BITE) Service Specification to support automated fault-detection resulting from distributed ad-hoc partners & plug-and-play applications. Model-Driven Health-Tool defines run-time schematron test fixtures. Performance-Monitoring-Component Service-Specification to trace run-time execution pathways and measure latency to support, system tuning, automated testing and certification. Code-Coverage Regression-Test and Stress-Test Tool-Specification , to support automated testing and certification of “happy path” and fault recovery pathways. Cross-Reference Tool-Specification to automatically map module-module and module-data dependencies and certify no unexpected changes. Pretty-Printer Tool-Specification to certify software-module Standards and Conventions ( SAC ) & to do syntax verification and readability reformatting. SAIF ECCF Implementation Guide (IG) for documenting component Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification. SAIF ECCF Tool Specification to manage module Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification. ESB Services Specification of iEHR Tier 1-2 Application Virtualization-Layer of federated standards-based services. Database Services Specification of iEHR Tier 2-3 Database Virtualization-Layer of federated standards-based services. Standards and Conventions (SAC) , updated to modern SOA software engineering practices, as defined by Thomas Erl.
Health Information Systems’ essential value comes from data and its intelligent re-use. The slides show an information model within an Interoperable Electronic Healthcare System ( iEHR ) with a Common Information Interoperability Framework ( CIIF ) component. CIIF can be shared between partners; it is made up of design-time information models, which define the run-time structure and computable meaning of the information exchanged, managed, and/or stored. It includes services such as a Meta Data Registry ( MDR ) and Common Terminology Service ( CTS ). Health care is data intensive and without standardized terminology health data is generally poorly re-usable; that is, it is only readable but not computable. Just because healthcare data is captured in an electronic format does not mean that it is computable, can be effectively retrieved when needed, or can safely be used without significant risk of error. For information to be computable (and therefore useful in decision support or secondary analysis) it must be discrete, structured and typed. CIIF defines information models and a data-concept dictionary of detailed description of all of the types of data elements used plus the context-sensitive attributes and relationships of those elements. CIIF defines the use of controlled clinical terminologies as part of these models and CIIF includes additional services useful for translation and transformation of legacy information. CIIF can assure syntactic and semantic information interoperability, while supporting privacy (e.g., right to not disclose), confidentiality (e.g., promise to maintain control of information) and security (e.g., a mechanism that assures safety from unauthorized information disclosure) constraints. “ iEHR Common Data ” implies native use of a single logical database, specified by the CIIF.
Service Aware Interoperability Framework (SAIF) Meta-Model Canonical Definition (CD) defines a minimal set of common concepts and properties, including terminologies, ontologies, and technology neutral constructs, from which conformant SAIF Implementation Guide (IG) models can be defined that support a number of different technical approaches to interoperability, e.g. messages, documents, or services. A SAIF IG thus adopts and defines modelling languages and document artefact templates complaint with the concepts and properties defined in the SAIF CD.
We will stop at Information Meta-Model and not add additional confusion and non-essential data and terminology related details to the discussion; although, the detailed definitions are included in the glossary. As a simplifying assumption, assume there is no difference between a controlled clinical terminology, vocabulary, code system, and reference terminology. In defining Detailed Clinical Models (DCMs), the big distinction one might make is between those terminologies which are based on ontological/ logical principles (DL-based reference terminologies) and otherwise suitable for use in a clinical information system (e.g. SNOMED-CT, HUGO, NDF-RT), those which are simple lists of concepts/ terms (the simple case of a vocabulary), and those which are classification systems that lack the required properties for use in clinical systems/EHRS (e.g. ICD-9/10). ICDs are “statistical classification”, where the categories are designed to support statistical reporting, rather than patient care. What is important for a terminology is that it is consistent between and within systems, has consistent meaning over time, and has deterministic (computable) meaning. Humans understand the terms, which are a single concept to many terms mapping (synonyms). Definitions which make for a good reference terminology (i.e. DL intensional) do not always make for good human readability. Most of us agree that LOINC is a “reference terminology”, but it is only ‘well formed’ for a subset (lab), and is little more than a coded list of human terms (and violates both good terminology practice and even its own rules) in places. That doesn’t preclude it being useful. The big question we need to address Is how to augment SNOMED-CT {e.g., use NUCC Provider Taxonomy as translation for provider type, SNOMED-CT as translation of RxNorm in medication management, LOINC/SNOMED-CT together for Observations, LOINC for documents} and how should we use SNOMED-CT for Observation events, Substance Administration event, Procedure events, Encounter events, Supply events, Documents, and various specializations (ObservationRequests (e.g. lab and other diagnostic study orders), Procedure Requests, Supply Requests, Substance administration requests, Observation goals, Observation risks, Health Concerns and Care Plans) {Finding with Explicit Context, Procedure with Explicit Context, use compositional grammar in instances where all messages/models are either decomposed into a semi-normalized form, or use a fully defined pre-coordinated code/extension—the key is that you don’t have a value set that has some partial enumeration with pre-coordinated codes, and some expressions, and is otherwise ‘messy’—we need to pick a single paradigm and stick to it, being sure that the various options allowable for post-coordination are explicitly defined for each instance Glossary A Class is a collection of attributes that pertain to a specific encapsulated concept. For example a person can be described by a set of attributes that are always reflective of fixed properties of a human being. The properties include a date of birth, a genetically determined gender, a race to which the person belongs and an ethnicity that reflects an ancestral population group. All of these attributes are expressed in data types and collected into an information structure called a class that can be used as a component of larger information models. Classes have relationships to other classes and there are relations that are monotonic (1:1) or relations that are open ended such as 1: many or 0: many. Information models are built from these classes and their relationships to other classes that form increasingly complex concepts. A Concept is an abstract thought about a thing, or things, in the world. It the basic unit of communication and each concept represents an atomic unit of thought that references a concrete or abstract thing; a concept is the basic unit of data used in information exchanges. Concepts can be expressed in a number of ways, such as verbal, symbolic, textual or coded. Once a concept expression is agreed upon it can be used for the purpose of interacting with trading partners that need to share information. In verbal communication of terminological concepts, the spoken language must be known by the communicating parties as well as the dialect and inflection in some cases. Often times those terminological concepts may have multiple meanings depending on the context in which they are used, even when the spelling in a given language is identical; therefore, the textual representation of a concept is inadequate to completely provide the meaning of a term when it is separated from its context of use. Information systems depend on an explicit and unique meaning of a concept and hence cannot rely on verbal or textual representations of concepts; considering that, textual representations may be misspelled, abbreviated, or expressed in a different language with different spellings. Pre-coordinated concepts are composed of two-or-more primitive concepts, within a concept dictionary or terminology set. Post-coordinated concepts are composed of two-or-more concepts by users, from within a concept dictionary or terminology set. When used, post-coordinated conditions avoid the need to create large numbers of Defined Concepts as within SNOMED. However, many systems only use pre-coordinated conditions. As an example, with respect to those concepts already within the SNOMED CT release dataset and any other ad hoc concepts created by its community of end users - properly requires the application of an appropriate description logic classification algorithm. As of 2007, SNOMED CT content limits itself to a subset of the EL++ formalism. Primitive concepts are the simpler components of pre- or post-coordinated concepts. Data is the raw material from which information is derived. In order to allow information systems to use data to address most healthcare use cases, we must first convert it to information by defining its context with associated meta-data. A Data Type is a data storage model or template that defines the attributes for a specific type or range of values. It acts to formalize the requirements for data of specific types so that all of the attributes needed to process the data are known by a receiver. Simple Data Types are where the attributes of the data type each hold only a single data value (primitive types). Complex Data Types are where the attributes may hold a pointer (e.g., association) to other data types that hold the actual data values. In an implementable information model a complex data type is usually a composite of other existing simple and complex data types (e.g., complex data types are links amongst database schemas). For example, you might create a complex data type whose components include Nominal, Ordinal, Quantitative data types or other complex types. An important advantage that complex data types have over “encapsulated user defined simple data types” (e.g., attribute address = <number, street, city, state, zip> is that users can directly access and manipulate the individual components of a complex data type. Consequently, in a database environment, the only way to access the component values of “encapsulated user defined simple data types” is through functions that are define on the “encapsulated user defined simple data types”. Data Type Flavors or Data Sub-Types are constrained Complex Data Types which have a mechanism to define an abbreviated set of attributes which may be sent so that a processor can still validate the contents of the constrained type without requiring all attributes to be populated. In this way a single data type definition can satisfy multiple use cases. As an example. INT.POS : Constrained to positive integers. Value must be >= 1. Canonical Data Types are a set of data type categories, such as Nominal, Ordinal, Quantitative, Narrative Text or Binary Data Types. Nominal Data Types express a categorical response that does not have a natural ordering. This includes names of entities or simple observations of natural phenomenon such as color. Ordinal Data Types express concepts that have a natural order. Examples of ordinal values include grades such as A-F and sizes such as small, medium and large. Quantitative Data Types include numerical values expressed as ratios, integers, real numbers or ranges that have a mathematical interpretation. Narrative Text Data Types are used to express descriptions in natural language. Binary Data Types, aka “Image Mime” in an e-mail context, are binary data image information that are typically symbolic to human interpretation but may be processed by machines as digital data. Examples are radiology images, digital wave forms and gel electrophoresis patterns. Filler is a reference set of semantic types for an attribute of the abstract information models such as Conceptual or Logical Information Models. With fillers, it is inappropriate to define specific codes or code systems from which these semantic types might originate. This is so that the Conceptual or Logical Information Models maintain maximal reuse capability and subject matter expert familiarity. Being able to refer to a semantic type as the appropriate concept group for an attribute allows a domain expert to provide requirements in their language and allows a terminologist, downstream in the development process, to assign appropriate code-system content to that abstract semantic type. Information is &quot;data-in-context&quot;. It is the context of data and its unambiguous organization into a hierarchy of information models that contributes to the properties of semantic interoperability when shared among information systems. For information to be computable (and therefore useful in decision support or secondary analysis) it must be discrete, structured and typed. An Information Exchange (IE) is when data is exchanged between trading partners, there is a requirement for describing an information model (IE static semantics) and behaviour model (IE dynamic semantics) about the data and how the systems will move the data over the connections between them. A particular information model describes the data available for transfer, but need not define the specific data available in a single payload. In fact, it is most appropriate to have data modules (e.g., demographics, problem list, medications), which are reusable models that fit a well-defined and compact information requirement (archetype or DCM). In IT systems this provides flexibility and reuse to the information exchange interface. As an example, one may want to have a model for an interface (e.g., clinical summary) that can constrain its information model to the demographic data about a person. This interface can then be used in multiple ways because it is loosely coupled to the underlying information model from which it was derived and to the information model in which it will be consumed. Levels of interoperability can be associated with information exchanges*. The minimum goal of an information exchange is to enable Working Interoperability (WI); where, Working Interoperability aka Shared Purpose is an instance of two “trading partners” –- human beings, organizations, or systems, successfully exchanging data or information, or coordinating behaviour to accomplish a defined task, or both. The biggest impediment to WI is implicit assumptions. WI for lab results to a clinician may only require level 2 or 3 interoperability; while Epidemiological studies, decision support systems and research generally require level “4” full semantic Interoperability. FOOTNOTE : * Levels of Interoperability [Center for Information Technology Leadership] 1 - Viewable (e.g., paper based) 2 - Machine Transportable (e.g., electronic form, such as PDF) 3 - Machine readable structured messages with unstructured content 4 - Machine interpretable structured messages with standardized content An Information model represents a collection of concepts modeled as classes and the instantiated relationships between those classes. The instantiated relationships may be classes themselves in more complex modeling methods (e.g., metadata). The relationships are reflective of a specific domain or context of discussion. In other words, the relationships between classes are not static from information model to information model; but, relationships may change depending on what behavior (or larger concept) the model is expressing. Information models for a given domain may be subdivided into small, reusable sub-models. This is a useful way to provide consistency of class relationships that are common across information models. An example would be the physical address class relation to an entity class which is always a static relationship since a physical entity always occupies some physical location. There are many examples of the small, reusable models in healthcare modeling; they include archetypes, common message element types, and detailed clinical models among others. Information models may be built in a number of ways, though the effort to derive semantically consistent models may be partially dictated by the methodology of information derivation. One method is through constraint of an abstract class that contains a superset of all attributes of a class type. Another method might be through specialization of a class where the parent class has only the necessary and sufficient attributes to define that parent and the children classes add attributes to define specialization of the parent class. Finally , there is the ad-hoc building of an information model, where attributes are added to a class based on empiric analysis of a domain of discourse. Information Models are often categorized into Conceptual, Logical and Implementable information models, which may be considered as perspectives. Perspectives are roughly equivalent to levels-of-abstraction, but are more correctly viewed as role-based Perspectives (i.e. views from the perspective of SMEs and “outward-facing analysts,” (Conceptual Perspective), architects and “inward-facing analysts” (Logical Perspective), and developers and designers (Implementable Perspective). A Conceptual Information Model (CIM) is an abstract model, which may not define attributes and when it does define attributes, does not define specific codes or code systems from which semantic types might originate. CIMs maintain maximal reuse capability; because, CIMs are able to refer to a semantic type for attributes. This allows a domain expert to provide requirements in their language (e.g., define a notional value set) and it allows a terminologist, downstream in the development process, to assign appropriate value sets or code-system content to each abstract semantic type. A logical Information Model (LIM) is a “ design time ” representation of a domain's data, organized in terms of entities modelled as classes and relationships and may be independent of any particular terminology or implementation. LIMs can be abstract where the classes may have optionality to the classes they are related to and the terminology may not be set to bindings of specific values. These abstract models can be used to define information requirements from which more specific constrained information models are derived. For a specific run-time environment LIMs are used to generate IIM instances. An Archetype or Detailed Clinical Model (DCM) is a complete reusable component models for a universally-understood concept (e.g., symptom, Blood Pressure); it can be a Logical-Information-Model component, which is an abstract prototype from which more complex Archetypes/ DCMs or LIMs are composed or aggregated. There is a difference in Archetypes and DCMs; although, they both convey the associated clinical data elements. ISO13606 and openEHR Archetypes are defined in Archetype Definition Language ( ADL ), and have nothing to do with HL7. In HL7, a DCM is a specification of static-semantic clinical-content expressed as a set of consistent constraints upon the HL7 V3 Clinical Statement Pattern. The goal of HL7 DCMs is to provide *consistent* static semantics for the structured clinical content in Clinical Document Architecture ( CDA ) r3, services and for V3 messaging. For example, the “Abstract Symptom” DCM will need to be combined (i.e. a derivative template) with the “Abstract Clinical Finding Temporal Series” DCM to create a “History of a Complaint over Time” DCM. The Federal Health Information Model (FHIM) is a comprehensive, integrated, logical, health information model and associated terminology model(s) to support health interoperability, especially semantic interoperability. The FHIM is built by harmonizing information from the individual Federal partners and from standards organizations; the HL7 Reference Information Model ( RIM ) is leveraged for the FHIM; but, the FHIM is not directly derived from the RIM. The VHA Health Information Model (VHIM) is the authoritative enterprise information model for Veterans Health Administration (VHA), representing the structure and content of all shared information that is exchanged across the enterprise. The VHIM complements the Standards and Terminology Services (STS) program through classification and representation of data elements and their relationships, representation of data element types and incorporation of appropriate terminology. Together, the VHIM and the STS Program ensure that a single meaning and structure is defined for shared information, furthering consistency in information representation and understanding. An Implementable Information Model (IIM) aka Physical Information Model is a “ run-time ” implementation-specific information model representation of a domain's data, organized in terms of entities/classes modeled as schemas (e.g., template) and specific relationships and is bound to a particular terminology and implementation technology. Metadata is the appropriate set of descriptors to understand the context of concepts. As an example, in a longitudinal lifelong medical record, value set metadata should include sufficient descriptors to resolve the exact value set membership at a given point in time, such as, the value-set-version used when the user submitted data. Terms are words describing ideas, concepts or things, e.g. “dog” (preferred English term), which may have alternate designations, e.g., “hund” (German) or “canis lupus” Terminology is a set of terms/ concepts/ codes in a specific subject field (e.g., domain) whose meanings have been defined or are generally understood; Terminology defines how concept metadata is described and what, if any, rules can be applied to the concepts to create more complex concepts out of simpler concepts. The purpose of a terminology is to provide a clear and unambiguous way to describe concepts so that two or more individuals can gain a shared meaning of those concepts (e.g., working interoperability). Terminology MUST be able to distinguish when two items are the same and terminology SHOULD be able to distinguish precisely how non-identical items are similar. The concepts/ terms that are characterized by special reference within a discipline are called the terms of the discipline and collectively form the Terminology . Terms that function in general reference over a variety of languages are simply words, their totality is a Vocabulary . Vocabulary defines the meaning of data – i.e. changes data to information through instantiation of semantic rules; a terminology (structured vocabulary subset) is composed of concepts along with synonymous terms , properties and various relationships (e.g., Taxonomy is-a, Partonomy part-of, Etiology caused-by, Therapy treated-by, Position located-in). A “ Vocabulary ” is a set of terms in general reference , e.g., “medical vocabulary” (more colloquial and less precise). A vocabulary and terminology are approximately equal terms. From the point of view of messaging/interfaces/data persistence/rules. A Coding System or more simply, a Code System is a collection of codes with associated designations (e.g., concepts or terms) and meanings in a particular terminology. A Semantic-Type Code-System is a category for an item or group of items (concepts in our case) that all share a similar meaning (semantics) as defined for that group; it is a set of concepts that describe like or similar concepts. Semantic types can be used to distinguish the use and purpose of different items in the group. Examples of semantic types taken from the National Library of Medicine’s Unified Medical Language System (UMLS) include virus, fungus, laboratory test and professional society, all placed into a hierarchical structure. Examples of semantic-type code-systems that contain concepts of a single semantic type include the CDC Vaccines Administered code system (CVX) and the Standard Occupational Codes (SOC) code system that defines occupational categories. Complex -Semantic-Type Code-Systems have many semantic types defined in non-overlapping subdivisions. The prime example is SNOMED CT where top level categories include products and geographical locations as well as clinical findings or procedures. A Classification is a terminology that is hierarchically arranged (Greek: taxis = arrangement); where A taxonomy is a hierarchy of concepts, usually with a single parent for each (child) concept; usually no other relationships, and focus is on classification, e.g. species of an organism. A strong taxonomy has consistent semantics for parent-child “has-a” relationship; while a weak taxonomy does not. a Subsumption Hierarchy is an organization of terms into types, subtypes, sub-subtypes etc. for the purpose of making generalizations and specializations explicit. A Controlled Terminology (model) provides the organizational framework for concept ordering, inheritance and rules that govern the use of the concepts. A controlled terminology is most applicable to metadata or other data intended for searching. In short, controlled vocabularies reduce ambiguity inherent in normal human languages where the same concept can be given different names and ensure consistency. As an example, the 3M Health Data Dictionary uses Numeric Code Identifiers (NCIDS) to organize multiple terminologies (e.g., SNOMED, CPT, ICD). Dr. Jim Cimino in his Desiderata described several rules that a sound controlled terminology should adhere to. These include vocabulary content, concept orientation, concept permanence, non-semantic concept identifiers, poly-hierarchy, formal definitions, rejection of &quot;not elsewhere classified&quot; terms, multiple granularities, multiple consistent views, context representation, graceful evolution, and recognized redundancy {Cimino, 1998 #94}. Computers can analyze their built in types (Boolean, byte, integer, floating point), ordinal (ordered) data, categorical data, or using a symbol/code system with well specified hierarchies and associations (a controlled clinical terminology or vocabulary based upon sound practices). In addition, the information must be conveyed within the context of a model of meaning--the structure which relates the various aspects (attributes) of a data element (class) to itself, and to others (associations). The model defines what the name and data type of attributes are, what relationships are allowed, as well as the cardinality and allowed value ranges. Only when properly modeled data is conveyed with its proper context does it become information. DL-based (Reference) Terminology is a high quality controlled terminology, where each concept has a formal, logical definition, usually provided by an ontology, which is consistent between and within systems, has consistent meaning over time, and has deterministic (computable) meaning. The objective of a DL-based Reference Terminology is to be widely used, where the meaning is useful, able to be communicated-to and understood-by many average health care providers without reference to inaccessible, hidden or private meanings. SNOMED CT and NDF-RT are DL-based reference terminologies, while ICD-9 CM, ICD-10 and ICF are only taxonomies because they only contain hierarchical relationships and some are logically contradictory. LOINC is an example of an authoritative-type-of-reference but neither taxonomy nor DL-based reference terminology although it can be converted into a DL-based terminology. Unfortunately, “Reference Terminologies” are commonly used as ill-defined jargon; most listeners think &quot;authoritative&quot; when they hear &quot;reference&quot;, which is not what, is meant. “Reference terminology” is sometimes used in the sense of &quot;terms we refer in an accepted list&quot; like ICD-9 or the VA National Lab File. Even the use of good terminology practices (e.g. UUID identifiers instead of hierarchical numbers with meaning) doesn't make a DL-based reference terminology. Descriptive Logic (DL)’s, intensional knowledge is represented as a taxonomy using a so-called concept language as a representation method. A concept language is in fact a limited variant of the First Order Predicate Language. DL is more expressive than propositional logic but has more efficient decision problems than first-order predicate logic. Intensional logic is an approach to predicate logic that extends first-order logic, which has quantifiers that range over the individuals of a universe (extensions), by additional quantifiers that range over terms that may have such individuals as their value (intensions). The distinction between extensional and intensional entities is parallel to the distinction between sense and reference. An Interface Terminology assists entry and display of information and provides consistent data entry – (link to legacy data); but, does not meet the requirement for data retrieval based on implicit meaning. Example: Alternative designations mapped to a reference terminology or may be contained in reference terminology. Ontology, in the ‘usual’ use, is a purpose driven systematic representation of domain concepts (terms, identifier) and their relationships to other concepts; unfortunately, ontology is a term of jargon that has no consistent definition when considering divergent uses in computational linguistics, knowledge-based systems, and related fields. In some uses, an Ontology is equivalent to a description-logic based system for representing concepts for a given domain (possibly equivalent to a DL based reference terminology). In other cases, Ontology is strictly encoded using language, rather than description logics. In this case, an Ontology is a concept map of terminology which, when richly populated, reflects all the possible semantic relationships that might be inferred from different ways that terms are assembled in human language. A subject specific ontology is more easily understood in a graphical representation. Ontologies also help to inform semantic search engines by contributing to an automated deconstruction of a query (making sense out of what the searcher wants to know) and automated deconstruction of the content to be indexed and searched. Good semantic search, therefore, depends on excellent ontologies. For our EHR related purposes, the use of the word Ontology is discouraged, and should be replaced with a less ambiguous description of the thought trying to be conveyed. Terminology Binding is the identification of the concept fillers for a given attribute in a given class. Attributes of a class can be coupled with the set of concepts used to describe the possible values of that attribute. The binding at the class level is broad and can usually best be done with a Semantic Type rather than a Value Set until such time that the class is incorporated as a component of a specific Implementable Information Model ( IIM ) that is to be used for a specific data purpose in a specific domain. For example, a laboratory class has a result value attribute. When the class is unbound to a specific IIM, I can only say that the terminology for that attribute will come from some data set that can express a lab value. For example, that data set might be an ordinal type, a narrative type or a nominal value. If I now include my class in a specific IIM where I know the only result values that I will get are blood types, I can bind the attribute to a specific value set that contains all of the human blood types and no other values are possible. More recently, terminology binding can also occur with programming languages, in addition to with information models. A value set [ Core Principles and Properties of HL7 Models ] represents a uniquely identifiable set of valid concept representations (e.g., terms, codes), where any concept representation can be tested to determine whether or not it is a member of the value set. Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems. In the terminology model, a value set is represented by the Value Set class. HL7 Value Sets have the following properties: An identifier (id) that uniquely identifies the value set. A name (name) for the value set A description (description) for the value set. An optional expression (ruleSetId) that defines (by value or reference) the algorithm to determine the members for “intensionally defined” value sets A status (status) to identify the state (mainly for curation) A status date (statusDate) to identify the date the status was set to its current value (for curation) A Value Set can be used as fillers for a field in a data entry form. A value set need not draw all of its member concepts from a single code system. This means that a value set member must be stored with the date of the value set creation and some unique identifier for the value set. The life of a coded concept does not end when the submit button is depressed and the data element is stored in the database. The data will almost always have a secondary use and in order to use that data appropriately, it must be stored with the appropriate metadata to understand the coded concept in context. This will include enough metadata to resolve the exact value set membership at a given point in time, namely at the time the user submitted the data. Attention to value set membership in a pick list is necessary to enable valid life-long longitudinal analysis of data. Without this metadata it would be impossible to know what coded concepts a user could have chosen from as a response in a form field, hence data would not be comparable over time as the choices could have been changed by addition or deletion. A Pick List is an ordered value set for optimal use in an interface. here is psychometric evidence that the ordering of a concept in a pick list is important in evaluation of data input and this metadata may be optionally stored as well {Sudman S, 1996 #257}. APPENDIX SNOMED Hierarchies: Clinical findings/disorders Procedures/interventions Observable entities Body structures Organisms Substances Pharmaceutical/biologic products Specimens Special concepts Physical objects Physical forces Events Environments/geographic locations Social contexts Situations with explicit context Staging and scales Clinical LOINC® Subject Areas: Vital Signs Hemodynamics Fluid Intake/Output Body Measurements Operative Notes Emergency Department Respiratory Therapy Document sections Standard survey instruments EKG (ECG) Cardiac Ultrasound Obstetrical Ultrasound Discharge Summary History & Physical Pathology Findings Colonoscopy/Endoscopy Radiology reports Clinical Documents Tumor Registry Description Logics have played an important role in knowledge representation. In DL’s, intensional knowledge is represented as a taxonomy using a so-called concept language as a representation method. A concept language is in fact a limited variant of the First Order Predicate Language.
