Iehr ciif sdk-slides-draft-h

2,767 views

Published on

Published in: Technology, Health & Medicine
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,767
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
58
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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 "cross-references" and defines composite concepts by their elementary ones. Combinations of terms using "linkages" and "modifiers" 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 ("a lab is ordered", "a lab is canceled", "a lab specimen is corrupted", and so on).   You could say that a "patient" is a focal class, but a patient ID service generally doesn't express operations to modify the state of that "object". 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 "workbench" (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: "get concept description by keyword" (e.g., physician query to problem list), "get parent concept" (e.g., for data aggregation of entered problems), "get code by concept description" (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 "what code sets should I use for describing patient problems in the spinal cord injury registry?" "How do I access those codes (location, valid API)?" 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 "data-in-context". 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 "not elsewhere classified" 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 "authoritative" when they hear "reference", which is not what, is meant. “Reference terminology” is sometimes used in the sense of "terms we refer in an accepted list" 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.
  • Iehr ciif sdk-slides-draft-h

    1. 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. 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. 3. Preface <ul><li>In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates agreed on a common EHR technical architecture, data and services and exchange standards for the joint EHR system (aka iEHR), where the joint EHR will include both proprietary and open source software. The secretaries of the Veterans Affairs and Defense Departments met on May 2 and June 30, 2011 to determine their next steps toward developing a single electronic health record, for the two agencies. </li></ul><ul><li>“ VA is developing an open source track to modernize VistA and will incorporate the approach in the joint EHR &quot;, Shinseki said. “ One of my objectives is to have minimal disruption in the hospitals as we evolve from VistA to the joint EHR system What I think you will see us do is replace modules, do incremental upgrades .” … “ In five or 10 years, there may not be one line of code left from VistA. And in my ideal world, the users will have no idea that I have made any changes, ” VA Secretary Eric Shinseki said. </li></ul><ul><li>“ Our goals are to bring in as many private sector modules as possible and selecting the same thing to run between VA and DOD so that we end up with a single, common electronic health record system ,” Roger Baker , VA CIO said. OSEHRA sees private modules including both open source or commercial; OSEHRA intends to foster innovation at the module level and encourages Darwinian selection among competing modules based on cost, performance and support preferences. </li></ul><ul><li>  &quot; We planned, as part of this EHR framework, to release all the documents, architecture, all these things. It will no longer be, 'you figure it out, you tell us a solution, '&quot; said Col. Hon Pak , the Army medical department's chief information officer. &quot; The open-source custodial agent, largely a VA-led effort but we also participate, really gives you an opportunity in ways that we've never had before .&quot; … &quot; Having that venue now equalizes the playing ground so that small, innovative organizations can come and help us figure things out .&quot; said Pak. Opening the door to nimble, innovative technologies is a core focus for Pak, who said “ DoD is looking for more modular capabilities .” All the services &quot; have pretty much bet the farm &quot; that patient-centered medical home will change healthcare, but he said they need the right tools to get there. &quot; This idea around [health information exchange], telehealth, mobile health, patient-centered medical home are really going to be the necessary ingredients that have to be formulated to drive some of the transformation,&quot; Col. Pak said. </li></ul><ul><li>This iEHR-CIIF SDK is a part of the journey to implement the vision expressed above. </li></ul>
    4. 4. Purpose iEHR is a part of a joint DoD-VA Open Source EHR (OSEHR) Initiative <ul><li>The interoperable EHR Common Information Integration Framework (iEHR-CIIF) Software Development Kit ( SDK ) presents the vision (slide deck) and specifies the means (technical document) for Open Source and COTS applications to plug-and-play with DoD-VA’s future-state open-source interoperable-EHR kernel-operating-system and data-store (s); the kernel is an n-tiered set of “information” services for best-of-class application integration. </li></ul><ul><li>The SDK development, following agile processes, is intended to become a clear, complete, concise, correct and consistent HL7 SAIF (Service Aware Interoperability Framework) conformant standards-based iEHR Implementation Guide ( IG ) for vender and open-source developers. </li></ul><ul><li>YOUR HELP IS REQUESTED IN VERIFYING, VALIDATING AND INCREASING THE USABILITY OF THE iEHR-CIIF SDK </li></ul>
    5. 5. Benefits D R A F T Talking Points <ul><li>The SDK ensures consistency across </li></ul><ul><ul><li>Interoperable Application Service APIs </li></ul></ul><ul><ul><ul><li>Services/ Engineering Service Bus (ESB) </li></ul></ul></ul><ul><ul><ul><li>Interoperable Plug-and-Play Applications </li></ul></ul></ul><ul><ul><li>Interoperable Virtual Database ( DB ) APIs scalable from </li></ul></ul><ul><ul><ul><li>Legacy MUMPS-globals acting as a DB to CDR/HDR to HAIMES II to </li></ul></ul></ul><ul><ul><ul><li>Massively-parallel high-performance grids running on commodity-hardware-blade-platforms (i.e., amazon.com & google.com models). </li></ul></ul></ul><ul><ul><li>Interoperable Trading Partners </li></ul></ul><ul><ul><li>Acquisitions (SDK as GFI for RFIs and RFPs) </li></ul></ul><ul><ul><li>VA, DoD and IHS offices, staff and contractors </li></ul></ul><ul><ul><li>Open Source Community </li></ul></ul>
    6. 6. Transition Strategy <ul><li>The iEHR-CIIF set-of kernel-and-data services MUST be set-up at one-or-more data-centers. </li></ul><ul><li>For pre-certification self-testing and attestation, venders and developers MUST be provided: i) SDK, ii) an open-source test virtual-machine ( VM ) with the iEHR’s set-of kernel-and-data services, iii) clinically-meaningful test-database, test-scripts, OSEHRA certification-criteria. </li></ul><ul><ul><li>OSEHRA certified applications, their test and certification test-VM, test scripts and test-results MUST be made available to anyone who wishes to verify test results attestations. </li></ul></ul><ul><ul><li>Agile SDK, kernel and application development and certification processes require certification up-to-date VMs and ongoing OSEHRA recertification to maintain “VA’s class 1 software” status. </li></ul></ul><ul><li>One-or-more user-configurable iEHR viewers MUST be made freely available. </li></ul><ul><li>Legacy systems MUST be updated to “journal” their clinically-relevant data-store transactions with the iEHR data-store and to query the iEHR, analogous to legacy DoD-VA sharing; legacy-CIIF terminology harmonization MUST be a part of a transition. </li></ul><ul><li>To be repurposed to iEHR capability, legacy applications MUST meet the SDK’s iEHR kernel-services interoperability specifications and OSEHRA certification criteria. </li></ul><ul><li>Once appropriate iEHR viewer(s) and iEHR certified applications are available to clinical users, they can transition to iEHR-CIIF based systems, while others might continue on legacy systems. </li></ul><ul><li>Clinically-meaningful legacy-data MUST be extracted to iEHR before legacy systems are shut down. </li></ul>
    7. 7. <ul><li>Understanding iEHR-CIIF </li></ul><ul><li>iEHR-CIIF SDK Scope </li></ul><ul><li>Business Context </li></ul><ul><li>Clinical/Work Process Architecture </li></ul><ul><li>System Architecture </li></ul><ul><li>Information Architecture </li></ul><ul><li>Integration & Deployment Options </li></ul><ul><li>Potential Applications </li></ul><ul><li>Summary & Conclusion </li></ul>Outline iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    8. 8. Understanding the Interoperable EHR (iEHR) Common Information Infrastructure Framework (CIIF) <ul><li>The iEHR-CIIF is a business-driven agile enterprise-information-management methodology and set of software-service technologies, which enable semantic interoperability of clinical data. </li></ul><ul><li>The iEHR-CIIF Team specifies, implements, or imposes a standards-based set of iEHR foundational services that enables any authorized iEHR enpowered provider to care for any beneficiary regardless of location, organization or device. </li></ul>See notes page
    9. 9. iEHR-CIIF Benefits <ul><ul><li>Increases availability & accessibility of information  patient safety & quality of care </li></ul></ul><ul><ul><li>Eliminates/reduces costly data mapping </li></ul></ul><ul><ul><li>Clarifies & communicates improved requirements (for vendors) </li></ul></ul><ul><ul><li>Provides common reproducible software development processes (interoperability design patterns) </li></ul></ul><ul><ul><li>Encourages faster-and-lower-cost changes </li></ul></ul><ul><ul><li>Supports efficient legacy transition to modernized systems </li></ul></ul><ul><ul><li>Assures consistent information context and meaning </li></ul></ul>
    10. 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. 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. 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
    13. 13. Business Context iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    14. 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. 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. 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. 17. Why an iEHR? The World of Healthcare is Changing… <ul><li>The Old World </li></ul><ul><li>Provider-focused </li></ul><ul><li>Illness centric </li></ul><ul><li>Site-of-care centric </li></ul><ul><li>Episode Management </li></ul><ul><li>Supply Management </li></ul><ul><li>Solitary decision making </li></ul><ul><li>Inefficiency </li></ul><ul><li>De-centralized, generalized care </li></ul>iEHR-CIIF WORKING DRAFT: not for wide distribution or official use See notes page The New World Patient & family-focused Medical home and wellness care Continuum of care & case management Disease and demand management Collaborative, evidence-based decisions Meaningful-Use objectives, metrics & criteria Patient safety, quality and effectiveness Centralized, specialized care
    18. 18. Why an iEHR-CIIF? The World of Healthcare is Changing… <ul><li>The changes in healthcare require significant capability from the health infostructure; this capability does not fully exist today </li></ul>iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    19. 19. The Timing Has Never Been Better! <ul><li>Public wants more accessibility </li></ul><ul><li>Health Authorities recognize benefits </li></ul><ul><li>Increased financial pressures </li></ul><ul><li>Healthcare professionals embracing technology </li></ul><ul><li>Willingness to collaborate </li></ul><ul><li>Political will </li></ul><ul><li>Funding is now available </li></ul><ul><li>mandated to pursue investments </li></ul>CONVERGENCE WILL CAPACITY <ul><li>Better infrastructure </li></ul><ul><li>More mature application technologies </li></ul>CAPABILITY iEHR-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]
    20. 20. iEHR-CIIF: Key Concepts iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    21. 21. EHR <ul><li>An Electronic Health Record (EHR) provides each individual with a secure and private lifetime record of their key health history and care within the health system. The record is available electronically to authorized health providers and the individual anywhere, anytime in support of high quality care. </li></ul><ul><li>This record is designed to facilitate the sharing of data – across the continuum of care, across healthcare delivery organizations and across geographies. </li></ul>iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    22. 22. Interoperable EHR Solution <ul><li>The Interoperable EHR Solution is a combination of people, organizational entities, business processes, systems, technology and standards that interact and exchange clinical data to provide high quality and effective healthcare. </li></ul>iEHR-CIIF WORKING DRAFT: not for wide distribution or official use See notes page
    23. 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. 24. iEHR-CIIF Outcomes <ul><li>Providers </li></ul><ul><li>Relevant data, granular, computable if needed </li></ul><ul><li>Real time </li></ul><ul><li>Rapid access from multiple locations, anywhere, anytime </li></ul><ul><li>Decision support </li></ul><ul><ul><li>Clinical reference data </li></ul></ul><ul><ul><li>Guidelines & protocols </li></ul></ul><ul><ul><li>Common terms & codes </li></ul></ul><ul><li>Case management & workflow </li></ul><ul><li>Safety </li></ul><ul><li>Improved quality of care </li></ul><ul><li>Regulation & accountability </li></ul>Authoritative, reliable, secure, private <ul><li>Patient/Public/Clients </li></ul><ul><li>Convenient, relevant access to accredited health information </li></ul><ul><li>Access to relevant personal health information </li></ul><ul><li>Safety </li></ul><ul><li>Improved quality of care </li></ul><ul><li>Public Sector Health Managers </li></ul><ul><li>Registry solutions & initiatives </li></ul><ul><li>Objective analysis of results & benefits </li></ul><ul><li>Management reports </li></ul><ul><li>Funding & resource allocation </li></ul><ul><li>Policy </li></ul><ul><li>Payer/Payee </li></ul><ul><li>Relevant data to adjudicate claim </li></ul><ul><li>Workflow management </li></ul><ul><li>Researchers & Health Surveillance Professionals </li></ul><ul><li>Computable data </li></ul><ul><li>Appropriately summarized data </li></ul><ul><li>Anonymized in framework </li></ul><ul><li>Designed for analysis: </li></ul><ul><ul><li>Statistical sampling </li></ul></ul><ul><ul><li>Trends </li></ul></ul><ul><ul><li>Outbreak detection </li></ul></ul><ul><ul><li>Outcome analysis </li></ul></ul><ul><li>Regional </li></ul><ul><li>National </li></ul>iEHR-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]
    25. 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. 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. 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. 28. Guiding Principles for iEHR-CIIF <ul><li>Patient-centric </li></ul><ul><li>Easially customized views of all clinical data </li></ul><ul><li>Value add for the provider </li></ul><ul><li>Timely, accurate information </li></ul><ul><li>Enable sharing at local, regional, cross-organizational </li></ul><ul><li>Interoperable, integrated applications </li></ul><ul><li>Standards based </li></ul><ul><li>Computable where required </li></ul><ul><li>Replicable solution – patterns, components </li></ul><ul><li>Leverage legacy systems & solutions </li></ul><ul><ul><li>VA VistA </li></ul></ul><ul><ul><li>MHS AHLTA </li></ul></ul><ul><ul><li>Open Source Applications </li></ul></ul><ul><li>Design for phased rollout with near term results </li></ul><ul><li>Scalable </li></ul><ul><ul><li>Individual provider’s Point-of-Service (POS) </li></ul></ul><ul><ul><li>Specialty, Ancillary, Public Health POSs </li></ul></ul><ul><ul><li>Interoperating with large -o-massive Enterprise </li></ul></ul><ul><li>Extensible to support future growth </li></ul><ul><li>Pragmatic and Cost-effective </li></ul><ul><li>Secure & private </li></ul><ul><li>Allow for innovation & competition </li></ul><ul><ul><li>Open Source commodity applications </li></ul></ul><ul><ul><li>Best –of-class COTS applications </li></ul></ul><ul><li>Comprehensive </li></ul>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]
    29. 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. 30. A Few Misconceptions About Interoperable EHR Solutions <ul><li>Misconception </li></ul><ul><li>A person’s health data is in only one physical EHR </li></ul><ul><li>All data for a person must be in the EHR to have value and generate adoption </li></ul><ul><li>An Organization is a provider practice </li></ul><ul><li>The EHR is a data warehouse to support research and surveillance </li></ul><ul><li>Reality </li></ul><ul><li>EHR: an integrated service covering all available Interoperable EHR Solutions; a client’s record is seen as coming from a single integrated EHR </li></ul><ul><li>Quality, safety & effectiveness enhanced with only subsets of clinically relevant data available for sharing </li></ul><ul><li>An organization is any geo-political entity mandated or chartered to govern the operation of an Interoperable EHR Solution </li></ul><ul><li>The iEHR-CIIF: an information support service available to caregivers in the daily context of care provision work activities </li></ul>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]
    31. 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. 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
    33. 33. Coordination Across the Enterprise Common Services Bus (CSB) CIIF Infrastructure Rules Engine Technical Services Services Communications Translation Service MDR Terminology Model Services Model Information Model Rule Set Mapping to Legacy Data Standardization Physical Data Model Caching Database Topologies Latency <ul><li>Outside </li></ul><ul><li>Clinical Measures </li></ul><ul><li>Capabilities </li></ul><ul><li>Applications </li></ul><ul><li>Adapters </li></ul>See notes page
    34. 34. The CIIF drives the iEHR run-time environment 10/15/11
    35. 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
    36. 36. Business/Clinical Scope iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    37. 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. 38. Population/Public Health Business Requirements <ul><li>Focuses on managing health status of populations </li></ul><ul><li>Managed and executed through complex network of public/private organizations acting at different levels of the health system (Federal, State, Regional, Local, Individual) </li></ul><ul><li>Involves: </li></ul><ul><ul><li>Research & analysis to identify/define population health programs </li></ul></ul><ul><ul><li>Surveillance activities to detect and pro-actively react to potential population health problems </li></ul></ul><ul><ul><li>Application of health programs to prevent the appearance and/or dissemination of preventable diseases </li></ul></ul><ul><ul><li>Active management of communicable disease outbreaks </li></ul></ul><ul><ul><li>Active management of the delivery of health services to individuals in the context public health related programs </li></ul></ul><ul><li>Current focus limited to: </li></ul><ul><ul><li>Surveillance and detection (focused on human health-related diseases) </li></ul></ul><ul><ul><li>Outbreak Management </li></ul></ul><ul><ul><li>Public Health Alert Management </li></ul></ul><ul><ul><li>Disease Information Dissemination </li></ul></ul><ul><ul><li>Immunization Management </li></ul></ul><ul><ul><li>Communicable Disease Case Management </li></ul></ul>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]
    39. 39. Integrating Population/Public Health in the Architecture <ul><li>Candidate services required to support: </li></ul><ul><li>Surveillance & Detection: There is a business need for a Health information data warehouse </li></ul><ul><li>Outbreak Management: requires the addition of a new category of service called Population Health Services where a specific service is introduced to address outbreak management; analogous services will evolve. </li></ul><ul><li>Common Information Integration Framework (CIIF): addresses the need for a formal terminology registry system that maintains information and terminology models for clinical domains and other key terminologies required for many services of the iEHR </li></ul><ul><li>Public Health Alert Management </li></ul><ul><ul><li>Public health disease alert reporting requires use of specific applications also positioned as Population Health services </li></ul></ul><ul><ul><li>Public health alerts dissemination relies on terminology registry and CIIF Alerts and Notification services </li></ul></ul><ul><li>Immunization Management </li></ul><ul><ul><li>Immunization programs and their management requires a specific application that would live under the Population Health services category </li></ul></ul><ul><ul><li>Delivery of immunisation would be tracked by the drug information domain as part of the EHR </li></ul></ul><ul><li>Communicable Disease Case Management </li></ul><ul><ul><li>Delivery of health services in relation with the treatment of a CD case would be tracked by the shared health record and other domains as part of the EHR </li></ul></ul><ul><ul><li>Management of a CD case from the perspective of the public health specialists involved in detection and tracking would require a specific application that would live under the Population Health services category </li></ul></ul>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]
    40. 40. Integrating Public Health in the Architecture <ul><li>Some Public Health business requirements can be sustained by the </li></ul><ul><li>existing services of the EHR Infostructure </li></ul><ul><li>Public Health Alert Management: CIIF and LRS to provide for mechanism to help with detection & reporting on communicable diseases </li></ul><ul><li>Immunization Management: Drug Information Domain is the home of immunization information as part of the core clinical data in client’s health records. CIIF and LRS to provide mechanisms to communicate the data and coordinate its location and access within the EHRi </li></ul><ul><li>Communicable Disease Case Management: CD Cases, from the perspective of the EHR are treated like any other health delivery encounter </li></ul>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]
    41. 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. 42. Telehealth Business Requirements <ul><li>Telehealth: the use of information & communication technologies to deliver health services in contexts where the providers and clients are in separate locations </li></ul><ul><li>Telecommunication infrastructure is a pre-requisite </li></ul><ul><li>Telehealth solutions enable health service delivery channels: </li></ul>Tele-consultations Tele-education Tele-homecare Tele-triage <ul><li>Scheduling solutions – a key enabler required for the effective use of telehealth service delivery </li></ul><ul><li>EHR Infostructures support telehealth applications as per any other Point-of-Service Application </li></ul>Videoconferencing stations, communication enabled medical devices Videoconferencing stations used for training/education Active or passive monitoring of remote patients for pre-/ post-op procedures, chronic diseases management, etc Centralized call centers to offer first line delivery of service to clients as part of primary care and emergency response 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]
    43. 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. 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. 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. 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. 47. Clinical, Business & Socio-economic Drivers for Interoperable EHR SOLUTIONs iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    48. 48. Why is Value Created by an Interoperable EHR SOLUTION? <ul><li>Healthcare professionals make clinical decisions based on knowledge </li></ul><ul><ul><li>Encounter and Case Management, </li></ul></ul><ul><ul><li>Care Plan, </li></ul></ul><ul><ul><li>Health Concern Tracking </li></ul></ul><ul><ul><li>Analytics </li></ul></ul><ul><li>Better knowledge translates to better care </li></ul><ul><li>Knowledge starts with accurate, relevant clinical information </li></ul><ul><li>The EHR creates the capability to share relevant clinical information </li></ul><ul><li>The 5 Rs of the EHR: </li></ul><ul><ul><li>The right information </li></ul></ul><ul><ul><li>About the right client </li></ul></ul><ul><ul><li>Available to the right person </li></ul></ul><ul><ul><li>In the right place </li></ul></ul><ul><ul><li>At the right time </li></ul></ul>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]
    49. 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. 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. 51. Why Pursue The EHR: Benefits Pharmacy Laboratory Diagnostic Hospital Emergency Homecare Community Care Center Clinic Emergency Services Specialist Clinic <ul><li>DoD priorities: </li></ul><ul><li>Experience of care </li></ul><ul><li>Readiness </li></ul><ul><li>PopHealth </li></ul><ul><li>Per capita costs </li></ul>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 QUALITY SAFETY ACCESSIBILITY
    52. 52. The iEHR-CIIF is a Key to a Renewed Health System! <ul><li>Interoperable EHR Solutions provide an opportunity to </li></ul><ul><li>Improve the quality, safety, accessibility and timeliness of care </li></ul><ul><li>Support more informed healthcare decision making, research and management </li></ul><ul><li>Improve the efficiency of the healthcare system and reduce costly duplication </li></ul><ul><li>Maximize return on IT investments </li></ul><ul><li>Achieve standards based solution allowing interoperability </li></ul>iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    53. 53. iEHR-CIIF Key Clinical & Business Requirements <ul><li>Life-long longitudinal record of clinical data </li></ul><ul><li>Allowing private and secured access to data made available in EHR </li></ul><ul><li>Focused on clinically relevant data shared beyond organizational boundaries </li></ul><ul><li>Support for accurate, complete, timely delivery of information </li></ul><ul><li>Shared across multiple organizations, Organizations </li></ul><ul><li>Adaptive to the future of healthcare delivery in the 21st Century </li></ul><ul><li>Requiring ongoing governance and operations management with 24/7 high availability service </li></ul><ul><li>Affordable in relation to complexity and size of integration challenges (connecting large numbers health points of service) </li></ul><ul><li>Scalable to allow continuous, extensive growth of clinical and financial ROI </li></ul><ul><ul><li>More POS applications sourcing data to EHR </li></ul></ul><ul><ul><li>More users accessing and using data from EHR </li></ul></ul><ul><ul><li>Allowing natural growth of capabilities towards Generation 3 and beyond </li></ul></ul>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
    54. 54. Different Approaches To Achieving iEHR-CIIF iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    55. 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. 56. Methods of Sharing EHR Information <ul><li>The “Big Database </li></ul><ul><li>in the Sky” </li></ul><ul><li>All Point-of-Service (POS) systems share same data store </li></ul><ul><li>Broadcast to all or </li></ul><ul><li>a logical subset of </li></ul><ul><li>Systems (caching) </li></ul><ul><li>Replication of data from one system to all other relevant/ participating POS systems </li></ul><ul><li>Every POS system holds same information </li></ul><ul><li>The “Big Index in </li></ul><ul><li>the Sky” </li></ul><ul><li>EHR Index or locator service that holds links to all POS systems where information resides </li></ul><ul><li>Each POS system interfaces to other systems </li></ul><ul><li>Use of a </li></ul><ul><li>shared reference </li></ul><ul><li>information source </li></ul><ul><li>POS systems populate it </li></ul><ul><li>POS systems or viewers reference it </li></ul><ul><li>External to the “operational” store </li></ul>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]
    57. 57. Key Factors Affecting How to Share <ul><li>Sharing creates some very profound issues & requirements </li></ul><ul><ul><li>Unique identification of clients, providers, service delivery locations, etc. </li></ul></ul><ul><ul><li>Protecting privacy and confidentiality of patients and providers while simultaneously not limiting the ability to deliver appropriate services </li></ul></ul><ul><ul><li>Ensuring information is stored, shared securely </li></ul></ul><ul><ul><li>Ensuring compatibility of how data is interpreted/understood --- CIIF </li></ul></ul><ul><li>Issues the same no matter which model is chosen to share patient identified information </li></ul><ul><li>Governance model for healthcare means these issues are organizational responsibilities – requirements vary </li></ul><ul><li>People increasingly mobile, especially when considering long periods of time </li></ul><ul><li>Provider’s confidence in the mechanisms to enable sharing is crucial </li></ul>DEERS EDIPN Service is the DoD-VA solution 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]
    58. 58. The Integration Challenge of Interoperable EHR Solutions iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    59. 59. Integrating Heterogeneous Systems Pharmacy Laboratory Diagnostic Hospital Emergency Homecare Community Care Center Clinic Emergency Services Specialist Clinic Clients/Patients
    60. 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. 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. 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. 63. Integrating Health Information Systems: Key Challenges <ul><li>Protecting Privacy </li></ul><ul><ul><li>Governance, accountability & data custodianship </li></ul></ul><ul><ul><li>Controlling access </li></ul></ul><ul><ul><li>Managing & applying consent directives </li></ul></ul><ul><ul><li>Controlling feeds and queries to the data </li></ul></ul><ul><ul><li>Trust relationships & contracts </li></ul></ul><ul><li>Existence & availability of data thru CIIF </li></ul><ul><ul><li>Discovery capability </li></ul></ul><ul><ul><li>Availability in electronic format </li></ul></ul><ul><ul><li>Timeliness </li></ul></ul><ul><li>Harmonization through CIIF </li></ul><ul><ul><li>Data structures (format) </li></ul></ul><ul><ul><li>Vocabularies (encoding, normalization) </li></ul></ul><ul><ul><li>Semantics </li></ul></ul><ul><li>Heterogeneous technology environments </li></ul><ul><li>Number of organizations, connection points & systems </li></ul><ul><li>Costs inherent to integration </li></ul>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]
    64. 64. Recommended Approach: The Cost of Integration As A Key Driver iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    65. 65. Integrating Health Information Systems: Point-to-Point Connectivity <ul><li>Costs basis </li></ul><ul><li>Cost of one integration </li></ul><ul><ul><li>Simple = $32K; Medium = $95K; Complex = $190K </li></ul></ul><ul><li>Futile approach </li></ul><ul><li>38,783 systems in Canada </li></ul><ul><li>Simple = 4,527; Medium = 20,081; Complex = 14,175 </li></ul><ul><li>1.5 B integration points </li></ul><ul><li>183.928 B $CDN </li></ul>SYSTEMS TO CONNECT SYSTEMS TO CONNECT SYSTEMS TO CONNECT Contracts 2 App 1 Appl 1 App 1 Appl 2 App 1 App 1 Appl 1 App 1 Appl 2 6 App 1 App 1 Appl 3 Interfaces = N (N-1) 12 App 1 Appl 1 App 1 Appl 2 App 1 Appl 3 App 1 Appl 4 We need a different approach 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] App 1 App 1 App 1 App 1 App 1 App 1 App 1 App 1
    66. 66. Integrating Health Information Systems: Hospital Networks Approach <ul><li>Costs basis </li></ul><ul><li>Cost of one integration </li></ul><ul><ul><li>Simple = $32K; Medium = $95K; Complex = $190K </li></ul></ul><ul><li>Hypothesis </li></ul><ul><li>1,126 Hospital networks, each includes 71 systems to integrate and group (EAI) in 44 points of integration </li></ul><ul><li>1,892 (44 x 43) integrations per network totalling 2.1 M (1,126 x 1,892) integrations in Canada </li></ul><ul><li>Assuming existence of standardized protocol for interfaces </li></ul><ul><li>68.172 M $CDN (if Simple – 32K) </li></ul><ul><li>202.316 M $CDN (if Medium – 95K) </li></ul>We need a different approach SYSTEMS TO CONNECT SYSTEMS TO CONNECT SYSTEMS TO CONNECT Contracts 2 App 1 Appl 1 App 1 Appl 2 App 1 App 1 Appl 1 App 1 Appl 2 6 App 1 App 1 Appl 3 Interfaces = N (N-1) 12 App 1 Appl 1 App 1 Appl 2 App 1 Appl 3 App 1 Appl 4 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] App 1 App 1 App 1 App 1 App 1 App 1 App 1 App 1
    67. 67. Rational for Recommended Approach <ul><li>Only cost effective scenario to handle degree of application integration required </li></ul><ul><li>Maximized ability to deliver proper response time and consistent access to data across thousands of source systems </li></ul><ul><li>Maximized ability to apply privacy and security policies in a harmonized and consistent fashion </li></ul><ul><li>Enables evolutionary path to semantic harmonization of health information across service delivery points </li></ul><ul><li>Enables high degree of scalability from local health services integration, to regional, state and cross-organizational </li></ul><ul><li>Enables high degree of flexibility in reconfiguration of health services delivery networks </li></ul>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]
    68. 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. 69. iEHR-CIIF Work Process Architecture <ul><li>The EHR Clinical Reference Framework: Life of the Lamberts </li></ul><ul><li>Depiction of the use of an Interoperable EHR Solution in different contexts of health service delivery </li></ul><ul><ul><li>14 different storyboards created </li></ul></ul><ul><ul><li>Extensible by adding new use cases </li></ul></ul><ul><ul><li>System or security administration use cases not represented </li></ul></ul><ul><li>Life of the Lamberts </li></ul><ul><ul><li>Patient centric framework </li></ul></ul><ul><ul><li>Focused on different members of a family and their health status evolution </li></ul></ul><ul><ul><li>Focused on health related events </li></ul></ul><ul><li>Represented with UML use case notation </li></ul><ul><li>Published as artefacts under the Artefact Repository </li></ul><ul><ul><li>Available in HTML and PDF format </li></ul></ul><ul><ul><li>Available in Magic Draw format and XMI for upload to other case tools </li></ul></ul>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]
    70. 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. 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. 72. People Use Cases: Caregiver Perspective 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 <ul><li>First class of SDK informative deliverables are contextual & informational </li></ul><ul><li>They describe the end-user functional requirements and assumptions for use of an Interoperable EHR Solution ( DoDAF OV-3: Operational Resource Flow Matrix ) </li></ul><ul><li>Establish when POS applications expected to interact with an EHRi in the context of daily work activities for caregivers ( DODAF OV-6c: Event-Trace Description aka BPMN use case diagrams ) </li></ul><ul><li>iEHR-CIIF SDK is only documenting Interoperability Specifications (ISs); not internal EHR features. </li></ul><ul><li>Scope is broad enough to cover large spectrum of healthcare and public health service delivery to achieve representative set </li></ul>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 Security Mgmt Data Privacy Data Configuration CIIF Secure Communications Bus Common Services EHR INTERFACE REQUIREMENTS DOCUMENTATION Stakeholder Entities Storyboards, Use Cases Events, Encounters, Episodes of Care Clinical Activities, Information Exchanges
    73. 73. EHR Interoperability Profile (EHR IP) CIIF <ul><li>Second class of SDK normative deliverables; specify the interfaces between POS applications and iEHR ( DODAF SV-6: Systems Resource Flow Matrix & SvcV-6: Services Resource Flow Matrix ) </li></ul><ul><li>Establishes a language to describe types of service requests made to an EHRi ( DODAF SV-1: Systems Interface Description & SvcV-1: Services Context Description ) </li></ul><ul><li>Positions which data to be exchanged by referring to data views of the data model ( DODAF DIV-1: Conceptual Data Model & DIV-2: Logical Data Model ) </li></ul><ul><li>Assumes SOAP-based web services calls where XML encoded HL7 V3 message requests … V3? and responses are carried between POS applications and the EHRi </li></ul>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 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 Interoperability Profile (IP) Information Exchange Content Standards Information Exchange Transport Standards
    74. 74. EHR Infostructure IP (EHR I-IP) Security Mgmt Data Privacy Data Configuration CIIF Secure Communications Bus Common Services <ul><li>Third class of SDK normative deliverables; specify inner workings within iEHR Infostructure to orchestrate and process transactions ( DODAF SV-10c: Systems Event-Trace Description & SvcV-10c: Services Event-Trace Description ) </li></ul><ul><li>Express sequencing of activities to process transactions ( DODAF SV-5a: Operational Activity to Systems Function Traceability Matrix & SvcV-5: Operational Activity to Services Traceability Matrix ) </li></ul><ul><li>Express expected capabilities of services within an EHRi to process transactions ( DODAF CV-3: Capability Phasing ) </li></ul>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 Business Rules EHR Index Message Structures Normalization Rules Longitudinal Record Services (LRS) Client Registry Provider Registry Location Registry Terminology Registry POINT OF SERVICE INFOSTRUCTURE INTEROPERABILITY PROFILE Infostructure IP Infostructure Services Catalogue Generic Interface Specification
    75. 75. Enterprise Application Integration (EAI IP) Security Mgmt Data Privacy Data Configuration CIIF Secure Communications Bus Common Services <ul><li>Fourth class of SDK normative deliverables; specify inner workings within iEHR Applications to orchestrate and process transactions ( DODAF SV-10c: Systems Event-Trace Description & SvcV-10c: Services Event-Trace Description ) </li></ul><ul><li>Express sequencing of activities to process transactions ( DODAF SV-5a: Operational Activity to Systems Function Traceability Matrix & SvcV-5: Operational Activity to Services Traceability Matrix ) </li></ul><ul><li>Express expected capabilities of services within an EHRi to process transactions ( DODAF CV-3: Capability Phasing ) </li></ul>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 Business Rules EHR Index Message Structures Normalization Rules Longitudinal Record Services (LRS) Client Registry Provider Registry Location Registry Terminology Registry POINT OF SERVICE Enterprise Application Integration Interoperability Profile / Specification Application IP Application Services Catalogue Generic Interface Specification
    76. 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. 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. 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. 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. 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. 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. 82. EHR Infostructure: Longitudinal Record Services (LRS) <ul><li>The EHR Index maintains a sequential list of all events that affect the clinical picture of a client. It also provides the location where the data relevant to each event is kept in the EHRi. It can be used to retrieve the history of events for a client or to trace the information about a specific event. </li></ul><ul><li>EHR INDEX </li></ul><ul><li>Event ID (Instance ID of an event) </li></ul><ul><li>Parent Folder ID </li></ul><ul><li>Focal Class Type </li></ul><ul><li>Focal Act Subject (Client ECID) </li></ul><ul><li>Focal Act Author (Provider) </li></ul><ul><li>Focal Act Service Delivery Location </li></ul><ul><li>Focal Act Timestamp </li></ul><ul><li>Focal Act Status </li></ul><ul><li>Focal Act Language </li></ul><ul><li>Focal Act Type: </li></ul><ul><ul><li>Act Mood (e.g. Order Request) </li></ul></ul><ul><ul><li>Act Class Code (type of class, e.g. Lab order) </li></ul></ul><ul><ul><li>Act Code (Class value, e.g. CBC) </li></ul></ul><ul><li>Focal Act Source ID (ID provided by POS) </li></ul><ul><li>Focal Act Template ID </li></ul><ul><li>Focal Act Data Location ID (URI) </li></ul>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
    83. 83. EHR Infostructure: iEHR-CIIF Locator Data <ul><li>EHRi Client ID (resolved ECID) </li></ul><ul><li>CR instance ID (OID root) </li></ul><ul><li>EHRi instance ID (which instance of an EHRi) </li></ul><ul><li>EHRi URI (the URI to access the CIIF) </li></ul><ul><li>Optimized for performance </li></ul><ul><ul><li>Information type (drug, lab, DI) (derived from HL7 act classes) </li></ul></ul><ul><ul><li>First created date </li></ul></ul><ul><ul><li>Last updated date </li></ul></ul>CROSS-ORGANIZATIONAL INFOSTRUCTURE ORGANIZATIONAL INFOSTRUCTURE POINT OF 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] 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) Common Interoperable Information Infrastructure (CIIF) iEHR Locator
    84. 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. 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. 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. 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. 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. 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. 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. 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. 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. 93. EHRi Client Registry: What Data? <ul><li>The generation (or sourcing) of the EHRI Client Identifier (ECID) is a service offered by the Client Registry. </li></ul><ul><li>The ECID is the foundation for interoperability both locally and across EHR Infostructures. </li></ul>MDR ID Lab ID Name Birthdate Gender SIN ULI ECID Address Phone Eligibility status Coverage details Static, natural person identity information Dynamic, natural person identity information Static, artificial person-identifying information Dynamic, artificial person-identifying information Core system data about the person 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] DEERS EDIPN Service is the DoD-VA solution
    94. 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. 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. 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. 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]
    98. 98. Standards-based Solutions: What Does It Mean? iEHR CIIF WORKING DRAFT: not for wide distribution or official use
    99. 99. Interoperable EHR Solutions: Key Architectural Requirements <ul><li>Standards-based Solutions </li></ul>Standardized Architecture Standardized Interfaces Standardized Data Structures Standardized Data Vocabularies (encoding rules) Standardized Functional Behaviour iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    100. 100. Standards-based Solutions <ul><li>Why Standards? </li></ul><ul><li>They facilitate information exchange; are a critical foundation for EHR </li></ul><ul><li>They create opportunity for future cost reduction as vendors and systems converge on national and international standards </li></ul><ul><li>They ease effort required for replication </li></ul><ul><li>Mandatory Investment Eligibility Requirements </li></ul><ul><li>Compliance to standards (infostructure, architecture) </li></ul><ul><li>Initiatives must comply with existing guidelines or standards adopted by US Health and Human Services (HHS) </li></ul><ul><li>Where standards or guidelines do not exist, projects must support longer-term interoperability and congruence of solutions </li></ul>iEHR’s program role is to encourage standards and requirements for robust, interoperable products and outcomes 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]
    101. 101. Principles for Establishing iEHR Standards <ul><li>The DoD-VA have created Principles for Establishing iEHRs </li></ul><ul><li>Standards to provide guidance in the adoption of standards-based solutions </li></ul><ul><li>As the iEHR SDK evolves, there are many assumptions made that, once implemented in the architecture, can no longer be considered assumptions anymore: they are now principles about the function of iEHR-CIIF Infostructures and iEHR-CIIF Solutions that need to guide detailed design and development of solutions. Business-driven Adoption of existing standards where ever possible </li></ul>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]
    102. 102. Principles for Establishing iEHR-CIIF Standards <ul><li>Standards initiatives to be driven by the business of healthcare with a clearly defined business need </li></ul><ul><li>Existing standards work must be leveraged wherever possible and practical with an approach that includes adoption, or adaptation of existing standards, before development </li></ul><ul><li>Health Level 7 V3 messaging standard required for all new message development related to EHR </li></ul><ul><li>Investments predicated on a commitment to implement national iEHR standards </li></ul><ul><li>Standards to be established, tested, refined and evaluated within the context of early adopter implementations </li></ul><ul><li>DoD and VA will support early adopter investment projects that have the establishment of National standards as their goal </li></ul>NOT DoD-VA Principles 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
    103. 103. Principles for Establishing iEHR-CIIF Standards <ul><li>Establishing standards is an evolutionary process and will not be perfect the first time; implementation of standards that are not fully balloted may be needed </li></ul><ul><li>iEHR program is committed to supporting influencing EHR national and international standards </li></ul><ul><li>iEHR program and its stakeholders will work with other organizations undertaking similar EHR initiatives to leverage their work and bring synergies to the projects as they move toward balloted standards </li></ul><ul><li>iEHR program and its stakeholders will partner with HL7, IHE, OASIS, IHTSDO and other standards organizations in the establishment of iEHR-CIIF standards </li></ul><ul><li>Establishment of EHR standards is coordinated via an open, transparent and inclusive Stakeholder Collaboration Process </li></ul>NOT DoD-VA Principles 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
    104. 104. Standards Collaboration Process (SCP) <ul><li>An integral element of and key requirement for the establishment of an interoperable Electronic Health Record (EHR) </li></ul><ul><li>The EHR Standards Collaboration Process includes those Organizations, standards-related organizations, healthcare professionals and vendors that will build, operate and use an interoperable EHR-CIIF </li></ul><ul><li>The EHR Standards Collaboration Process will establish standards for investments through collaboration and consensus </li></ul>GOVERNANCE REGIONAL DEVELOPMENT Interoperable EHR STRATEGIC COLLABORATION/COORDINATION Telehealth Lab Diagnostic Imaging Drugs Registries Infostructure Infostructure/EHR Expert Working Groups EHR Standards Steering Committee National EHR Standards Advisory Committee National Standards working groups NOT DoD-VA Process 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]
    105. 105. iEHR-CIIF Standards: Status <ul><li>Needed Standards </li></ul><ul><li>Groups </li></ul><ul><li>Drugs </li></ul><ul><li>Client Registry </li></ul><ul><li>Provider Registry </li></ul><ul><li>DI/Tele-radiology </li></ul><ul><li>Laboratory </li></ul><ul><li>Clinical Terminology </li></ul><ul><li>iEHR Technical Standards (coming soon) </li></ul><ul><li>iEHR Clinical Standards (coming soon) </li></ul><ul><li>Public Health (coming soon) </li></ul><ul><li>Suggested Projects </li></ul><ul><li>iEHR-CIIF SDK </li></ul><ul><li>EHR Data Definition & Standards </li></ul><ul><li>Standards Collaboration Process </li></ul><ul><li>Standards Tactical Plan </li></ul><ul><li>Artefacts Repository </li></ul><ul><li>Telehealth ISO Interoperability </li></ul><ul><li>Telehealth CCHSA Accreditation </li></ul><ul><li>Client Registry </li></ul><ul><li>Provider Registry </li></ul><ul><li>Laboratory Nomenclature & Messaging </li></ul><ul><li>NeCST: electronic claims messaging </li></ul><ul><li>EHR Clinical Terminology Integration </li></ul><ul><li>EHR Profiles for Interoperability between DI, Registries & Consumers </li></ul><ul><li>EHR-CIIF Evolution Project </li></ul><ul><li>Privacy & Security Architecture Project </li></ul>Health Surveillance Telehealth Lab Diagnostic Imaging Drugs Registries Interoperable EHR NOT DoD-VA Status 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]
    106. 106. iEHR-CIIF Infostructure: Standards-based Connectivity 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] Registries Data & Services POINT OF SERVICE Population Health Data & Services EHR Data & Services Data Warehouse ORGANIZATIONAL INFOSTRUCTURE Physician/ Provider Physician/ Provider Physician/ Provider Lab Clinician Radiologist Pharmacist 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 EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP CIIF EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP <ul><li>Architecture Standards </li></ul><ul><li>iEHR Blueprint </li></ul><ul><li>EHR Use Cases </li></ul><ul><li>FHIM/EHR Data Model </li></ul><ul><li>iEHR-CIIF Services Model </li></ul><ul><li>EHR Interoperability Profiles </li></ul><ul><li>Terminology Standards </li></ul><ul><li>Terminology implemented in data messaging standards </li></ul><ul><li>Data Messaging Standards </li></ul><ul><li>Client Registry </li></ul><ul><li>HL7 Provider Registry </li></ul><ul><li>HL7 Pharmacy </li></ul><ul><li>Laboratory </li></ul><ul><li>Public Health Services Standards </li></ul><ul><li>Public Health Surveillance Standards </li></ul><ul><li>Diagnostic Imaging/Teleradiology (in planning) </li></ul><ul><li>iEHR Clinical Messaging (in planning) </li></ul><ul><li>iEHR Technical Standards ( DODAF StdV-1: Standards Profile aka DoD-VA shared Standards Profile ) </li></ul>
    107. 107. Service-oriented Architecture (SOA): What Does It Mean? iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    108. 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. 109. SOA as an Enabler <ul><li>Applications of SOA in EHRi Solutions </li></ul><ul><li>Repurposed legacy applications to offer services as part of SOA-based EHR Infostructure </li></ul><ul><li>New breed of services to enable coordinated transactions in an EHR Infostructure (e.g. Longitudinal Record Services ( LRS )) </li></ul><ul><li>Use of commercially available solutions to enable components of EHR Infostructure </li></ul><ul><li>Two Degrees of Separation </li></ul><ul><li>Services exposed outside of an EHRi in the form of supported EHR Interoperability Profiles for an entire Infostructure perceived as a single system with transactional services </li></ul><ul><li>Services within an EHR Infostructure to optimize scalability, maintainability and functional flexibility </li></ul>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]
    110. 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. 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
    112. 112. Functioning Principles iEHR-CIIF WORKING DRAFT: not for wide distribution or official use
    113. 113. Functioning Principles/Rules <ul><li>Home/no-home EHR </li></ul><ul><li>EHRi Identifier Management </li></ul><ul><li>EHR Index </li></ul><ul><li>iEHR Locator </li></ul><ul><li>POS to EHRi interface </li></ul><ul><li>Level of transparency of EHR to POS applications </li></ul><ul><li>Transaction scope </li></ul><ul><li>Trust Models valid for an EHRi </li></ul><ul><li>CIIF normalization of information/terminology </li></ul><ul><li>Auditing, logging, use of logs </li></ul><ul><li>HL7 V3 (Messaging and templates) </li></ul><ul><li>Level of parameterization </li></ul><ul><li>Primary Purpose for EHRi repositories </li></ul><ul><li>Other uses of the CIIF (POS to POS) </li></ul><ul><li>Multilingual capabilities </li></ul><ul><li>Runtime environment </li></ul><ul><li>Performance principles – targets </li></ul><ul><li>POS Integration environment </li></ul><ul><li>Error Handling </li></ul><ul><li>Consent </li></ul><ul><li>Authentication & Authorization </li></ul><ul><li>OIDS as a principle </li></ul><ul><li>Prospective Events </li></ul>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]
    114. 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. 115. EHRi Conceptual Data Model <ul><li>High-level model representing generalized concepts </li></ul><ul><ul><li>Encounter Management, </li></ul></ul><ul><ul><li>Care Plan Service, </li></ul></ul><ul><ul><li>Health Concern Tracking </li></ul></ul><ul><ul><li>Analytics </li></ul></ul><ul><li>Event driven model to represent instances of clinical service impacting a patient record </li></ul><ul><li>Broad range of event typing – governance, people playing roles, delivery, environment, resource </li></ul><ul><li>Derived from the Federal Health Information Model (FHIM) </li></ul><ul><li>Detailed Clinical Models (DCLs) </li></ul><ul><li>Aligned and mapped to HL7 V3 RIM </li></ul><ul><li>Mapped against several local and international EHR data models </li></ul><ul><li>More detailed views available – transactional views, domain views </li></ul>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] Governance Event Linkage Event Role People Resource Environment Place Capability
    116. 116. Components of Computable Data Terminology Model Information Model Repository Used By Used By <ul><li>Concepts </li></ul><ul><li>Concept relationships </li></ul><ul><li>Concept definitions </li></ul><ul><li>Terms </li></ul><ul><li>Hierarchies </li></ul><ul><li>Clinical propositions </li></ul><ul><li>Standard terminologies </li></ul><ul><li>Mappings </li></ul><ul><li>Not patient specific </li></ul><ul><li>Structural layout </li></ul><ul><li>Clinical definition </li></ul><ul><li>Hierarchical in nature </li></ul><ul><li>Contains fields for discrete values </li></ul><ul><li>Fields tied to dictionary </li></ul><ul><li>Defines “valid data” </li></ul><ul><li>Not patient specific </li></ul><ul><li>Instances of data using model and dictionary </li></ul><ul><li>Event based </li></ul><ul><li>Constrained by model </li></ul><ul><li>Patient specific </li></ul><ul><li>An Terminology is a formal representation of healthcare knowledge as a set of concepts , called terms, and the relationships between those terms. </li></ul><ul><li>An information model is a representation of concepts, relationships, constraints, rules, and operations to specify data semantics for healthcare. </li></ul>See notes page
    117. 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. 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. 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. 120. CIIF Services <ul><li>Services Provided by CIIF </li></ul><ul><li>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. </li></ul><ul><ul><li>Syntactic field mapping and conformance </li></ul></ul><ul><ul><li>Semantic terminology mediation and value normalization </li></ul></ul><ul><li>Mediation - a mediation service can handle the transformation from one information-exchange payload-format and transport to another. </li></ul><ul><li>Built-In-Test-Environment (BITE) - for run-time information-exchange integrity-checking. </li></ul><ul><li>Common Terminology Services 2 (CTS2) - CTS 2 terminology services </li></ul><ul><li>Metadata Service – provides information schemas and terminology bindings </li></ul><ul><li>Services Used by CIIF </li></ul><ul><li>Identification – Who are you looking for ? </li></ul><ul><li>Authentication – Who are you ? </li></ul><ul><li>Authorization – What are you allowed to know or do ? </li></ul><ul><li>Secure Data Transport - Standards-based information exchanges. </li></ul><ul><li>RLUS - Retrieve, Locate, Update Service </li></ul><ul><li>Rules Engine – – A business rule service enables policies and other operational decisions to be defined, tested, executed and maintained separately from application code. </li></ul>
    121. 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. 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. 123. CIIF Integration Layer: Evolutionary Path iEHR=CIIF WORKING DRAFT: not for wide distribution or official use
    124. 124. Interim State: No EHR Services (Undesirable) ORGANIZATIONAL INFOSTRUCTURE POINT OF SERVICE Registries Data & Services EHR Data & Services Client Registry Drug Information System Repository EHR Viewer Physician Pharmacy System Pharmacist Each Organization Infostructure level system uses patient and other required strong identifiers (e.g. provider, encounter) based on point-of-service generated IDs (e.g. MRNs). The CR-EMPI source systems make the CR-EMPI aware of client identifiers. The Point-of-Service applications and Infostructure systems query the CR EMPI for these identifiers in order to access data within any Infostructure System. The level of queries and maintenance of MRNs in the EMPI is not scalable to hundreds or thousands of Point-of-Service systems. There are performance issues accessing CR/EMPI for every Drug system interaction. CR API CR API Client Registration 1) Search client 2) Create new client 3) Update existing client HL7 (CR) Pharmacy Profile 4) Request drug profile 5) Request DUR 6) Enter new prescription HL7 (CR) Search/Resolve <ul><li>PATIENT ENCOUNTER </li></ul><ul><li>Client Registration </li></ul><ul><li>Search client </li></ul><ul><li>Create new client </li></ul><ul><li>Update existing client </li></ul><ul><li>Pharmacy Profile </li></ul><ul><li>Request drug profile </li></ul><ul><li>Request DUR </li></ul><ul><li>Enter new prescript

    ×