Platform for interoperable healthcare data exchange

CROSS REFERENCE TO RELATED APPLICATIONS

0001This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Application No. 60/759,015 filed on Jan. 17, 2006, and U.S. Provisional Application No. 60/777,147 filed on Feb. 28, 2006 the subject matter of which is hereby incorporated by reference in full.

FIELD OF THE INVENTION

0002The present invention generally relates to an interoperable healthcare data exchange platform. More specifically, embodiments of the present invention provide a system and related method for seamlessly linking a plurality of disparate, remote health records sources to enable the real-time collection, processing and centralized storage of health records, along with enabling controlled access to the centralized storage.

BACKGROUND OF THE INVENTION

0003In April 2004, in Executive Order 13335, President George W. Bush revealed his vision for the future of health care in the United States. The President's plan involves a health care system that puts the needs of the patient first, is more efficient, and is cost effective. This plan is based on the following tenets: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0004"> Medical information follows consumers (patients) so that they are at the center of their own care </li><li id="ul0002-0002" num="0005"> Consumers (patients) choose physicians and hospitals based on clinical performance results made available to them </li><li id="ul0002-0003" num="0006"> Clinicians have consumers' (patients') complete medical history, computerized ordering systems, and electronic reminders </li><li id="ul0002-0004" num="0007"> Quality initiatives measure performance and support quality-based competition in the industry </li><li id="ul0002-0005" num="0008"> Public health and bioterrorism surveillance is seamlessly integrated into care </li><li id="ul0002-0006" num="0009"> Clinical research is accelerated and post-marketing surveillance will be expanded. </li></ul></li></ul>

0010In order to achieve these and other desired benefits, the President has charged the Secretary of the Department of Health and Human Services (DHHS) with executing this vision and established the Office of the National Coordinator for Health Information Technology (ONCHIT) to develop and maintain a strategic plan to guide the nationwide implementation of interoperable Electronic Health Records (EHRs) in both the public and private health care sectors to facilitate health information exchange. A fully functional platform for health information exchange deployed on a regional or national basis could provide the framework for authorized, secure, timely, and accurate exchanges of health information among patients, clinicians and other providers and authorized entities.

0011A fully functional platform for health information exchange deployed on a regional or national basis could provide the framework for authorized, secure, timely, and accurate exchanges of health information among patients, clinicians and other providers and authorized entities. The solution proposed in the present invention, as described below, will allow the widespread exchange of health care information by maximizing interoperability among health care software applications, particularly EHRs. This approach could be used in support of a National Health Information Network (NHIN) or support Regional Health Information Organizations (RHIOs) and Regional Health Communities (RHCs).

0012At the same time, the global market for Health IT is large and expected to grow rapidly. Of that, likely half will be spent on EMR/EHR capabilities. US estimates of wide scale implementation of EMR/EHR range from $156 to $280 Billion in total investment over a 5 to 10 year period with between $16-48 Billion spent per year thereafter. Estimates of EMEA market potential developed for select target countries by ACN leadership suggest a cumulative $10 Billion opportunity for eHealth (EMR/EHR/Back-office) over the next five years, likely peaking in 2007-2009, with additional applications extending well beyond these dates. Likewise additional opportunities exist in other markets and countries.

0013There are many different suppliers to the healthcare market, and these include offerings from mainstream vendors, and also specialized, boutique providers to the health industry. Most current products are specific to a care domain, or provide an extremely “thin” layer of functionality across a care setting. Other products are specific to the underlying architecture and provide, typically, standards based interface to a vendor's business logic and architecture. There is a need for a truly flexible “middleware” architecture that is agnostic to underlying architectures, whilst being able to interface to both existing systems and newly developed technologies in a secure, robust manner protecting both the privacy of patients, and the integrity of the care process.

0014Healthcare technologies have expanded over the last 25 years typically in an organic manner. This has meant that technologies have developed at the same pace as healthcare, with associated advances in specific areas. To date, technology vendors have addressed their forays into healthcare through the interfacing with existing platforms, or the development of functionality that simply replicates that which is currently offered by competitive vendors. Innovation, such as it is, is led by clinical need rather than technological capability, and, treatment of the healthcare enterprise as a single domain has not occurred.

0015The healthcare market is a global one, whereas healthcare provision is by necessity regional, and there are few truly country (or nation) wide providers of healthcare. However, political motivations, based upon an understanding of technological potency, are driving the need for an enterprise approach to healthcare that pushes the boundaries of existing technologies. Indeed, the drive for a truly national healthcare record is one that will require extensive innovation and evolution of current technologies with novel approaches being required to seemingly intractable problems.

0016While other countries, including the United Kingdom and Australia, have attempted to create a national, centralized medical record repository, these efforts have met mixed results. Furthermore, the methods employed in other countries partially rely on state control of health facilities, thereby allowing systemic harmonization of health records which is not possible in the United States where the privately created health records may have varying formats and contents. Moreover these previous solutions could not be scaled to operate with the significantly larger number of medical records in the United States, the world's largest health care market.

0017To accomplish the goals of exchanging authorized, secure, timely, and accurate health information, many organizational, political and technical challenges need to be overcome. Specifically, a successful health information exchange should: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0018"> address organizational issues such as privacy, security, data ownership, and change management, in addition to technical issues </li><li id="ul0004-0002" num="0019"> effectively merge patient records from multiple sources and avoid duplicate records that result in increased errors and decrease information availability </li><li id="ul0004-0003" num="0020"> support the ability to aggregate data from multiple, different clinical systems and EHRs within and across regional health communities by using common acquisition, interoperability, transformation and normalization processes </li><li id="ul0004-0004" num="0021"> have a security and access architecture to facilitate trust, auditing and cross-domain data access management </li><li id="ul0004-0005" num="0022"> have a robust data model and de-identification/re-identification capabilities that support data analysis and evidence-based health query capabilities </li><li id="ul0004-0006" num="0023"> be able to support the addition of new applications and transactional systems in a scalable and cost effective manner, and </li><li id="ul0004-0007" num="0024"> be flexible to support rapid program changes <br /> By effectively addressing these issues, the delivery of health care can be dramatically improved. </li></ul></li></ul>

SUMMARY OF THE INVENTION

0025The solution described herein documents a novel approach to building and deploying a technology platform that enables the exchange of semantically normalized data between different health care institutions. Embodiments of the present invention provide a system and related method for seamlessly linking a plurality of disparate, remote health records sources to enable the real-time collection, processing and centralized storage of health records, along with enabling controlled access to the centralized storage. This platform can be used to support clinical care at the regional or national level, public health surveillance, clinical trials, drug monitoring, care management initiatives, ePrescriptions, and other health care processes.

0026The interoperable healthcare data exchange platform seamlessly links a plurality of disparate, remote applications generally representing provider systems containing electronic health records (EHRs) to enable the real-time collection, processing and centralized storage of health records at a data store, along with enabling controlled access to the centralized storage.

0027The central health records data store receives, in real time, substantially complete messages containing electronic medical data input from multiple, disparate providers and sources of health records. Embodiments of the platform enable semantic normalization of the health records by converting the data in the health records to standardized message formats using a data conversion engine and mapping the converted data to standard terminologies (such as FHA terminology standards) using mapping products. This data store may be located at any convenient place and provides storage as well as programmatic contributions to the operation of the system.

0028In embodiments of the present invention, the platform provides security and privacy of protected health information through an integrated approach that provides a workable way to obtain sensitive patient information and to facilitate control by the patient to her information for all healthcare purposes, not solely direct clinical care. The platform is flexible and scalable to provide interoperable security and access architecture as need to provide auditing and cross domain access management, as well as role-based access control that provides for different organizational structures, privilege authorization, as well as patient-provider relationships which reflect the direct care relationship between a patient and their care providers (or groups of providers) including, the wider health and social care team, and also facilitating patients to specify those who they wish to have access to their care record.

BRIEF DESCRIPTION OF THE DRAWINGS

0029A more complete understanding of the present invention and advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings in which like reference numbers indicate like features, and wherein:

0030FIGS. <b>1</b>A and <b>2</b>-<b>3</b> are a high-level schematic diagram of an interoperable healthcare data exchange platform accordance with embodiments of the present invention;

0031<figref idref="DRAWINGS">FIG. 1B</figref> depicts high-level schematic diagram of a secure data output system for the an interoperable healthcare data exchange platform of FIGS. <b>1</b>A and <b>2</b>-<b>3</b> in accordance with embodiments of the present invention;

0032<figref idref="DRAWINGS">FIGS. 4-7</figref> are a high-level schematic diagram of an interoperable healthcare data exchange platform in accordance with embodiments of the present invention; and

0033<figref idref="DRAWINGS">FIG. 8</figref> is a schematic diagram of a health data collection network in accordance with embodiments of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0034<figref idref="DRAWINGS">FIG. 1</figref> depicts an interoperable healthcare data exchange network <b>500</b> of the present invention and its component parts. Specifically, the network <b>500</b>. As described in greater detail below, the network <b>500</b> collects health care data from multiple disparate electronic health records (EHR) systems <b>510</b> at various locations. The EHRs, for example, may be associated with doctors, hospitals, other treatment centers, insurance companies, etc. Consequently, the various EHR systems <b>510</b> store the EHR in different formats and protocols. In response, in the network <b>500</b>, each of the EHR systems <b>510</b> has an associated interface adapter <b>515</b> for preparing and standardizing the EHR for transmission to a messaging handling server <b>520</b>. For example, interface adapter <b>515</b> may adapt the EHRs to Health Language 7 (HL7), version 3, a standardized XML schema for the transmission and processing of health records, described in greater detail below. The a messaging handling server <b>520</b> receives the standardized EHRs and forwards the standardized EHRs to regional clinical data servers <b>530</b>, using advanced database techniques to store and organize the standardized EHRs to allow the stored, standardized EHRs to be accessed and processed as needed to achieve desired results, for example through a secondary use server <b>540</b> that is programmed, as described below to extract meaningful data. Similarly, a centralized public health records <b>550</b> may aggregate the health records from the various clinical data servers <b>530</b>. These and other aspects of the present invention are described in greater detail below.

0035FIGS. <b>1</b>A-B and <b>2</b>-<b>3</b> comprises a general overview of the interoperable healthcare data exchange platform <b>100</b> of the present invention and its component parts. The interoperable healthcare data exchange platform <b>100</b> seamlessly links a plurality of disparate, remote General Practice (GP) applications <b>110</b> generally representing provider systems containing electronic health records (EHRs) <b>120</b> to enable the real-time collection, processing and centralized storage of health records at a data store <b>160</b>, along with enabling controlled access to the centralized storage.

0036As described in greater detail below, the platform <b>100</b> provides novel methods and software to partition and manage data, to maintain performance, and to protect the integrity of the data. The platform <b>100</b> may include, for example, information governance software <b>101</b> control access to stored data <b>165</b> and to verify the accurate transfer and storage of medical data <b>120</b>; operations architecture <b>102</b> and infrastructure <b>103</b> to reliably implement the harmonizing data conversion and mapping, storage, and access; and development architecture <b>104</b> to allow users to implement and modify the platform <b>100</b> as needed.

0037Briefly, the central health records data store <b>160</b> receives, in real time, messages containing electronic medical data <b>120</b> input from multiple of general purpose (GP) applications <b>110</b> representing various, disparate providers and sources of health records <b>120</b>. As described in greater detail below, embodiments of the platform <b>100</b> enable semantic normalization of the health records <b>120</b> by converting the data in the health records <b>120</b> to standardized message formats using a data conversion engine <b>130</b> and mapping the converted data to standard terminologies (FHA terminology standards) using mapping products <b>150</b>.

0038In this way, the platform <b>100</b> optionally provides a data capture workflow to capture data at the provider location (represented by the GP applications <b>110</b>) using tools and workflow with structured data to allow input of relevant demographic or clinical data for patients. For example, the platform <b>100</b> may allow providers to input relevant clinical data using their existing electronic medical records (EMR) systems. Typically, a provider enters data <b>120</b> into the GP application <b>110</b>. This entry is documented in their system as an “episode,” and the episode generates a message to an associated data store <b>160</b> such as a RHIO. Using the techniques described herein, an extract of the information added may be sent to the home RHIO and stored. Specifically, as described below, the platform <b>100</b> sends the episode data through various interface engines <b>130</b> to normalize the data <b>120</b> and integrate this captured data <b>120</b> into the repository <b>160</b>.

0039In embodiments of the present invention, the data store <b>160</b> may comprise a series of linked servers or groups of separate servers, each of which is allocated to received health records for storage and access from a finite or defined group of patients, e.g., all patients within a certain range of social security numbers; all patients from a geographic region, etc.

0040The data store <b>160</b> may be located at any convenient place and provides memory as well as programmatic contributions to the operation of the system. Also, there may be multiple data stores <b>160</b>. For example, in one implementation of the present invention, a data store is associated with a RHIO such that health records <b>120</b> within a region are collected by that data store <b>160</b>. Then multiple data stores <b>160</b>, each associated with a different RHIO, may combine to provide medical records <b>120</b> to a master data store <b>160</b> at a national health record repository at a National Health Information Network (NHIN).

0041It should be appreciated that a significant number of GP applications <b>110</b> may thus be involved in the platform <b>100</b>. The platform <b>100</b> does not typically limit the number of providers that may communicate with and submit health records on a patient-by-patient basis to the health record data store <b>160</b>. As described in greater detail below, each one of the GP applications <b>110</b> will provide unique medical information to the data store <b>160</b> through a network such as the Internet or a dedicated network or other network means.

0042The GP application <b>110</b> may constitute a health provider's or hospital's patient records that may include, for example, demographic and biographical data about the patients, a listing of each patient's symptoms; and another listing of the various courses of treatment administered to each of the patients, including the various prescribed procedures, tests, and drugs; a listing the doctors treating the patients. Similarly, the GP application <b>110</b> may be a combination of various general purpose applications used at the hospital, such as a combination of (1) a patient intake tool to acquire the biographical data and a listing of each patient's symptoms; and (2) a hospital billing program that tracks the courses of treatment administered to each of the patients and a listing the doctors treating the patients.

0043Furthermore, it should be appreciated that health records <b>120</b> may come from different GP applications <b>110</b> operating at different locations. Other examples of GP applications <b>110</b> that provide the health records <b>120</b> may include medical testing data software at a medical lab, prescription dispensing data software at a pharmacy, account and payment software from a public health care agency or an insurance company.

0044Thus, it should be appreciated that the patent records <b>120</b> obtained from the GP applications <b>110</b> may be quite complex and large. Also, since the patent records <b>120</b> come from <b>120</b> may be wildly different in format, style, and content. One may readily appreciate that health records <b>120</b> from GP applications <b>110</b> at different providers may be drastically different in format and content, let alone health records <b>120</b> from different GP applications <b>110</b> such as medical billing and medical testing software. Thus, aspects of the platform <b>100</b> entail converting the various health records <b>120</b> into a common format, and then processing the normalized health records <b>120</b> to allow meaningful access and use of the health records <b>120</b>. For example, the platform <b>100</b> may allow an emergency room health care provider to access the data store <b>160</b> to acquire a new patient's stored health care records data <b>120</b> to better treat the patient.

0045The manner in which that information is provided to the central server <b>110</b> is now disclosed in greater detail. Referring back to FIGS. <b>1</b>A and <b>2</b>-<b>3</b>, a message handling service <b>130</b> regulates the transfer of the health records <b>120</b> between the provider GP application <b>110</b> and the data store <b>160</b>. One example of a commercially available message handling service is Cloverleaf by Quovadx of Greenwood Village, Colo.

0046The message handling service <b>130</b> administers the detection and forwarding of the new health records <b>120</b> from the GP application <b>110</b> to the data store <b>160</b>. For example, the message handling service <b>130</b> may detect new health records <b>120</b> at the GP application <b>110</b>, and then forwards a request to have the GP application <b>110</b> forward the new health record <b>120</b>. Likewise, to better manage the production environment, the message handling service <b>130</b> may allow users to monitor message flow and to define proactive alerts. In embodiments of the present invention, the message handling service <b>130</b> is recoverable and can be configured to save a copy of a message in an internal work queue, database or file so that message are not lost.

0047One aspect of the message handling service <b>130</b> may reside at the provider location with the GP application <b>110</b>. As described above, the GP application <b>110</b> typically stores the health records <b>120</b> in various formats. In other words, each of the GP applications <b>110</b> natively stores and transmits its data records <b>120</b> in a different format. In response to this problem, the message handling service <b>130</b> enabled powerful application level integration using a library of application integration adapters, where each of the GP applications <b>110</b> has one or more appropriate associated adapters to transform transmitted health records <b>120</b> into a standard message format for data transfer such as extended meta language (XML) or Health Level 7 (HL7). In this way, the message handling service <b>130</b> is an interface to allow for automatic import of health records into centralized patient records at the data store <b>160</b> via standard protocols (HL7, XML). For example, <figref idref="DRAWINGS">FIGS. 2 and 3</figref> suggest data conversion to HL7v3 (United Stated version) or other future versions of HL7 from various other known formats such as HL7v2, Edifact, HL7v3 (United Kingdom Version), HL7v3 (Australian Version), Dicom, X12N, NCPDP.

0048In this way, the platform <b>100</b> enables the extraction of data from multiple disparate sources in the healthcare value chain (such as Providers, Commissioners, Payors, Laboratories and Pharmacy Benefit Managers (PBMs)), agnostic to input systems, “at scale”, and regardless of terminology codes used or geography, via interfacing engines.

0049The term “standardized output” has been used to describe the output of an ontology application implemented in the ontology processing block. This term should be read as encompassing any output form acceptable to an external system, whether human or machine. For example, in the context of the healthcare billing code application, there are many standards that might serve to define the exact nature and content of the system's output, including standards established by the Health Insurance Portability &amp; Accountability Act (HIPAA), International Classification of Diseases Clinical Modification (e.g., ICD-9-CM; ICD-10-CM, etc.), Health Care Common Procedure Coding System (HCPCS) (e.g., HCPCS Level II codes), Current Procedural Terminology (CPT-Y) (e.g., CPT-4; CPT-5, etc.), Health Care Financing Administration (HCFA), Food &amp; Drug Administration (FDA), Veterans Affairs (VA), Department of Health and Human Services (HHS), Centers for Medicare and Medicaid Services (CMS), National Library of Medicine (NLM), and the World Health Organization (WHO), etc.

0050The term “standard” or “standardized” in the foregoing context may have reference to either the content and/or the form factor of the resulting output. That is, the standardized output might not only include properly identified and related healthcare billing codes, but it may also be presented in a form ready for immediate consumption by downstream systems (e.g., be interface ready via XML—such as HL7, etc.).

0051In a preferred implementation of the present invention, these interface engines within the message handling service <b>130</b> will convert the local health record <b>120</b> into standardized HL7 message formats for transfer to the data store <b>160</b>. Electronic medical information is often exchanged using well-known HL7 data encoding, and information from medical institutions may be obtained electronically by interpreting HL7 communications among hospitals, insurance companies and pharmacies, following transformation from the native format of the data records <b>120</b>.

0052The coding used in HL7 data typically includes IDC codes for diagnostic information, CPT codes for treatment information, and FDA data for medications. Each portion of the information taken individually only infers to a particular medical situation. Taken together, however, the patient's record may be precisely updated. This information can include treatments and medications of all types, even those not officially approved for certain conditions.

0053To further complicate the data transform needed to forward meaningful health records from the GP applications <b>110</b> to the data store <b>160</b>, different versions of the standard messaging protocols exist, and the filters in the message handling service <b>130</b> may not produce the correct version as needed for an interoperable platform <b>100</b>.

0054For example, the HL7 Version 3 Reference Information Model (RIM) was recently completed. HL7 Version 3 is a definitive HL7 messaging standard, incorporating more trigger events and message formats than any previous version. Version 3 uses the RIM, as described below as a common source for the information content of specifications. As part of Version 3, HL7 specifications draw upon codes and vocabularies from a variety of sources. The V3 vocabulary helps to assure that the systems implementing HL7 specifications have an unambiguous understanding of the code sources, value domains and semantics that they are using.

0055HL7 Version 3 is different from previous versions, such as Version 2 that is commonly used in most current message handling services <b>130</b>. New capabilities offered in Version 3 include: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0056"> Top-down message development emphasizing reuse across multiple contexts and semantic interoperability; </li><li id="ul0006-0002" num="0057"> Representation of complex relationships; </li><li id="ul0006-0003" num="0058"> Formalisms for vocabulary support; </li><li id="ul0006-0004" num="0059"> Support for large scale integration; </li><li id="ul0006-0005" num="0060"> Solving re-use and interoperability across multiple domain contexts; </li><li id="ul0006-0006" num="0061"> A uniform set of models; </li><li id="ul0006-0007" num="0062"> Expanded scope to include community medicine, epidemiology, veterinary medicine, clinical genomics, security, etc. </li></ul></li></ul>

0063The Reference Information Model (RIM) is the cornerstone of HL7 Version 3, described in greater detail below. An object model created as part of the Version 3 methodology, the RIM is a large pictorial representation of the clinical data (domains) and identifies the life cycle of events that a message or groups of related messages will carry. HL7 RIM is a shared model between all the domains and, as such, is the model from which all domains create their messages. By explicitly representing the connections that exist between the information carried in the fields of HL7 messages, the RIM increases precision and reduces implementation costs.

0064It is known to convert from HL7 version 2 to version 3. For example, please refer to U.S. Published Application No. 20060161840, the subject matter of which is hereby incorporated by reference in full.

0065Similarly, an HL7 template is a data structure, based on the HL7 Reference Information Model, and which expresses the data content needed in a specific clinical or administrative context. They are prescribed patterns by which multiple OBX segments may be combined to describe selected, gross observations. Some observations may be quite simple, such as blood pressure readings that involve a set of expected observations (i.e., systolic, diastolic, patient position, method, etc.). Other more elaborate diagnostic procedures may involve hundreds of related pieces of information, including anatomy, orientation, sequences of measurements, etc. Templates provide a means of coupling the multiple OBX segments needed to send the observation with separately encapsulated rules for combining/validating them for the particular observation. Based on user need and preference, the template offers the user the advantage of defining the collection of OBX segments needed and the corresponding set of validation rules once, and once, defined, the structure can be used again and again. Since they are based on a specific user's needs/requirements, Templates can be plug-and-play at a given user site. The HL7 template are composed of data structures drawn from the HL7 RIM, that make use of HL7 vocabulary domains.

0066HL7 Version 3 further includes a coded vocabulary that, when used in conjunction with HL7 and related standards, will enable the exchange of clinical data and information so that sending and receiving systems have a shared, well defined, and unambiguous knowledge of the meaning of the data transferred. The purpose of the exchange of clinical data includes but is not limited to: provision of clinical care, support of clinical and administrative research, execution of automated transaction oriented decision logic (medical logic modules), support of outcomes research, support of clinical trials, and to support data reporting to government and other authorized third parties.

0067While the foregoing discussion exclusively discusses the use of HL7, other comparable health record communication protocols are known and may be similarly employed by a message handling service <b>130</b>.

0068As described above, a message handling service <b>130</b> may not output the desired new protocol. Accordingly, embodiments of the present invention may further include an optional data conversion module <b>140</b> to perform the non-trivial task of converting messages in a first standard protocol to a second desired message protocol. For example, as laid out above, there are significant differences between HL7 versions <b>2</b> and <b>3</b>.

0069Returning back to FIGS. <b>1</b>A and <b>2</b>-<b>3</b>, the platform <b>100</b> further includes a data mapping engine <b>150</b> that stores terminology mapping data <b>155</b> that may be used to support health data collection and organization data by the platform <b>100</b>. In this way, the health data records <b>120</b>, message normalization by the message handling service <b>130</b>, may be normalized from terminology perspective. The data in the messages that are sent data store <b>160</b> is preferably mapped to standard Federal Health Architecture (FHA) terminologies (e.g., SNOMED CT, LOINC, or other such hierarchy). The mapping engine <b>150</b> has information about the relevant terminology hierarchy and maintains information about the relationship between terms of the hierarchy. The data mapping engine <b>150</b> may comprise a module hosted separately from the platform <b>100</b>. Several commercial vocabulary services are available, for example, from Apelon Inc. of Ridgefield, Conn.

0070Preferably, embodiments of the data mapping engine <b>150</b> support terminologies that conform to a common standard such as SNOMED-CT (Systematized Nomenclature of Medicine—Clinical Terms). SNOMED CT is a dynamic, scientifically validated clinical reference terminology that makes health care knowledge more usable and accessible. The SNOMED CT core terminology provides a common language that enables a consistent way of capturing, sharing and aggregating health data across specialties and sites of care. Among the applications for SNOMED CT are electronic medical records, ICU monitoring, clinical decision support, medical research studies, clinical trials, computerized physician order entry, disease surveillance, and image indexing and consumer (patient) health information services. The Core terminology Core content includes the technical specification of SNOMED CT and fully integrated multi-specialty clinical content, and the Core content includes the concepts table, descriptions table, relationships table, history table, an ICD-X-CM mapping, and the Technical Reference Guide. SNOMED CT further includes offers content, tools and services that build upon the Core content. For example, the SNOMED CT US Drug Extension includes proprietary medications approved for use in the United States. It links to the Core for electronic prescribing and clinical decision support which also relies on terminology for drug allergies, contraindications, drug-induced diseases, and lab tests used to monitor drugs. Currently, the Core terminology contains hundreds of thousands of health care concepts with unique meanings and formal logic-based definitions organized into hierarchies. Currently, the fully populated table with unique descriptions for each concept contains more than a million descriptions, and millions of semantic relationships exist to enable reliability and consistency of data retrieval.

0071In one embodiment, the data mapping engine <b>150</b> can be regularly updated as new terminology and other data becomes public. For example, updates of SNOMED CT are released twice a year. Alternatively, the terminology mappings <b>155</b> may be manually updated as needed for preferred operation of platform <b>100</b>.

0072The terminology, including vocabularies, code sets, and identifiers, is employed in characterizing or identifying a health provider organization, a location in an organization, a healthcare worker, a medical condition, a health service, a cost of a medical procedure or service, a payer organization, or a particular health plan. In this way, the health data store <b>160</b> may contain medical terms, vocabularies and identifiers in addition to organizational characteristics, as well as location and other information. A medical code set as used herein is any set of codes used for encoding data elements, such as tables of terms, medical concepts, medical diagnosis codes, or medical procedure codes.

0073Proper categorization of a data record <b>120</b> may require, for example, a determination of whether the patient has diabetes. In order to make this determination, the platform <b>100</b> sends a request to the data mapping engine <b>150</b> for all of the various sub-types of diabetes. These subtypes are also known as the “subsumed terms” associated with diabetes or the set of unique medical IDs subsumed within the term “diabetes.” In response to receiving the parent identifier of “diabetes,” data mapping engine <b>150</b> returns the set of subsumed terms. Using these subsumed terms, data mapping engine <b>150</b> can query the terminology mapping <b>155</b> for the full complement of possible types of diabetes. The terminology contains unique identifiers for each medical element and hierarchical terminologies for each element. For example, a medical term such as “Type II Diabetes” may subsume many types of diabetes such as Type II diabetes with renal complications, and insulin resistant Type II diabetes. If the guideline has a criterion that asks, “Does this patient have Type II Diabetes?” the encoding would ask “Does this patient have SNOMED CT: 44054006” where SNOMED CT: 44054006 is the code for Type II Diabetes. When the terminology mapping <b>155</b> is queried for subsumption with “SNOMED CT: 44054006”, it would respond with the relevant subsumed meanings of “Type II Diabetes”.

0074Continuing with FIGS. <b>1</b>A and <b>2</b>-<b>3</b>, the data store <b>160</b> receives and stores modified data records <b>165</b> following conversion by the message handling service <b>130</b> and conversion module <b>140</b> and following data mapping by the data mapping engine <b>150</b>. The updating preferably includes algorithms to manage version skewing in terminology as terminology changes over time. For example, the existing records <b>165</b> may be remapped by the mapping engine <b>150</b> using updated terminology <b>155</b> so that the existing records <b>165</b> may be integrated with incoming, newly mapped data records <b>120</b>.

0075Preferably, embodiments of the present invention provide methodology and software as needed to integrate the terminology normalized data from the mapping engine <b>150</b> from a commercially available data mapping engine as needed by the data repository <b>160</b>.

0076While data mapping techniques are known, it should be appreciated that the platform <b>100</b> provides methodology and software to provide the speed to get the data into the data store repository <b>160</b> at a sufficiently large scale.

0077Returning now to FIGS. <b>1</b>A and <b>2</b>-<b>3</b>, the data store <b>160</b> receives the data records after protocol conversion and data mapping and stores these converted, mapped health records <b>165</b>. The data store <b>160</b> partitions and manages the data as needed to maintain performance and protect the data <b>165</b>. Specifically, the converted, mapped health records <b>165</b> are used to populate a centralized repository <b>160</b>. Thus, the data store preferable supports the clinical data structures of the normalized records <b>165</b>. As described in greater detail below, the data store <b>160</b> entails databases, data models and methodologies that provide decision support, privacy services, aggregated views, and other desirable features. In this way, the normalized data records <b>165</b> will be available for multiple secondary uses as well as potentially provide information to a treating physician.

0078Data <b>165</b> held within the data store <b>160</b>, although normalized, should be a sufficient richness and quantity to subsequently enable robust, meaningful analyses. A non-exhaustive list of possible analyses include: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0079"> Data linkage across patients; </li><li id="ul0008-0002" num="0080"> Data linkage across care episodes; </li><li id="ul0008-0003" num="0081"> Longitudinal analysis of patient care; </li><li id="ul0008-0004" num="0082"> Age based analyses; </li><li id="ul0008-0005" num="0083"> Gender based analyses; </li><li id="ul0008-0006" num="0084"> Condition based analyses; </li><li id="ul0008-0007" num="0085"> Geographic Analyses; </li><li id="ul0008-0008" num="0086"> Epidemiological analyses; </li><li id="ul0008-0009" num="0087"> Bio-surveillance; and </li><li id="ul0008-0010" num="0088"> Screening. </li></ul></li></ul>

0089In one preferred embodiment of the present invention, that data store <b>160</b> receives and stores the normalized data records to provide an extended, distributed data model that is based on the HL7 Version 3.0 Reference Information Model (RIM), as described above. In this way, data accessed from the data store <b>160</b>, such as messages that are sent to the regional data model, will comply with standard Federal Health Architecture (FHA) terminologies (i.e., SNOMED CT, LOINC, etc.) and a centralized repository shall be capable of supporting such vocabularies.

0090Normalization enables the creation of valuable data stores <b>160</b> that can be used for epidemiology studies, bioterrorism detection activities, quality assurance, cost containment, and clinical research. In addition, appropriately identified and indexed data <b>165</b> can be used to generate alerts for error reduction and to support disease management system development. Additionally, this same normalization process has the valuable by-product of supporting a consent management system that provides a workable way to sequester sensitive patient information and to allow for access control by the patient to his/her information for all purposes, not just direct clinical care.

0091In embodiments of the present invention, data store <b>160</b> is specifically designed for health care, and has a data model based on a health care data standard, such as the above-described HL7 Version 3.0 Reference Information Model (RIM). The data store <b>160</b> further supports a master patient index <b>170</b> (described in greater detail below) and federated security architecture at the NHIN and RHC level. For example, the data store <b>160</b> may be based on the Health Care Transactions Base (HTB) software marketed by Oracle® of Redwood Shores, Calif.

0092In embodiments of the platform <b>100</b>, the data store <b>160</b> may optionally include has several core components such a master patient index <b>170</b>, a provider directory or a record locator service. In this way, the stored normalized data may be search by patient, provider, or other used defined criteria. For example, health records related to a particular condition, demographic, and course of treatment may be collected to aid in the evaluation of the efficacy of the specified course of treat for the specified demographic group.

0093For efficiency purposes, the data store <b>160</b> may optionally contain no identifiable personal information (i.e., patient name and address), but should contain coded information with a specified identifier for each patient. Patient demographic information is then externalized in the patient directory <b>170</b> in a high availability database or directory that is separate from the data store <b>160</b>.

0094The patient directory <b>170</b>, sometimes called Enterprise Master Patient Index (EMPI), optimally, includes a strict change control process for patient information to link disparate information of patients received from external systems into one file for the patient to avoid duplicate records. The patient index <b>170</b> may further enable complexity and architecture that is not available in current health record databases. For example, patient index <b>170</b> may allow the platform <b>100</b> to perform medical records management (using services, processes and building tools) across provider organizations. For example, maintenance may be initiated where a search for records associated with a person cannot find any relevant records. In other embodiments, the patient directory <b>170</b> may be implemented through novel approaches to secure patient privacy while still permitting appropriate tracing of patients by providers. Toward this goal, the platform <b>100</b> may include processes and software to coordinate across distinct provider organizations.

0095Accordingly, another embodiment of the present invention may include a provider directory (not illustrated). For example, the provider directory may be a multifaceted to allow a provider to be placed within a clinical hierarchical context. Moreover, a provider may operate on several different hierarchies. Thus, the platform <b>100</b> may include novel processes around the implementation and provide a provider directory for a national information network. However, the addition of a provider directory adds complexity by requiring management of other types of dynamic data in additional to patients

0096Referring to <figref idref="DRAWINGS">FIG. 1A</figref>, the platform <b>100</b> further comprises information governance <b>101</b> to provide security and privacy of protected health information. Aspects of the information governance <b>101</b> include an integrated approach that provides a workable way to obtain sensitive patient information and to facilitate control by the patient to his/her information for all healthcare purposes, not solely direct clinical care. The information governance <b>101</b> is flexible to allow customized access control rules as needed by various access functions, as described below. Specifically, the information governance <b>101</b> is flexible and scalable to provide interoperable security and access architecture as need to provide auditing and cross-domain access management. Thus, aspects of the present invention provide an approach to role-based access control that provides for different organizational structures, privilege authorization, as well Patient-Provider relationships which reflect the direct care relationship between a patient and their care providers (or groups of providers) including, the wider health and social care team, and also facilitating the ability of patients to specify those who they wish to have access to their care record.

0097The information governance <b>101</b> further includes an access control framework that can operate within either a hierarchical or federated model, and support the use of public/private key technologies (such as Public Key Infrastructure or PKI) where appropriate. The information governance <b>101</b> may further include (1) processes, policies and procedures for the robust identification, registration and issuance of access credentials to care professionals; and (2) processes, policies and procedures for the management, including key management, of all aspects of the security and confidentiality model—with such processes, policies and procedures to be harmonized with the care environment. Accordingly, the information governance <b>101</b> may provide the capability to aggregate data for a variety of cohorts in a pseudonymised or anonymised fashion, yet maintain sufficient controls to enable direct patient contact if required. Likewise, the information governance <b>101</b> may give the capability for a patient, subject to strict access controls, to be able to access their own health record formed from an aggregation of many different data sources across a variety of provider organizations, including the provision of software to enable patient access to health records

0098The information governance <b>101</b> may possible further allow patients to select specific parts of their record and place access controls upon them which are independent of those other access controls routinely provided. Likewise, the information governance <b>101</b> may provide care providers with the capability to select specific parts of the patient record which require special access controls to be placed upon them, independent of those other access control routinely provided

0099Referring now the <figref idref="DRAWINGS">FIG. 1B</figref>, the platform allows access to the data records <b>165</b> stored at the data store <b>160</b> in a variety of methods, depending on the granted level of access. For example, an authorized user, such as health care providers may be able to use the messaging system <b>130</b> to access the normalized data records <b>165</b> in whole. Other users may access particulars portions of the data records <b>165</b> after the data records <b>165</b> are stripped of confidential information. Other users may receive data created through analysis of the data records <b>165</b>, such as selected statistical summaries.

0100For example, the application programming interfaces (APIs) may be integrated into data store <b>160</b> allow the development of applications that can leverage the semantically normalized data existing to support a wide variety of existing and future health care processes. Additionally, the normalized data can be exported into data warehouses for further analysis.

0101A portal with a graphical user interface may be available for patient and provider access and this same interface can be exposed as a web service to other applications. Additionally, the data can be leveraged by other applications through the development of web services that again are accessed through the above-described APIs.

0102As described above, the application programming interfaces (APIs) integrate to applications that can leverage semantically normalized data existing at the regional level or at individual health provider, research or pharmaceutical and biotechnology companies to support a wide variety of health care processes.

0103For example, for presentation of medical summary data, the platform <b>100</b> may include a custom portal (not depicted) with a graphical user interface which can be exposed as a web interface to providers and patients. In this way, a patient could potentially acquire information on the quality of a provider or a course of treatment. Alternatively, an existing application may be modified to access the data store <b>160</b> to acquire the summary. In this way, a provider could likewise acquire statistical information about course of treatment. Other more sophisticated user interfaces may be added to the data store <b>160</b> this purpose to allow intrinsic access to certain data. Then, a user may define search criteria to pull the desired medical summary information, and the requested data is brought into the presentation layer.

0104Referring back to <figref idref="DRAWINGS">FIG. 1B</figref>, the platform <b>100</b> enables Service for the Provision of Secondary Purpose data (SPSP) to provide de-identified, anonymized data through the data store, or warehouse <b>160</b>. In this way, the platform develop a more innovative approach to the current, standard mechanisms including the ability to re-identify the data for patient identification and contact and other novel capabilities to instantiate privacy and security rules to enable desired secure access.

0105In the embodiment of the platform <b>100</b> depicted in <figref idref="DRAWINGS">FIG. 1B</figref>, the SPSP Application <b>180</b> is a direct user interface available as a web-browser based client. This UI enables control of all the querying, analytical and outputting functions through a server side application. Third party applications interact with the SPSP through messaging, and the provision of batch data.

0106Continuing with <figref idref="DRAWINGS">FIG. 1B</figref>, Data Transformation Engine and Messaging Interfaces, such as above-described message handling system <b>130</b> enables the SPSP application and other third party applications to integrate with SPSP components. Multiple messaging interfaces may be supported, enabling data to be presented in a variety of formats. Also, as previously disclosed, data transformation services through the message handling system <b>130</b> are also provided to facilitate the normalization of data. This layer <b>130</b> typically does not provide semantic validation services, as all data is assumed to be valid prior to presentation, but may provide for the validation of data for out of range values, etc. Instead semantic validation services may be offered through other known tools. Alternatively, a different message handling service may be used as needed to format the desired output data.

0107Continuing with <figref idref="DRAWINGS">FIG. 1B</figref>, a variety of predefined queries <b>182</b> are provided through the platform <b>100</b> to allow users to undertake common and routine tasks. A query engine <b>181</b> may also be provided to enabling users to create ad-hoc or custom defined queries. An analysis service <b>183</b> enables manipulation of data. Data that is output from the SPSP typically passes through a Pseudonymization Service <b>184</b>. This will pseudonymize the data dependent upon user access controls.

0108As described above, the data store <b>160</b> holds a normalized copy of all presented data. For purpose of data output, the data store <b>160</b> may also present a series of data marts (which might also be the result of a query).

0109In operation, the platform may provide two modes of operation, Batch, or Submission, mode where data is automatically forwarded and Interactive mode where the data forwarded upon user request.

0110Consequently, the platform <b>100</b> provides the ability to process patient identifiable data into pseudonymised data while preserving the ability to provide patient identifiable data. Moreover, the platform <b>100</b> provides a robust and flexible access control framework and automatic association of queries and analyses with the user performing such functions.

0111The platform <b>100</b> allows algorithms implemented within the SPSP <b>180</b> to be secure, robust, high performance, having low resource requirements, adjustable, and resulting in different products depending upon user, access control and function.

0112Continuing with <figref idref="DRAWINGS">FIG. 1B</figref>, the Pseudonymization Service <b>184</b> is generally capable of undertaking a variety of pseudonymization tasks, and the nature of these will depend upon user access controls and application function being performed. In essence, the platform <b>100</b> may output Patient Identifiable Data including non-coded information; Patient Identifiable Data using solely coded information; Patient Data in which any identifiers have been pseudonymized; and Patient Data in which all identifiers have been removed.

0113As the purposes to which output data will be put are many and varied, the platform <b>100</b> facilitates flexibility in the performed pseudonymization. Therefore, the platform is capable of re-running queries and analysis and outputting the results using a different pseudonymization regime than previously undertaken. Also, platform <b>100</b> allows analysis or query to be re-run using a defined “point in time,” thereby enabling the same cohort to be output as was previously.

0114The Pseudonymization Service <b>184</b> further supports the linkage of data sets output. This is done in a manner that can be specific to the data, the user, a facet of the user role, or the purpose to which the data will be put, dependent upon user access controls.

0115In another embodiment of the platform <b>100</b>, an optional record locater service (not illustrated) may be associated with the data store <b>160</b> or another database. The record locater service includes list of pointers telling where the original data records <b>120</b> is located (RHIO and/or Provider locations).

0116Embodiments of the present invention enable the operating and maintaining of a RHIO. The ability to normalize data and interface with a wide variety of systems results in an architecture that can scale and promote the sharing of health care data across a wide variety of provider organizations and systems. For example, the data store <b>160</b> may be operated by a service provider such as a Regional Health Information Organization (RHIO) which would initially be comprised of affiliated hospitals, staff, laboratories, physicians, care givers, intermediate and long term care providers and pharmacies. Each would have access to the RHIO operated central server and each would have an encryption code for its list of patients. That code would enable unidirectional input on a unique patient by patient basis to the central server, subject only to input programming criteria to insure clean data and limited bidirectional communication to confirm data receipt and to control the standardization of data, i.e., insure it is clean data. The encryption code would be secured through the patient hardware key plus the user name and password of the provider. This combination of code input would insure communication uniquely solely with the patient's record for input purposes only since the provider would not have the patient name and password. Rather, the combination of key code with provider name and password would limit the provider (via the server program software) to data input only in one preferred embodiment.

0117The RHIO would preferably create a backup record of all input data on a real time basis. That backup data record would replicate the RHIO data in case of system failure and would immediately be on line upon detection of a system failure. Such redundancy is a preferred feature of the system and would provide a source of information that could be separately used for research.

0118That is, certain fields of information could be rendered inaccessible for research purposes, such as name, address, social security number, etc. However, other fields of information could be made available for statistical research. Such research access could be subject to pre-access approval by the RHIO or other server operator and could also comprise an income source for the RHIO, e.g., payment for access to the medical information regarding the history of certain drug use. Again, the access to information would require patient permission that would be solicited and obtained upon assignment of and providing the patient with a key device, password, etc. All at the same time the patient would also likely provide various medical instructions such as a living will, organ donation information, emergency instructions, etc.

0119Emergency access by certain providers could be insured by a combination of the authorized providers key code and the patient name and/or password, and/or encryption key. For example, an emergency medical service (EMS) may have an encryption key device that, in combination with the device or password and/or name of an accident victim, provides access to that victim/patient's medical record. Thus, the patient/victim may have an RFID device, a USB device, or even a “smart card” which in combination with the EMS encryption key will permit access to the unique medical record of the patient/victim. The available information will typically, in such circumstances, comprise an emergency subset of patient information per a program that limits the information to the “need to know in emergency situation.”

0120As can be seen, the system eliminates duplication of records, standardizes record keeping, permits access as needed, provides for contribution of information by multiple sources and most importantly is dependent upon patient participation.

0121The platform <b>100</b> of the present invention integrates both existing software assets and new technologies along with operating and execution processes to develop a technology platform, repeatable operational and development architecture and processes that support the ability to manage dynamic data from multiple types of stakeholders—patients, providers, etc. as well as aggregating data from multiple, different clinical systems and EHRs within and across health provider organizations, laboratories, health insurance organizations and/or governmental agencies, by using common acquisition, interoperability, transformation and transaction and medical terminology normalization processes.

0122In this way, the platform <b>100</b> effectively merges patient records from multiple sources and avoids duplicate records that result in increased errors and decrease information availability. The platform <b>100</b> further enables authorized, secure, timely, and accurate exchanges of semantically normalized health information among patients, clinicians, other providers and authorized entities. The platform <b>100</b> further provides a scalable security and access architecture to facilitate trust, auditing and cross-domain data access management that facilitates interoperability and/or federation. Overall the platform <b>100</b> provides a robust data model and de-identification/re-identification capabilities, supporting the secondary use of patient information (e.g. epidemiology studies, biosurveillance activities, screening, quality assurance, cost containment, clinical research and disease management) Secondary Uses means those uses that are not the provision of direct healthcare to a patient or group of patients. The Platform <b>100</b> may further optionally provide for the provision of analytical facilities to support secondary uses, as well as supporting a National Health Information Network (NHIN), Regional Health Information Organizations (RHIOs) and Regional Health Communities (RHCs) in exchanging information and be flexible for the growth and scalability of these initiatives.

0123Embodiments of the present invention provide readily available packaged solutions for most the architecture's technical components. Given the diverse and rapidly expanding landscape of possible technology solutions for the architecture, selecting the most appropriate solution for the architecture will require discussions and evaluation of the existing environment. Therefore, in this response potential vendors are mentioned but this is purely for indicative purpose and not a formal selection.

0124Moreover, the present invention provides innovative emerging solutions to provide high value for the architecture. For example, a networking solution, such as Cisco Application Oriented Networking (AON) may play a vital role in the proposed solution. The networking solution may be leveraged to develop a standard architecture layer for member institutions, the so-called Novel Integration Platform (NIP). The NIP can be rapidly deployed and will provide the advanced security and manageability required in the architecture's distributed architecture.

0125Furthermore, embodiments of the present invention can be adapted to include advanced security and privacy architecture since providing a secure environment that protects patient privacy is an integral component of the present invention. Security and privacy requirements are complex and will evolve over time, making packaged solutions insufficient to meet the architecture's security needs. The present invention may implement an advanced architecture for security and privacy protection, based on the experience gained during other significant clinical data exchange implementations.

0126Also, the operations architecture disclosed herein supports ongoing management, and the technical components outlined elsewhere make up the execution, or run-time, environment for the architecture. Based on experience, it is equally important to focus on another aspect of the solution—Operations Architecture. Operations Architecture is the set of capabilities necessary to monitor and manage the environment on an ongoing basis, once the solution is deployed. Given the importance of having the Operations Architecture ready when the solution is deployed, an approach to Operations Architecture is included below.

0127Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, an interoperable health records platform <b>200</b> in accordance with another embodiment of the present invention is disclosed. As disclosed herein, the an interoperable health records platform <b>200</b> allows health records to be collected from participants <b>210</b> and collected at a central location <b>220</b>.

0128One would implement the technical components in a layered, modular fashion as depicted in platform architecture <b>300</b> in <figref idref="DRAWINGS">FIG. 5</figref>, primarily a logical view of the architecture. The physical distribution of architecture components would be determined as needed. In making those physical distribution decisions, the invention may be adapted to ensure the most appropriate balance of security, functionality, performance and manageability.

0129The architecture will be able to begin by implementing only those components necessary to provide basic data exchange functionality. Once the basic data exchange functionality is in place, layering and modularity will also allow for incremental improvements to the architecture, as it minimizes the impact of changes to any one architecture component.

0130Each layer of the architecture <b>300</b> is now disclosed in greater detail. The applications <b>310</b> are in the layer that faces the end users. Applications allow the user to view or manipulate data in the architecture data stores. Applications may or may not take advantage of services. Architecture Services <b>320</b> is the layer that provides services to support clinical data exchange. These services are typically invoked by events, either user requests or other business events that trigger service execution. Data Stores <b>330</b> are Repositories that store data. Infrastructure <b>340</b> is the platform that provides infrastructure services. The Operations Architecture <b>350</b> is the set of capabilities necessary to monitor and manage the environment on an ongoing basis, once the invention solution is deployed.

0131The architecture <b>300</b> may further contain optional additional components (i.e., Integration Engine, Public Health Database) that will be described as necessary to provide full clarity on how one would implement the specific components of the architecture <b>300</b>.

0132Continuing with <figref idref="DRAWINGS">FIG. 5</figref>, the Applications Layer <b>310</b> is the primary mechanism by which end users perform business functions. Exemplary applications within the application layer are given in Table 1. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="161PT" align="left" /><colspec colname="3" colwidth="91PT" align="left" /><thead><row><entry namest="1" nameend="3" align="center">TABLE 1</entry></row><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Application</entry><entry>Purpose</entry><entry>Used By</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Patient Matching/</entry><entry>Match and locate patients based on demographic</entry><entry>ED Physicians</entry></row><row><entry>Record Locator</entry><entry>attributes.</entry><entry>Other ED users</entry></row><row><entry /><entry /><entry>Other authorized users (e.g.,</entry></row><row><entry /><entry /><entry>receptionists)</entry></row><row><entry>Clinical Data</entry><entry>Provide access to clinical data captured in the</entry><entry>ED Physicians</entry></row><row><entry>Viewer</entry><entry>architecture system.</entry><entry>Other ED users</entry></row><row><entry>Reporting</entry><entry>Provide predefined reports and a mechanism for the</entry><entry>based on reporting</entry></row><row><entry /><entry>definition of ad hoc data reports and analysis</entry><entry>requirements; most likely</entry></row><row><entry /><entry>services.</entry><entry>outside the ED context</entry></row><row><entry>Terminology</entry><entry>Manage standard terminologies; allow users at each</entry><entry>the terminology managers at</entry></row><row><entry>Management</entry><entry>site to map standard terminologies to local</entry><entry>each member institution</entry></row><row><entry /><entry>terminologies.</entry></row><row><entry>Administration</entry><entry>Allow authorized individuals to perform administrative</entry><entry>the administrative personnel</entry></row><row><entry /><entry>and maintenance activities, such as user</entry><entry>(at each member institution)</entry></row><row><entry /><entry>management (enrollment, role, access control).</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0133Again, it should be appreciated that Table 1 represents an indicative list of applications in the application layer <b>310</b>, and should not be taken as definitive. For example, definition of an appropriate access control framework may be otherwise performed as needed.

0134As the Table 1 above indicates, physicians and other personnel within the Emergency Department (ED) will typically use two of the applications listed above: Patient Matching/Record Locator and the Clinical Data Viewer. Depending on the workflow that supports the architecture system, ED personnel may not even use the Patient Matching/Record Locator application.

0135The Architecture Services Layer <b>320</b> performs functions to support clinical data exchange between the members <b>301</b> as well as data transfer to the public health repository <b>302</b>. Architecture services are described below in Table 2, along with their key functions. Each service has a well-defined purpose and will be deployed according to the present invention's preferred implementation roadmap. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="196PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 2</entry></row><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Service</entry><entry>Purpose</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Clinical Data Services</entry><entry>Process data both into and out of the clinical data repository:</entry></row><row><entry /><entry>Capture data into the clinical data repository.</entry></row><row><entry /><entry>Process requests from the hub and respond with clinical data.</entry></row><row><entry>Patient Demographic</entry><entry>Manage patient demographics data in the clinical data repository</entry></row><row><entry>Services</entry><entry>and the central master patient index.</entry></row><row><entry>Data Aggregation</entry><entry>Retrieve and aggregate data from member clinical data</entry></row><row><entry>Services</entry><entry>repositories.</entry></row><row><entry>Message Handling</entry><entry>Receive and parse incoming messages, invoke appropriate</entry></row><row><entry /><entry>services based on the contents of the message.</entry></row><row><entry>Transformation &amp;</entry><entry>Transform and normalize data from member institutions to enable</entry></row><row><entry>Normalization</entry><entry>sharing via the data exchange. For example, map local</entry></row><row><entry /><entry>terminologies to the architecture standard terminologies.</entry></row><row><entry>Public Health</entry><entry>Services to support uses such as age based analyses, gender</entry></row><row><entry>Transformation &amp;</entry><entry>based analyses, condition based analyses, geographic analyses,</entry></row><row><entry>Normalization</entry><entry>epidemiological analyses, biosurvelliance and screening.</entry></row><row><entry>Audit Trails &amp; Logging</entry><entry>Services to log key data about events within the system.</entry></row><row><entry>Security &amp; Privacy</entry><entry>Services to secure the application and data as well as protect</entry></row><row><entry /><entry>patient privacy.</entry></row><row><entry>Business Rules Engine</entry><entry>Store rules that manage the execution of workflow.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0136The Architecture Services layer <b>320</b> provides the core components that enable the data exchange to function. It is anticipated that some of these services will be physically deployed at the member sites <b>210</b> and some will be deployed at the central hub <b>220</b>. The invention may be adapted to determine the precise details around physical distribution of components. It may be possible to manage the components that are physically deployed at the architecture member sites by developing a Novel Integration Platform (NIP)—a standard bundle of components (including data stores and potentially architecture services) that will be physically deployed at member sites. By standardizing the NIP, one can rapidly deploy the architecture to member sites. In addition, it is expected the NIP to leverage Cisco's AON solution, enhancing the architecture's ability to provide a secure and managed infrastructure at member sites.

0137The approach for integrating member data into the exchange is designed to ensure consistency within the NIP, minimize the burden on members and leverage member's existing investments in applications and integration tools. A standard set of messages that the NIP will accept and process may be defined. If source transactional systems at member sites can supply these messages, the NIP will accept them. This minimizes the burden on the member sites by re-using existing interfaces. If source transactional systems cannot supply these messages, members can utilize existing in-house interface engines to supply these messages, thus preserving their investment in these tools. If members do not have interface engines, the architecture will provide a recommended standard interface engine. Member institutions may need to configure or develop adapters for some applications in order to utilize the interface engine.

0138Due to the sensitivity of patient health data as well as established federal patient privacy regulations, security and the protection of patient privacy should be among the most important concerns when implementing a clinical data exchange. Given the ongoing national debate over the impact of health data exchange on patient privacy, it is possible to implement a number of advanced features to provide security and ensure the protection of patient privacy. Those features are described below. Specifically, a variety of security services may be offered in the Architecture Services layer <b>320</b>, providing a holistic approach to the security and privacy of patient information. The techniques adopted are designed to provide a high level of integrity to both existing estate and newly deployed systems. The precise configuration of the security components will depend, but over and above the traditional techniques for ensuring privacy and confidentiality of information, the architecture <b>300</b> may further include augmented approaches for Registration and Authentication, Role Based Access Control (RBAC), Patient—Provider Relationships, seal envelopes, and Audit and Alerting.

0139For example, in the registration and authentication service is one that can implement differing levels of assurance in the credentialing process used to identify and register both healthcare users and healthcare systems, and depending upon organizational requirements can implement various different authentication mechanisms. All authentication may be based around a Public Key Infrastructure (PKI)—providing for strong authentication of users, and mutual authentication of all system end points. PKI comprises of a system of digital certificates, certificate authorities (CA), and other registration authorities that verify and authenticate the identity of each party involved in an Internet transaction. PKI components include maintaining root certificates, authentication, authorization, and encryption and decryption of transactions.

0140The architecture <b>300</b> enables regional data interchange among various healthcare hospitals and institutions. These institutions may not be directly affiliated and have their own information security policies and AAA (Access Control, Accounting, Audit), methods. The members are, for the most part, separate business entities with their own data centers, security designs, and management policies. Authentication amongst these separate entities suggests building a loosely coupled and federated identity management system, however, the precise details of this will depend upon the governance model implemented with the proposed solution. There may be cooperation with the members to ensure that this is robust, deployable and scalable. Support for digital signatures provides non-repudiation, thereby guaranteeing that a message or data can be proven to have originated from a specific person. Non repudiation will be supported where required by the architecture's needs and to meet legislative obligations.

0141A flexible, scalable, manageable approach to Role Based Access Control (RBAC) may also be desirable. This feature enables a layer of commonality to be placed across multiple provider organizations. RBAC constraints can be enacted at a variety of levels. Applications that are framework aware can use the privilege information offered by the framework to enact security constraints within the application itself. However, for those applications which are not framework aware, RBAC constraints can be implemented within the messaging layer(s), thus constraining the manner in which applications can interact with the architecture as a whole.

0142This architecture <b>300</b> is complimentary, yet orthogonal to that of Role Based Access Control, and facilitates the declaration of relationships between patients and their care providers. This relationship can then be used to constrain user access to solely those patients to whom the provider is providing care (and therefore has a relationship with). Triggers for the creation and termination of the relationships are implemented within applications that are aware of this framework. However, as for RBAC, this architecture <b>300</b> can also be implemented within the messaging layer(s), thus constraining access to data within applications that are not PPR capable. Unlike RBAC however, this framework requires a greater degree of management when an application is not PPR aware, as relationships can not be automatically created and terminated, therefore an additional management application is required in limited cases. The Patient-Provider Relationship can also be used independently of access control to represent the care team around a patient. A vocabulary for PPRs is implemented, which holds both access control semantics, and also broader care relationship semantics. Therefore, PPRs can be interrogated and yield the entire care family for a patient.

0143The sealed envelope has two facets—that of the Patient's Sealed Envelope, and also the Clinician's Sealed Envelope. The former can be used by the patient to place additional access controls upon their shared data. This enables the patient to restrict access to certain parts of their shared record and is of use when a patient has special privacy requirements. However, the Patient's Sealed Envelope is not intended for regular use, as the interaction of correctly implemented Role Based Access Control and Patient-Provider Relationships provide a sufficiently granular access control framework to prevent access to patient data by unauthorized individuals, who have no need to know. The Clinician's Sealed Envelope can be used by clinicians to place special access controls around specific sections of a patient's shared record. This is of use where specific diagnoses or information concerning prevalent conditions are deemed by the clinician to be potentially harmful to the patient, or need to be withheld from the patient for another reason. This is especially of use in areas such as Mental Health, and Genitourinary Medicine. Specific policies and procedures must be implemented by organizations around the use of sealed envelopes—concerning specifically the classes of information that can be placed within the envelope.

0144All systems deployed as part of the architecture may incorporate robust audit and analysis systems as standard. These will propagate audit information to a logically centralized audit repository, which shall be available for query and analysis by authorized users. Those packaged applications which are incorporated into the architecture may not be considered to have the same level of audit functionality as custom built systems. This is not to say that such systems have poor audit capabilities, simply that they may not have the same facilities as available in a custom-built system—and they are unlikely to have the integrated nature of audit subsystem available that is being proposed. Therefore, where appropriate, auditing of messaging output from systems will be implemented—thus facilitating an integrated audit facility inclusive of all platforms. As explained above, a networking solution, such as AON® can play a vital role in the architecture's audit and alerting approach. Acting as a network interception point for application message traffic, each security gateway node within the sites can be configured to act as a sensor that can capture, process, and log highly granular information about application messages. An administrative user interface will be available for the security officers from member organizations to manage such audit trails. Additional intelligence in logging transactions is provided in a networking solution's ability to generate and route events external systems based on message content inspection. This can be very useful in tracking patient opt-outs, which can be appropriately tagged in the security system such that access will be denied to patient information for those patients who have opted-out of the program.

0145Returning now to <figref idref="DRAWINGS">FIG. 5</figref>, the Data Stores Layer <b>330</b> includes various data stores that could be implemented as part of the proposed solution, as depicted in Table 3. It is anticipate that the number and/or nature of these data stores will change as the solution design evolves. The structure of several of these data stores may be driven by the packaged solution that the architecture selects. Therefore, this section provides an overview of the likely data stores, along with their purpose and how they would be most frequently accessed. <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><colspec colname="3" colwidth="105PT" align="left" /><thead><row><entry namest="1" nameend="3" align="center">TABLE 3</entry></row><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Data Store</entry><entry>Purpose</entry><entry>Accessed By</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Member Clinical Data</entry><entry>Stores patient demographics and</entry><entry>Clinical Data Services</entry></row><row><entry>Repository</entry><entry>clinical data. May also store audit</entry></row><row><entry /><entry>trail data. The data repository will be</entry></row><row><entry /><entry>structured to allow the persistence of</entry></row><row><entry /><entry>data in a standardized fashion, while</entry></row><row><entry /><entry>still permitting each member to</entry></row><row><entry /><entry>implement different data types at</entry></row><row><entry /><entry>different times.</entry></row><row><entry>Master Patient Index (MPI)</entry><entry>Stores patient demographic</entry><entry>Patient Demographics Service</entry></row><row><entry /><entry>information along with any attributes</entry><entry>Patient Matching/Record Locator</entry></row><row><entry /><entry>necessary for matching and/or</entry><entry>Service</entry></row><row><entry /><entry>locating patients.</entry></row><row><entry>Provider Registry</entry><entry>Stores information about participating</entry><entry>Patient Demographics Service</entry></row><row><entry /><entry>entities.</entry><entry>Patient Matching/Record Locator</entry></row><row><entry /><entry /><entry>Service</entry></row><row><entry>Audit Trail</entry><entry>Captures data necessary to identify</entry><entry>Reporting Services</entry></row><row><entry /><entry>who requested data for which</entry><entry>Security and Privacy Services</entry></row><row><entry /><entry>patients.</entry></row><row><entry>Security/Privacy</entry><entry>Stores information to support the</entry><entry>Security and Privacy Services</entry></row><row><entry /><entry>security services, including patient-</entry></row><row><entry /><entry>provider relationships and sealed</entry></row><row><entry /><entry>envelopes.</entry></row><row><entry>Terminology</entry><entry>Stores standard terminologies along</entry><entry>Terminology Management</entry></row><row><entry /><entry>with the mappings between standard</entry><entry>application</entry></row><row><entry /><entry>terminologies and local</entry><entry>Transformation and Normalization</entry></row><row><entry /><entry>terminologies.</entry><entry>Service</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0146Continuing with <figref idref="DRAWINGS">FIG. 5</figref>, the infrastructure layer <b>340</b> may use Web Services to provide the primary infrastructure services. Web Services use standard Internet technologies to make functionality available over a network in a standardized programmatic manner. From a technology perspective, Web Services are based on Internet standards, platform agnostic, are widely available, and have complete vendor support. Web Services provide a common mechanism for interoperability among disparate systems, and the key to their utility is their standardization. The value of Web Services is in their ability to reduce the cost of technical integration of systems by applying industry wide Internet standards. This helps reduce delivery time and provides end users the capability to consume service through common user tools. It also provides a common technique for integration both internal and external to the architecture.

0147Web services standards can be categorized according to the purpose they serve, and the web services framework <b>400</b> for the architecture may be defined as depict in <figref idref="DRAWINGS">FIG. 6</figref>. Web Services standards are continually created, enhanced, and consolidated by numerous organizations and standards bodies. As a result, certain standards are consistently and widely used where they've been adopted into the mainstream, while others may be new or experimental standards used by fewer organizations. For the architecture, utilize web services standards that have been accepted into the mainstream may be used wherever possible.

0148The Table 4 below defines the standards that may be incorporate into the present invention. The “Category” column refers to the different categories illustrated in the framework <b>300</b> of <figref idref="DRAWINGS">FIG. 5</figref>. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="63PT" align="left" /><colspec colname="4" colwidth="84PT" align="left" /><colspec colname="5" colwidth="77PT" align="left" /><thead><row><entry namest="1" nameend="5" align="center">TABLE 4</entry></row><row><entry /></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry /><entry /><entry /><entry /><entry>Usage in the</entry></row><row><entry>Category</entry><entry>Standard</entry><entry>Name</entry><entry>Description</entry><entry>invention</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Service Description</entry><entry>WSDL</entry><entry>Web Services</entry><entry>Provides a model and an</entry><entry>WSDL will be used to</entry></row><row><entry /><entry /><entry>Description</entry><entry>XML format for describing</entry><entry>create the Web Service</entry></row><row><entry /><entry /><entry>Language</entry><entry>Web Services. Defines</entry><entry>message structure for</entry></row><row><entry /><entry /><entry /><entry>Web Services interfaces,</entry><entry>messages exchanged</entry></row><row><entry /><entry /><entry /><entry>data and message types,</entry><entry>between Portals and</entry></row><row><entry /><entry /><entry /><entry>interaction patterns, and</entry><entry>RHIOs.</entry></row><row><entry /><entry /><entry /><entry>protocol mappings.</entry></row><row><entry /><entry>WS-Policy</entry><entry>Web Services</entry><entry>Provides a general-purpose</entry></row><row><entry /><entry /><entry>Policy Framework</entry><entry>model and corresponding</entry></row><row><entry /><entry /><entry /><entry>syntax to describe and</entry></row><row><entry /><entry /><entry /><entry>communicate the policies</entry></row><row><entry /><entry /><entry /><entry>of a Web service.</entry></row><row><entry>Discovery &amp;</entry><entry>UDDI</entry><entry>Universal</entry><entry>A set of services supporting</entry><entry>Could be used to</entry></row><row><entry>Publication</entry><entry /><entry>Description,</entry><entry>the description and</entry><entry>publish a RHIO's Web</entry></row><row><entry /><entry /><entry>Discovery, and</entry><entry>discovery of businesses,</entry><entry>Service information to</entry></row><row><entry /><entry /><entry>Integration</entry><entry>organizations, and other</entry><entry>Providers and other</entry></row><row><entry /><entry /><entry /><entry>Web services providers;</entry><entry>RHIOs.</entry></row><row><entry /><entry /><entry /><entry>the Web services they</entry></row><row><entry /><entry /><entry /><entry>make available; and the</entry></row><row><entry /><entry /><entry /><entry>technical interfaces which</entry></row><row><entry /><entry /><entry /><entry>may be used to access</entry></row><row><entry /><entry /><entry /><entry>those services.</entry></row><row><entry /><entry>WSIL</entry><entry>Web Services</entry><entry>Defines a method to</entry><entry>RHIO to RHIO access,</entry></row><row><entry /><entry /><entry>Inspection</entry><entry>discover and locate a list of</entry><entry>RHIO to NHIN access.</entry></row><row><entry /><entry /><entry>Language</entry><entry>Web Services published at</entry></row><row><entry /><entry /><entry /><entry>a particular known</entry></row><row><entry /><entry /><entry /><entry>receiver's address.</entry></row><row><entry>Data Exchange</entry><entry>SOAP</entry><entry>Simple Object</entry><entry>Defines an XML messaging</entry><entry>Messages exchanged</entry></row><row><entry /><entry /><entry>Access Protocol</entry><entry>protocol for basic service</entry><entry>between Portals and</entry></row><row><entry /><entry /><entry /><entry>interoperability. Provides a</entry><entry>RHIO applications will</entry></row><row><entry /><entry /><entry /><entry>simple and lightweight</entry><entry>be packaged in a SOAP</entry></row><row><entry /><entry /><entry /><entry>mechanism for exchanging</entry><entry>envelope.</entry></row><row><entry /><entry /><entry /><entry>structured and typed</entry></row><row><entry /><entry /><entry /><entry>information between peers</entry></row><row><entry /><entry /><entry /><entry>in a decentralized,</entry></row><row><entry /><entry /><entry /><entry>distributed environment.</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0149Continuing with <figref idref="DRAWINGS">FIG. 5</figref>, the Operations Architecture <b>350</b> provides for ongoing monitoring and management of the environment. The environment is preferably be managed in a reliable and consistent manner across the central hub and all participating member institutions. Having the capability to support ongoing management and operations is desirable. Since the architecture distributes data to servers at member institutions <b>210</b>, the operations management capability <b>350</b> helps to ensure that each member operates according to consistent, standard service levels. As described above, it is known to manage both the central hub servers as well as (potentially) the servers within member data centers. Taking advantage of hosting and management capability would transfer the complexity of providing a consistent operational service. Regardless of who actually hosts or manages the infrastructure, the Operations Architecture <b>350</b> may offer a consistent structure that can use to ensure the appropriate level of operational support for the proposed solution.

0150Turning to <figref idref="DRAWINGS">FIG. 7</figref>, the Operations Architecture Framework is illustrated in greater detail and optionally includes various, such as those listed below in Table 5. <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="182PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><thead><row><entry namest="1" nameend="3" align="center">TABLE 5</entry></row><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Relevance for The</entry></row><row><entry>Service</entry><entry>Definition</entry><entry>Architecture</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Service Level</entry><entry>The process of defining, agreeing, documenting and</entry><entry>The architecture management will use</entry></row><row><entry>Management</entry><entry>managing the levels of IT service that are required and cost</entry><entry>SLAs and OLAs as the basis for</entry></row><row><entry /><entry>justified. Service Level Agreements (SLAs) and</entry><entry>evaluating the quality of infrastructure</entry></row><row><entry /><entry>Operational Level Agreements (OLAs) are typically</entry><entry>support services.</entry></row><row><entry /><entry>developed to capture the required levels of service.</entry></row><row><entry>Availability</entry><entry>The practice of ensuring that any IT service consistently</entry><entry>The architecture system will require</entry></row><row><entry>Management</entry><entry>and cost-effectively delivers the level of availability required</entry><entry>day-to-day maintenance to prevent</entry></row><row><entry /><entry>by the customer. This practice includes day-to-day</entry><entry>down-time and ensure service levels.</entry></row><row><entry /><entry>operations, administration and maintenance tasks.</entry></row><row><entry>Capacity</entry><entry>The process of planning, sizing and controlling</entry><entry>The architecture system will continue to</entry></row><row><entry>Management</entry><entry>infrastructure capacity to satisfy user demand at reasonable</entry><entry>grow, both in the number of participants</entry></row><row><entry /><entry>cost within target performance levels. This process ensures</entry><entry>as well as the different practice settings</entry></row><row><entry /><entry>optimal use of IT resources.</entry><entry>(e.g., moving from ED to ambulatory).</entry></row><row><entry /><entry /><entry>Proactive planning of capacity will be</entry></row><row><entry /><entry /><entry>important to ensure that this expected</entry></row><row><entry /><entry /><entry>growth does not negatively impact the</entry></row><row><entry /><entry /><entry>users.</entry></row><row><entry>IT Service</entry><entry>The practice of ensuring that IT services can still provide</entry><entry>Given the events of recent years (e.g.,</entry></row><row><entry>Continuity</entry><entry>value even when the primary infrastructure fails. Includes</entry><entry>Hurricane Katrina), a disaster recovery</entry></row><row><entry>Management</entry><entry>processes and procedures that describe how to recover</entry><entry>plan and procedures is a critical need</entry></row><row><entry>(Disaster</entry><entry>from an event. Events range from application or system</entry><entry>for the architecture.</entry></row><row><entry>Recovery)</entry><entry>failure to a complete destruction of the premises. In the</entry></row><row><entry /><entry>event of an extreme failure (e.g., natural disaster), services</entry></row><row><entry /><entry>will be restored to support only the minimum business</entry></row><row><entry /><entry>requirements.</entry></row><row><entry>Configuration</entry><entry>The identification, recording and reporting of IT</entry><entry>The architecture system has a</entry></row><row><entry>Management</entry><entry>components, including their versions, constituent</entry><entry>substantial number of components.</entry></row><row><entry /><entry>components and relationships. The scope of configuration</entry><entry>Managing these components in an</entry></row><row><entry /><entry>management includes hardware, software and associated</entry><entry>organized and detailed fashion will be</entry></row><row><entry /><entry>documentation. Examples of components that would be</entry><entry>an important need.</entry></row><row><entry /><entry>managed under Configuration Management include</entry></row><row><entry /><entry>hardware, software, network equipment, configurations,</entry></row><row><entry /><entry>processes, procedures, documentation, service level</entry></row><row><entry /><entry>agreements and problem records.</entry></row><row><entry>Release</entry><entry>The practice of coordinating and managing releases to a</entry><entry>The architecture system will continue to</entry></row><row><entry>Management</entry><entry>live environment. This process balances the need to</entry><entry>grow and change (e.g., when a new</entry></row><row><entry /><entry>release changes as quickly as possible to meet business</entry><entry>participant is added). Managing the</entry></row><row><entry /><entry>requirements with the need to ensure that changes are</entry><entry>changes to the environment in a way</entry></row><row><entry /><entry>implemented in a controlled and systematic way that limits</entry><entry>that balances speed with deliberation</entry></row><row><entry /><entry>negative impact to the information technology environment.</entry><entry>will be an important need.</entry></row><row><entry /><entry>Multiple changes would typically be grouped into a single</entry></row><row><entry /><entry>release to reduce the frequency of changes to the live</entry></row><row><entry /><entry>environment.</entry></row><row><entry>Change</entry><entry>The practice of ensuring that all changes to the</entry><entry>Given the intended use of the</entry></row><row><entry>Management</entry><entry>infrastructure are carried out in a planned and authorized</entry><entry>architecture system, managing changes</entry></row><row><entry /><entry>manner. Key aspects of this practice include confirming the</entry><entry>to the infrastructure is an important</entry></row><row><entry /><entry>reason for the change, identifying affected services,</entry><entry>need.</entry></row><row><entry /><entry>planning the change, testing the change and having a back</entry></row><row><entry /><entry>out plan in case the change results in an unexpected issue.</entry></row><row><entry>Problem</entry><entry>The process of identifying the root cause of incidents and</entry><entry>Problems within the architecture</entry></row><row><entry>Management</entry><entry>initiating actions to improve or correct the situation. This</entry><entry>system, particularly those that are</entry></row><row><entry /><entry>process has both reactive and proactive aspects. The</entry><entry>persistent, will threaten user</entry></row><row><entry /><entry>reactive aspect is concerned with solving problems in</entry><entry>acceptance of the system. Problems</entry></row><row><entry /><entry>response to incidents, and the proactive aspect is</entry><entry>must be permanently and pro-actively</entry></row><row><entry /><entry>concerned with identifying and solving problems and known</entry><entry>solved.</entry></row><row><entry /><entry>errors before an incident occurs.</entry></row><row><entry>Incident</entry><entry>An incident is any event that disrupts the expected standard</entry><entry>Incidents within the architecture system</entry></row><row><entry>Management</entry><entry>operation of a system, service or product within the</entry><entry>will require resolution with minimal</entry></row><row><entry /><entry>infrastructure. Incident Management aims to restore normal</entry><entry>impact on business operations.</entry></row><row><entry /><entry>service operation as quickly as possible and minimize the</entry></row><row><entry /><entry>negative impact on business operations.</entry></row><row><entry>Service Desk</entry><entry>The single point of contact for users of the architecture</entry><entry>The Help Desk - the users will need a</entry></row><row><entry /><entry>services. The focal point for reporting incidents and making</entry><entry>place to report incidents and make</entry></row><row><entry /><entry>service requests. The Service Desk also keeps</entry><entry>service requests.</entry></row><row><entry /><entry>stakeholders informed of service events and actions that</entry></row><row><entry /><entry>are likely to impact their ability to perform day-to-day</entry></row><row><entry /><entry>activities.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

CONCLUSION

0151While the invention has been described with reference to an exemplary embodiments various additions, deletions, substitutions, or other modifications may be made without departing from the spirit or scope of the invention. Accordingly, the invention is not to be considered as limited by the foregoing description, but is only limited by the scope of the appended claims. Further information on the present invention is provided in the attached.