Texas HIE Interoperability Guidance Enterprise Architecture Blueprint August 19, 2011
Texas HIE Interoperability Guidance Six- Year Vision This (EAB) document contains the architecture vision for the Texas Health Information Exchange (HIE) domain for the next six years, divided into three two- year increments. High Level Use Cases The EAB includes a set of high level use cases chosen to generically reflect the Texas HIE vision and desired capabilities for the next two years (years 1-2). It also includes planning considerations for years 3-4, and a very high- level strategic direction for years 5-6. Texas Health Authority - i - August 19, 2011
Notice This document makes reference to trademarks and brands that may be owned by others. The use of such trademarks herein is not an assertion of ownership of such trademarks by Texas Health Authority (THSA) or Accenture and is not intended to represent or imply the existence of an association between THSA, Accenture, and the lawful owners of such trademarks. Any comments on, or opinions stated in this document regarding the functional and technical capabilities of any software, standards or other products referred to in this document, whether or not expressed as being those of THSA or Accenture, are based on the information made publically available by the standards and governmental organizations to THSA and Accenture or provided in other sources and while THSA and Accenture has no reason to believe that this information is in any way inaccurate or incomplete, responsibility for its accuracy and completeness does not rest with THSA or Accenture. The recommendations made in this document are not required by THSA for implementation of health information exchange and are provided free of charge for informational purposes only. BOTH THSA AND ACCENTURE HEREBY EXPRESSLY DISCLAIM AND EXCLUDE ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED BY STATUTE, LAW OR OTHERWISE WITH RESPECT TO THE CONTENTS OF THIS DOCUMENT. Texas Health Authority - ii - August 19, 2011
Contents 1 Purpose and Objectives... 1 1.1 Implications... 1 2 Stakeholder Engagement Process... 3 3 Texas HIE Vision... 4 3.1 Texas HIE Capabilities... 5 3.1.1 Exchange of Patient Clinical Summaries... 5 3.1.2 Electronic Prescribing... 5 3.1.3 Electronic Submission of Lab Results to Public Health Agencies... 5 3.1.4 Electronic Submission to Immunization Registries... 5 3.1.5 Quality Reporting... 5 3.1.6 Audit and Administrative Reporting... 6 4 Architecture Guiding Principles... 7 5 Assumptions... 9 6 Functional Blueprint... 10 6.1 Statewide Health Exchange Layer Components... 10 6.1.1 Application and Components... 11 6.1.2 Database and Repository Components... 12 6.1.3 Integration Layer Components... 13 6.2 Local HIE and Provider Organization Components... 14 6.2.1 Application and Components... 14 6.2.2 Database and Repository Components... 16 6.2.3 Integration Layer Components... 17 6.3 Functional Blueprint: Years 1 2... 18 6.3.1 Application and Components... 18 6.3.2 Database and Repository Components... 21 6.3.3 Integration Layer Components... 22 6.4 Functional Blueprint: Years 3 4... 23 6.4.1 Application and Components... 23 6.4.2 Database and Repository Components... 25 6.4.3 Integration Layer Components... 26 6.5 Functional Blueprint: Years 5 6... 27 Texas Health Authority - iii - August 19, 2011
6.5.1 Application and Components... 27 6.5.2 Database and Repository Components... 29 6.5.3 Integration Layer Components... 30 7 Use Cases... 31 7.1 Clinical Summary Record Creation... 32 7.2 Query Patient Clinical Summary History... 33 7.3 Lab Order and Results Delivery... 34 7.4 eprescription and Dispensing... 35 7.5 Transition of Care: Direct Project Provider to HIE... 36 7.6 Submitting Lab Results to Public Health Agencies... 37 7.7 Submission to Immunization Registries... 38 7.8 Public Health Quality Reporting... 39 7.9 Audit and Administrative Reporting... 40 8 Local HIE Certification Process... 41 Texas Health Authority - iv - August 19, 2011
1 Purpose and Objectives The development of an enterprise architecture vision is a key component of the Statewide Health Exchange Layer. This (EAB) provides a framework for the way information is stored and interchanged. The goal of this is to: Provide an overview of the THSA vision for Texas HIE; Identify use cases which align with the Texas HIE desired capabilities; Provide a functional blueprint for technology components and interfaces required at the clinical, local HIE, and state levels required for the next 1-2 years; Identify and document the planning considerations for years 3-4, and a very high- level strategic direction for years 5-6; and Map process flows for the use cases to the technology components and interfaces described in the blueprint. This document is not intended to be prescriptive of the systems, technologies, or solutions to be chosen by each Local HIE or for the Statewide Health Exchange Layer. Rather, this document shows the individual components and illustrates the interfaces required; providing some information about how the various components should interact. This document is intended to inform the THSA Technical Implementation Specification documents. These Technical Implementation Specification documents will map standards provided in the THSA Technical Standards Landscape Review to the components and interfaces defined in this EAB. 1.1 Implications Provider Organizations For providers, this EAB is meant to demonstrate away to exchange electronic health records with other providers in the State of Texas. The functional components of the solution described in this document are meant to indicate the types of services and data a provider could be expected to implement or produce as a member of an HIE. However, THSA will not require providers to implement all of these components. Above a certain set of core functions (i.e. security and privacy), it will be largely the responsibility of the providers and the Local HIEs to determine which components they would like to implement and how to design their solution. This blueprint is not the only way by which providers can exchange information, however, it does describe generally those interactions that will be supported by the State, and which will have exchange functionality to support such interactions within the anticipated State Health Exchange layer infrastructure. Local HIEs For Local HIEs, this EAB outlines the components necessary to fully utilize the Statewide Health Exchange layer to facilitate patient data exchange between Local HIEs (and their constituent providers). Above a certain set of core functions (i.e. security and privacy), it will be largely the Texas Health Authority - 1 - August 19, 2011
responsibility of the providers and the Local HIEs to determine which components they would like to implement and how to design their solution. Patients While not intended to be a patient facing document, we appreciate that some patients and patient groups may find information contained within this document of interest. Care should be taken when reading this document that the purpose of the EAB is understood, and that for end to end understanding of the Texas HIE the EAB should be read in conjunction with other material issued by THSA, the Texas Health and Human Commission (HHSC), the Office of the National Coordinator for Health Information Technology (ONC), and other resources. Texas Health Authority - 2 - August 19, 2011
2 Stakeholder Engagement Process The production of this document has been an iterative process. This has been to ensure Texas Health Authority (THSA) stakeholders are aware of the approach and content and to, at each step, allow an opportunity for stakeholders to ask questions and provide feedback. The following table contains a summary of the key THSA stakeholder engagements and specifies the stakeholder groups, engagement dates, and content reviewed. Date Stakeholders Draft State Reviewed June 6, 2011 THSA Leadership EAB Strawman June 17, 2011 THSA Leadership Draft EAB V1.0 June 20, 2011 THSA Leadership / Texas HIEs Draft EAB V1.0 June 25, 2011 THSA Leadership Draft EAB V1.1 June 27, 2011 THSA Leadership Draft EAB V1.2 June 28, 2011 THSA Data Standards Task Force and Technical Architecture Task Force Summary July 27, 2011 THSA Leadership Draft EAB V1.3 August 5, 2011 THSA Collaboration Council Draft EAB V1.3 August 19, 2011 THSA Board of Directors Draft EAB V1.3 Texas Health Authority - 3 - August 19, 2011
3 Texas HIE Vision The state of Texas has selected a de- centralized approach to HIE. Texas has and will continue to have, numerous independent HIEs that may exist at either local or regional levels. Each appropriately certified HIE and Health Information Service Provider (HISP) qualified to provide services to rural Texas will be able to access to the Statewide Health Exchange layer. The THSA anticipates building a Statewide Health Exchange layer that will facilitate the transfer of electronic medical records (EMR) from Local HIE to Local HIE, between Texas Medicaid & Healthcare Partnership (TMHP) and the Texas Department of State Health (DSHS) and Local HIEs, and between the Local HIEs and the Nationwide Health Information Network (NwHIN). The Statewide Health Exchange layer will also provide a gateway for exchanging medical records between HIEs and some neighboring states without having to first pass through NwHIN (i.e. Louisiana, Arkansas, and New Mexico). The anticipated information flow would look like the following, although time and experience may further inform this model: Other Federal Agencies (i.e. VHA, DoD, IHS, CDC, Medicare) Other States Texas Statewide Health Exchange Layer (THSA) Texas Medicaid and State Health Agencies (i.e. TMHP and DSHS) Other State Level Data Sources (i.e. Payers) Local HIE Local HIE Figure 3.1: Texas HIE Vision: Federated HIEs connect to a thin state layer in order to connect to Texas Medicaid, DSHS, NwHIN, and other state level data sources Texas Health Authority - 4 - August 19, 2011
3.1 Texas HIE Capabilities THSA has identified the following capabilities as within the initial scope of the Texas HIE. This document will provide a functional blueprint of the components and interfaces necessary to achieve and support these capabilities: 1. Exchange of Patient Clinical Summaries 2. Electronic Prescribing 3. Electronic Lab Ordering and Results Delivery 4. Electronic Submission of Lab Results to Public Agencies 5. Electronic Submission to Immunization Registries 6. Quality Reporting 7. Audit and Administrative Reporting 3.1.1 Exchange of Patient Clinical Summaries Clinical Summaries contain a data set of patient- centric clinical information. Clinical Summaries should include the following information: patient s name, date of visit, location of visit, symptoms, vitals information, immunizations and medications administered during the visit, prescriptions, follow- up appointments, lab orders, and other important data and observations. This capability would support the electronic storage, transfer, and interoperability of Clinical Summary information between the Texas Local HIEs and other Local HIEs and trading partners. 3.1.2 Electronic Prescribing Electronic Prescribing is the set of services necessary to support online prescription message transport and dispensing for patient prescriptions. This capability includes electronic creation of prescriptions, delivery of those prescriptions to specified pharmacies, filling of the prescriptions, and providing notice when a prescription has been filled. 3.1.3 Electronic Submission of Lab Results to Public Health Agencies An extension of the previous capability, the submission of lab results to public health agencies is often required by state or local governments. At a national level, these public agencies include the U.S. Department of Health and Human (HHS), Veterans Health Administration (VHA), Indian Health (IHS), Center for Disease Control (CDC), and Medicare. 3.1.4 Electronic Submission to Immunization Registries Immunization Registries are a provider and patient- enabled toolset to collect and distribute immunization data across providers. This capability will ensure providers and HIEs can submit immunization records to Immunization Registries. 3.1.5 Quality Reporting Quality Reporting captures the integration of data to support quality measurement, feedback and reporting into Clinical Care Applications, begins to use quality measures to support clinical decision making, and allows for the aggregation of quality information across multiple providers and entities to support reporting of healthcare quality. Texas Health Authority - 5 - August 19, 2011
3.1.6 Audit and Administrative Reporting Audit and Administrative Reporting includes messages and documents that are specifically designed to support management, reporting and investigation in the public health context. This includes messages sent to public health regulatory agencies or other patient safety/quality improvement organizations from outside parties and reporting among health care providers, manufacturers, and public health or patient safety/quality improvement organizations. Texas Health Authority - 6 - August 19, 2011
4 Architecture Guiding Principles Architecture Guiding Principles define a framework and a vision that can be applied to evolving technologies in the. They also define how technology can be implemented as a solution to meet the needs of the business. The solutions must be scalable: The architecture provides a baseline to support future business volume growth requirements. The architecture is able scale both horizontally and vertically to meet system requirements that are defined based on business volumes. While a certain amount of scale is needed, solutions should not be over- sized to account for a lack of planning. The solution builds a strong foundation for the future: The architecture establishes the building blocks on which future capabilities can be built. The architecture framework should provide capabilities that can accommodate existing solutions. The solution provides an approach that lets systems share common functionality for integration: The solution provides common integration and data management services across the group. The architecture is based on common standards: The solution will define consistent standards for integration that can be applied throughout various architectures, whereby definitions are understandable and available to all users. Standards will be defined for reusable software components, software delivery and managing information. The solution provides a secure environment: Confidential data will be kept secure, both at rest and in motion, as it flows across the gateway. Below is a statement of the principles that will be used to guide the development of the THSA Enterprise Architecture Blueprint and will serve as a reference throughout the full lifecycle of the blueprint. Principle Ownership Description - Statewide Health Exchange layer is owned by THSA - Local HIE services and capabilities are owned by the Local HIE and / or the providers who are members of the HIE. In order to connect to the Statewide Health Exchange layer they must receive THSA certification (which is outlined later in this document) Business Transformation Stewardship - THSA has a mandate to change or design new services and capabilities with or without involvement of all or any of the Local HIEs. Any new capabilities defined by THSA will be included in the blueprints - Responsibility for data integrity of various information subjects will be assigned to Local HIEs and they will assume the obligation for making this information available to authorized users - Statewide Health Exchange layer will not host clinical data. Where applicable, the Statewide Health Exchange layer will facilitate or mediate record exchange between HIEs Texas Health Authority - 7 - August 19, 2011
Security Multiform Data Definition Flexibility Scalability Reusability Accessibility - Protection of confidentiality and privacy of information will be included in all architectural considerations - Authority to create and maintain the data will reside with Local HIEs and providers, those most knowledgeable about the data or those most able to control its accuracy - THSA will develop architectures to manage information in all necessary forms (data, text, image) - THSA will define the document format and terminology standards necessary for Local HIEs to interoperate with the Statewide Health Exchange layer - The architecture should be flexible to enable innovation around services and capabilities - The architecture will need to be scalable and allow for easy adoption by Local HIEs - THSA will support the sharing and reuse of common application modules or components across various Local HIEs and also use common environments to increase reusability - Statewide Health Exchange layer will provide the confidentiality, privacy, and security of data and THSA will choose a set of access and messaging capabilities which are standards for healthcare IT Texas Health Authority - 8 - August 19, 2011
5 Assumptions The following assumptions were utilized in drafting the and its application in the depicted Use Cases: Each Local HIE will provide and manage an Enterprise Master Patient Index (EMPI) service A statewide capability for patient identification and matching will be achieved by: o o Defining a common set of patient identifiers each Local HIE will be expected to maintain for patient information within its EMPI, and Providing a Patient Matching Service in the Statewide Health Exchange layer that has the capability to query Local HIE EMPIs (based on the common set of patient identifiers mentioned above) and use those retrieved identifiers to provide a common patient context to the Statewide Health Exchange Layer Each Local HIE within Texas should have a level of Direct Health Information Service Provider (HISP) capabilities and Security Certificate, or contract with partners to provide HISPs supporting Texas HIE will establish trusted relationships between each other to enable Direct- to- HIE messaging communications to and from non- HIE provider participants Each Local HIE or provider hosting Clinical Summary data will provide and manage Patient Consent services protecting the confidentiality and privacy required for the data Patient Consent is not federally mandated for all situations, but may be required by state law. Patient Consent can be obtained in various ways. THSA will provide a set of standards for patient privacy and security. Local HIEs will choose and implement their own solution with respect to Patient Consent, which will be conformant with these standards. THSA plans to have a Statewide Health Exchange layer Document containing a patient identifier and document locations. However, Clinical Summaries and other patient data will reside at the Local HIE or provider levels. Laboratory and immunization data may be stored within the Statewide Health Exchange layer, but should be de- identified and is not intended to contain the patient s name or other sensitive patient demographic data, A Local HIE Document is updated when new records are created in applicable data repositories (i.e. Clinical, Medications, and Laboratory repositories) A new entry is created in the Statewide Health Exchange layer Document each time a new entry is created in a Local HIE Document THSA will determine statewide integration for medication query capabilities that will be supported at the Local HIE level Texas Health Authority - 9 - August 19, 2011
6 Functional Blueprint The Texas HIE solution follows a largely federated approach, with independent Local HIEs that interface with a thin Statewide Health Exchange layer. The functional components of the Texas HIE solution are located at three location types: Provider Organizations, Local HIEs, and the Statewide Health Exchange layer. In this functional blueprint section, these components and services chosen for Texas HIE are mapped to each of those three location types. An explanation of each of these components is also provided in this section. This functional blueprint is divided into three two- year phases. The components and repositories listed in this section and throughout the remainder of this document are logical and may be located across multiple databases and/or physical systems. 6.1 Statewide Health Exchange Layer Components Components of the Statewide Health Exchange layer will be deployed over the course of three two- year phases. The following diagram depicts the components as they are expected to come online in each of those phases. There are three types of components: Integration Layer,, and Database/Repository. Below the diagram is an overview of each of these components. Basic Web Service Adaptors Basic Messaging Adaptors Statewide Health Exchange Layer Integration Bus Enhanced Messaging Adaptors Enhanced Web Service Adaptors Year 1 Security Certificate System Certificates Patient Identification Request Service Record Locator Public Health Public Health DW State Health Portal Immunization Transformation and Translation Lab Reporting Content Based Routing Terminology Patient Consent Patient Defined Access Clinical Data Repository Audit Document 1-2 year plan 3-4 years 5-6 years Key Integration Layer Component Component Database / Repository Figure 6.1: State- Level Components for years 1 2, 3 4, and 5 6 Texas Health Authority - 10 - August 19, 2011
6.1.1 Application and Components 6.1.1.1 Statewide Health Exchange Layer Security Certificate (Year 1): This is a key aspect of security for the Statewide Health Exchange layer. Although it contains other components, the most prominent component of the Security Certificate is the Statewide Health Exchange layer Certificate Authority (CA). A CA issues certificates to trusted users and applications and, in turn, allows for validation that the user or application is trusted when they attempt to access the Statewide Health Exchange layer. Other aspects of the Security Certificate include a Certificate Revocation List (CRL) and an Online Certificate Status Protocol (OCSP) Responder. Patient Identification Request Service (Year 1): Each Local HIE is expected to maintain an Enterprise Master Patient Index (EMPI). Each EMPI is expected to support a common set of patient identifiers (i.e. first name, last name, date of birth, etc.). When a provider queries for a patient s medical history (via a Clinical Care Application), the provider is expected to enter those common identifiers. This query is initially handled by the EMPI of which the Local HIE the provider is a member of. In turn, the Local HIE EMPI routes this request to the Patient Identification Request Service located in the State Health Exchange layer. The Patient Identification Request Service will then query other Local HIE EMPIs using this demographic information and return a list of all the possible matches to the provider. The provider can then use this list to select the correct matches and then request the medical history based on those selections. Please see Appendix A for a communication and data flow for querying patient history using the Patient Identification Request Service, EMPI, and Record Locator Service. Record Locator Service (RLS): The RLS is the application component that receives and stores information in the Document. This service, in the Statewide Health Exchange layer, allows providers who are members of a Local HIE to determine the existence and location of patient documents that are located within other Local HIEs. The RLS does not contain clinical data. Rather, it receives information (i.e. patient identifier and record location, but not actual clinical data) about new patient records created at Local HIEs and stores this information in the Document. A new entry is created in the Statewide Health Exchange layer Document each time a new entry is created in a Local HIE Document. The Statewide Health Exchange layer RLS then delivers location information for documents stored in Document when a request is received from a Local HIE. Public Health : Public Health are the front end to a Public Health Data Warehouse. The Texas HIE program is expected to provide data to public agencies such as the Texas Department of State Health (DSHS), the Department of Defense (DoD), the Veterans Health Administration (VHA), the Indian Health Service (HIS), the Center for Disease Control (CDC), Medicare, and Texas Medicaid. Public Health receive this public health data from Local HIEs, modify the data (i.e. reformat and / or aggregate the data) and store it in a Public Health Data Warehouse. State Health Portal: The State Health Portal allows providers and practitioners to connect to state agencies through a consolidated portal. Potential services could include eligibility/benefits verification (MMIS), Medicaid claim history, patient history, and immunization history. Transformation and Translation : These services include capabilities to transform message syntax structures received and sent between partners to conform to specific and evolving standards. Examples are laboratory results, identified and submitted to a public health biosurveillance and Texas Health Authority - 11 - August 19, 2011
epidemiology service. Note that the vocabulary and terminology services differ as they may transform or map between vocabularies (to standard LOINC codes, for example). Content Based Routing: Content Based routing enables the receiving and processing of messages based on the content of the message itself, rather than by its specified destination. In Content Based routing a set of rules is applied to the message s contents to determine the message s intended destination. This frees the sending application from needing some specifics about where a message is headed and helps to ensure message delivery. Content based routing is an important aspect of flexible IT systems. Patient Consent : Patient Consent allow the Statewide Health Exchange layer to enforce privacy for patient medical data (i.e. Clinical Summaries). The foundation of Patient Consent is called Basic Patient Privacy Consents (BPPC). BPPC provides a mechanism to record the patient s privacy consent(s) and a method for the Texas HIE to use to enforce the privacy consent appropriate to the use. The Patient Consent store privacy consent information in the Patient Defined Access Repository. (Patient Consent for Local HIEs is defined in Section 6.2.) 6.1.2 Database and Repository Components 6.1.2.1 Statewide Health Exchange Layer System Certificates (Year 1): The System Certificates repository contains the certificates utilized by the Security Certificate to authenticate users and applications at the Statewide Health Exchange layer. Document : The Document is the data repository which contains an identifier and location of documents of patients stored in the Local HIEs. It does not contain clinical data. Data is populated in the Document by the RLS. When the RLS is notified of a new document, a patient identifier and the location of the document are stored by the RLS into the Document. When a provider queries for documents of a given patient the RLS will search this registry and returns a list of documents and their locations found for that patient that are located in the Local HIEs. Audit: The Audit repository contains the data for required Audit reporting. Public Health Data Warehouse: A Public Health Data Warehouse is the repository for information stored by the Public Health. The Public Health store information that the Texas HIE is expected to provide to Public Agencies in a Public Health Data Warehouse. When a public agency seeks to retrieve public health data from the Texas HIE, a Public Health Data Warehouse is queried and provides this data. Immunization : Immunization Registries are confidential, population- based, computerized information systems that attempt to collect vaccination data about all children within a geographic area. It is an important tool to increase and sustain high vaccination coverage by consolidating vaccination records of children from multiple providers, generating reminder and recall vaccination notices for each child, and providing official vaccination forms and vaccination coverage assessments. Lab Reporting Repository: The Lap Reporting Repository contains all data associated with lab reporting (orders and results). The repository provides the data for the electronic format for the laboratory reports (making it human readable and machine readable). Examples of when the Lab Reporting Repository is used includes a laboratory report obtained from a laboratory, a healthcare institution produces a cumulative report of all laboratory tests performed for the patient during the encounter or a public health laboratory shares its reports into a regional repository. Texas Health Authority - 12 - August 19, 2011
Terminology Repository: The Terminology Repository contains a set of approved or standardized vocabulary for accurately describing human anatomy, medical diagnosis and procedures, and medicines, among other things, that should be used within the Texas HIE. Frequently, terminologies are updated and new terms are added to the existing set. Therefore, it is important to have a repository containing an up to date set of terminology. In the first two years of Texas HIE, Terminology Repositories will be managed by the Local HIEs. In years three to four a Statewide Health Exchange layer Terminology Repository will be introduced. Patient Defined Access Repository: The Patient Defined Access Repository contains information stored in it by the Patient Consent. This data in this repository consists of patient privacy consent information for patient documents stored in the Statewide Health Exchange layer. Clinical Data Repository: A Clinical Data Repository (CDR) is a real time database that consolidates data from a variety of clinical sources to present a unified view of a single patient. It is optimized to allow clinicians to retrieve data for a single patient rather than to identify a population of patients with common characteristics or to facilitate the management of a specific clinical department. Typical data types which are often found within a CDR include: clinical laboratory test results, patient demographics, pharmacy information, radiology reports and images, pathology reports, hospital admission, discharge and transfer dates, ICD- 9 codes, discharge summaries, and progress notes. 6.1.3 Integration Layer Components 6.1.3.1 Statewide Health Exchange Layer Integration Bus: The Integration Bus provides an abstraction layer on top of an implementation of an enterprise messaging system, and acts as a message broker between applications. It provides fundamental services for complex architectures via an event- driven and standards- based messaging engine (the bus). Developers typically implement an ESB using technologies found in a category of middleware infrastructure products, usually based on recognized standards. Basic Web Service Adaptors: Web adapters allow a consistent, standardized Web layer of connections to applications that that were not originally developed with Web in mind, or have non- conformant service layers. Basic Messaging Adaptors: Basic Messaging Adaptors allow communication of types of messages between applications. In general, Messaging Adaptors map messages to API calls and API call responses back to messages once the receiving application has processed the API call. Enhanced Web Service Adaptors: These include adaptors for wrapping the basic HIE functional components (EMPI, RLS, data repositories) as well as adaptors to include future capabilities such as advanced alerts, public health capabilities, advanced patient consent and workflow, etc. Some of these future capabilities may not be known yet, and may require more complex types of interaction. Enhanced Messaging Adaptors: These include adaptors for accommodating new standard types of content and messaging beyond the currently established messaging standards. Future areas of messaging and content types such as biometric identification, device monitoring and others may be required with complex types of interaction. Texas Health Authority - 13 - August 19, 2011
6.2 Local HIE and Provider Organization Components Components of the Local HIEs and Provider Organizations will be deployed over the course of three two- year phases. The following diagram depicts the components as they will come online in each of those phases. There are three types of components: Integration Layer,, and Database / Repository. Below the diagram is an overview of each of these components. 1 2 Years 5 6 Years 3 4 Years Provider Organizations Clinical Care Applications Business Applications Other Applications Emerging Applications Basic Messaging Adaptors Basic Web Service Adaptors Local Integration to Regional HIE Local HIEs / Large Providers EMPI Laboratory Repository Document Provider Directory Security Certificate Service Clinical Documentation Repository Medications Repository Business Intelligence Emerging Applications Patient Consent Record Locator Service Administrative Repository Terminology Basic Messaging Adaptors Basic Web Service Adaptors Statewide Health Exchange Layer Integration Bus Enhanced Messaging Adaptors Enhanced Web Service Adaptors Statewide Health Exchange Layer Security Certificate System Certificates State Health Portal Content Based Routing Immunization Terminology Patient Defined Access Patient Identification Request Service Audit Patient Consent Public Health Transformation and Translation Lab Reporting Public Health DW Clinical Data Repository Record Locator Document Figure 6.2: Provider Organization and Local HIE components for years 1 2, 3 4, and 5 6 6.2.1 Application and Components 6.2.1.1 Statewide Health Exchange Layer The following components are included in the Statewide Health Exchange Layer. Please reference Section 6.1 for details regarding the below components: Security Certificate Patient Identification Request Service Record Locator Service State Health Portal Public Health Content Based Routing Transformation and Translation Patient Consent Texas Health Authority - 14 - August 19, 2011
6.2.1.2 Local HIEs and Large Providers Enterprise Master Patient Index (EMPI): The EMPI contains a list of patients and unique patient identifiers for each patient who has received services in the Local HIE. Using the patient identifier located in the EMPI, a provider can locate a patient s identifier number and use this to submit a request via the Clinical Care Application to locate and retrieve a patient s health records (i.e. Clinical Summaries) located in the Texas HIE. EMPIs will also be queried by the Patient Identity Request Service which is located in the State Health Exchange layer. Provider Directory: The Provider Directory contains healthcare provider information for all providers (individuals and organizations) in the Local HIE. Typical provider information maintained by the directory is demographics, address, credential and specialty information as well as the provider s electronic endpoint to facilitate trusted communications with a provider. The directory can also maintain relationship information. Some examples of relationship are: a Health Information Exchange (HIE) and its members: Integrated Delivery Networks and their care delivery members, hospitals and their practitioners, hospitals and their sub organizations including departments, physician Practice Groups and their practitioners, practitioners and the hospitals they are associated with (members of), and Medical Associations and their members. Record Locator Service (RLS): The RLS is the application component that receives and stores information in the Document. This service, at the Local HIE level, allows providers who are members of the Local HIE to determine the existence and location of patient documents that exist in their Local HIE. In addition, the Local HIE RLS can forward document requests to the Statewide Health Exchange layer RLS to identify patient records located within other Local HIEs. The RLS does not contain clinical data. Rather, it receives information (i.e. patient identifier and record location, but not actual clinical data) about new patient records created in the Local HIE and stores these in the Local HIE Document. It then delivers location information for documents stored in Document when a request is received. Security Certificate : This is a key aspect of security for the Local HIE. Although it contains other components, the most prominent component of the Security Certificate is the Local HIE Certificate Authority (CA). A CA issues certificates to trusted users and applications and, in turn, allows for validation that the user or application is trusted when they attempt to access the Statewide Health Exchange layer. Other aspects of the Security Certificate include a Certificate Revocation List (CRL) and an Online Certificate Status Protocol (OCSP) Responder. Patient Consent : Patient Consent allow the Local HIE to enforce privacy for patient medical data (i.e. Clinical Summaries). The foundation of Patient Consent is called Basic Patient Privacy Consents (BPPC). BPPC provides a mechanism to record the patient s privacy consent(s) and a method for the Texas HIE to use to enforce the privacy consent appropriate to the use. The Patient Consent store privacy consent information in the Patient Defined Access Repository. Business Intelligence (BI): The BI component is an application or set of applications to retrieve, analyze and report data meaningful to the Texas HIE program. Two functions of the Local HIE BI component are to compile and send Laboratory Results and also Immunization data to the Public Health Service (which stores this information in the Public Health Data Warehouse). Emerging Applications: Emerging Applications include applications, components, systems, and potentially new processes and standards which are in development, in their infancy, or not yet adopted by most HIEs. Texas Health Authority - 15 - August 19, 2011
6.2.1.3 Provider Organizations Clinical Care Applications: A Clinical Care Application allows providers to create, manage and view Clinical Summary records. The most basic Clinical Care Applications allow providers to produce and use Clinical Summary records. In addition, Clinical Care Applications can facilitate eprescribing, care management, provider messaging, clinical analytics, and interfacing with laboratories. Business Applications: Business Applications allow providers to submit claims, generate referrals, inquire into patient eligibility, schedule appointments, and produce analytical information. Other Applications: In this case, Other Applications refers to a set of applications necessary to the Texas HIE, but not falling directly into the Clinical Care or Business Applications categories such as Electronic Transmission of Prescriptions (ETP), Laboratory Information Systems (LIS), and pharmacy applications. Emerging Applications: Emerging Applications include applications, components, systems, and potentially new processes and standards which are in development, in their infancy, or not yet adopted by most providers. 6.2.2 Database and Repository Components 6.2.2.1 Statewide Health Exchange Layer The following components are included in the Statewide Health Exchange Layer. Please reference Section 6.1 for details regarding the below components: System Certificates Audit Document Immunization Lab Reporting Terminology Public Health Data Warehouse Patient Defined Access Clinical Data Repository 6.2.2.2 Local HIEs and Large Providers Laboratory Repository: The Laboratory Repository contains data pertaining to Lab Orders submitted via the Clinical Care Application and Lab Results returned from the Laboratory Information System. It can be queried by the Local HIE via the Clinical Care Application and by other Local HIEs retrieving patient documents. Clinical Documentation Repository: The Clinical Documentation Repository contains data pertaining to Clinical Summaries and immunization records stored in the Immunization, both submitted via the Clinical Care Application. It can be queried by the Local HIE via the Clinical Care Application and by other Local HIEs retrieving patient documents. Document : The Document is the data repository which contains an identifier and location of documents of patients stored in the Local HIE. It does not contain clinical data. Data in the Local HIE Document is populated in the by the RLS. When the RLS is notified of a new document by the Clinical Care Application, a patient identifier and the location of the document are stored by the RLS into the Document. When a provider queries for documents of a given Texas Health Authority - 16 - August 19, 2011
patient the RLS will search this registry and returns a list of documents and their locations found for that patient that are located in that Local HIE. Medication Repository: The Medication Repository contains each patient s medication history including active medications, along with pertinent diagnosis, start and stop dates, ordering providers, frequency of use, and is matched using the national drug code (NDC) id as the standard for passing between clinical information systems. Administrative Repository: This repository is utilized for Audit and Administrative Reporting. Audit and Administrative Reporting includes messages and documents that are specifically designed to support management, reporting and investigation in the public health context. This includes messages sent to public health regulatory agencies or other patient safety/quality improvement organizations from outside parties and reporting among health care providers, manufacturers, and public health or patient safety/quality improvement organizations. Terminology Repository: The Terminology Repository contains a set of approved or standardized vocabulary for accurately describing human anatomy, medical diagnosis and procedures, and medicines, among other things, that should be used within the Texas HIE. Frequently, terminologies are updated and new terms are added to the existing set. Therefore, it is important to have a repository containing an up to date set of terminology. In the first two years of Texas HIE, Terminology Repositories will be managed by the Local HIEs. In years three to four a Statewide Health Exchange layer Terminology Repository will be introduced. 6.2.3 Integration Layer Components 6.2.3.1 Statewide Health Exchange Layer The following components are included in the Statewide Health Exchange Layer. Please reference Section 6.1 for details regarding the below components: Integration Bus Basic Messaging Adaptors Basic Web Service Adaptors Enhanced Messaging Adaptors Enhanced Web Service Adaptors 6.2.3.2 Local HIEs and Large Providers Integration Bus: The Integration Bus provides an abstraction layer on top of an implementation of an enterprise messaging system, and acts as a message broker between applications. It provides fundamental services for complex architectures via an event- driven and standards- based messaging engine (the bus). Developers typically implement an ESB using technologies found in a category of middleware infrastructure products, usually based on recognized standards. Basic Web Service Adaptors: Web adapters allow a consistent, standardized Web layer of connections to applications that that were not originally developed with Web in mind, or have non- conformant service layers. Basic Messaging Adaptors: Basic Messaging Adaptors allow communication of types of messages between applications. In general, Messaging Adaptors map messages to API calls, and API call responses back to messages once the receiving application has processed the API call. Texas Health Authority - 17 - August 19, 2011
6.3 Functional Blueprint: Years 1 2 In the first two years of statewide Texas HIE a number of key components are expected to be deployed by provider organizations, Local HIEs, and the Statewide Health Exchange layer. The main purposes of these components are to meet three of the desired capabilities of Texas HIE. These include: Exchange of Patient Clinical Summaries Electronic Lab Ordering and Results Delivery Electronic Prescribing Above in this document, these components were briefly outlined. The following diagram provides a more detailed look at some of these components and what constitutes them. Below is an overview of these underlying components. Provider Organizations Local HIEs / Large Providers Statewide Health Exchange Layer Clinical Care Applications Medical Summary eprescribing Care Management Provider Messaging Clinical Analytics Lab Interface ETP Application (Third Party) Laboratory Information System Pharmacy Application Business Applications Referral Generation Claims Submission Provider Credentialing Business Analytics Eligibility & Auth Inquiry Universal Scheduling Basic Messaging Adaptors Basic Web Service Adaptors Local HIE Integration Bus Laboratory Medications Clinical Documentation Administrative Orders Results ETP (Prescriptions) Pharmacy (Dispensing) Clinical Summaries Immunization Audit Administrative Reporting Quality Reporting EMPI Provider Directory Record Locator Service Security Certificate Patient Consent Basic Messaging Adaptors Basic Web Service Adaptors Statewide Health Exchange Layer Integration Bus Certificate Authority Patient Identification Request Service Security Certificate Certificate Revocation List Record Locator Indexing Online Certificate Status Protocol Responder Metadata Document System Certificates Audit Document Terminology 6.3.1 Application and Components Figure 6.3: Functional Blueprint for years 1 and 2 6.3.1.1 Statewide Health Exchange Layer Security Certificate, Certificate Authority: A CA issues digital certificates to trusted users and applications and, in turn, allows for validation that the user or application is trusted when they attempt to access the Statewide Health Exchange layer and Local HIEs. The CA can be a trusted third party vendor. Texas Health Authority - 18 - August 19, 2011
Security Certificate, Certificate Revocation List: A CRL is a file that contains a list of certificates that have been revoked. For each certificate it contains serial numbers and a revocation date. A CRL file also contains the name of the issuer of the CRL, the effective date, and the next update date. By default, the shortest validity period of a CRL is one hour. Security Certificate, Online Certificate Status Protocol Responder: The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders. The following components are included in the Statewide Health Exchange Layer as well. Please reference Section 6.1 for details regarding the below components: Patient Identification Request Service Record Locator Service (RLS) 6.3.1.2 Local HIEs and Large Providers The following components are included as part of Local HIE/Large Providers. Please reference Section 6.2 for details regarding the below components: Enterprise Master Patient Index (EMPI) Provider Directory Record Locator Service Security Certificate Patient Consent 6.3.1.3 Provider Organizations Medical Summary: The Medical Summary component of the Clinical Care Application allows providers to create Clinical Summary documents and store them into the Local HIE Clinical Summaries repository. Once in the Clinical Summaries repository, other providers connected to the Texas HIE can view these documents. eprescribing: The eprescribing component of the Clinical Care Application allows providers to interface with an Electronic Transmission of Prescription (ETP) application in order for the prescriber to electronically submit a prescription to pharmacy. The ETP application replaces a paper prescription that the patient would otherwise carry or fax to the pharmacy. It is believed to improve patient safety by reducing the possibility of a prescribing error due to various causes including poor handwriting or ambiguous nomenclature. Examples of universal eprescribing clearinghouses in the US include RxHub and Surescripts. Many Clinical Summary Applications send their prescriptions through these interfaces to the end pharmacy. Care Management: The Care Management component of the Clinical Care Application allows providers to exchange of information between HIT systems and applications used to manage care for specific conditions. Examples of these systems include Cancer Registries, Chronic Disease Management Systems, Disease Registries and Immunization Information Systems. Provider Messaging: Provider messaging includes secure messages sent from provider to provider. Providers could also benefit from message based prompts and reminders, initiated by other clinicians Texas Health Authority - 19 - August 19, 2011
and their staff. Messaging between providers need to be delivered using messages that are communicated in a secure sending and receiving environment, also known as a secured communication channel. Clinical Analytics: The Clinical Analytics component of the Clinical Care Application allows providers to make extensive use of data for statistical and qualitative analysis as well as explanatory and predictive modeling. Lab Interface: The Lab Interface component of the Clinical Care Application allows providers to create Lab Order records and store them into the Local HIE Laboratory repository. Once the Lab Order records are in the Laboratory repository, connected labs will receive these Lab Orders via a Laboratory Information System (LIS). Via the LIS, the lab can submit results of the test to the Lab Results repository. The Lab Interface allows the Clinical Care Application to retrieve the Lab Results for review by the provider. Referral Generation: The referral component of the Business Application allows providers to select a specialty provider, document the reason for the referral request, notate the level of urgency, include any necessary supporting documentation, along with recent results from lab or diagnostic tests and send directly to the specialty provider for appointment and consults either electronically, via fax and/or through the generation of a standard letter. Claims Submission: The claims submission component of the Business Application is the means by which a provider is reimbursed for services. The submission of a claim through a contracted clearing house allows provider organizations the ability to have a limited number of electronic interfaces but a large number of contracted relationships with Health Plans for reimbursement of services. Provider Credentialing: In order for a provider to be reimbursed for services rendered to patients, that provider must first be credentialed with the Health Plan under which the patient is covered. This credentialing process and management activity includes tracking of provider licenses and expirations, national provider id information, tax id number and includes reminders to the administrative department of when a provider needs to update their license and attend certified medical education (CME) classes to maintain their license. Business Analytics: Business analytics allows providers and their respective practices to monitor and track their cost of services against the reimbursements to effectively manage their business. Large provider groups use the financial information to analyze opportunities for new services, negotiations of reimbursement rates with Health Plans, and compensation to their providers using relative value units (RVU). Eligibility and Authentication Inquiry: This eligibility verification part of this function is used to ensure the patient is properly covered by a health plan prior to performing services, along with gaining an understanding of the medication formulary that patient s plan prefers. This is a real time validation process with the plans typically through a third party supplier. Many health plans require prior authorization for services, especially those involving hospital stays, in order to ensure the member is staying within the defined guidelines. Specialty providers request authorization from health plans and record the authorization number prior to performing services to ensure reimbursement from the health plans. Universal Scheduling: This business function permits centralized schedulers the ability to appoint a patient into the continuum of care, from primary care services to specialty and hospital bookings. Electronic Transmission of Prescriptions (ETP) Application: The eprescribing component of the Clinical Care Application allows providers to interface with an Electronic Transmission of Prescription (ETP) Texas Health Authority - 20 - August 19, 2011