AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT ORIGINAL Applicant(s): RALPH KORP AN; CINDY A POST; RUDY R HILADO, RANDAL W C EGG Actual Inventor(s): RALPH K MAN; CINDY A POST; RUDY R HILADO, RANDAL CLEGG Address for Service: PATE T ATTORNEY SERVICES 26 E11i gworth Parade Box H 11 Victoria 3128 Austra ia Title: INDIVIDUAL HEALTH ECORD SYSTEM AND APPARATUS The following statement is a full escription of this invention, including the best method of performing it known to me/us: INDIVIDUAL HEALTH RECORD SYSTEM AND APPARATUS This application is based. n and claims priority from Australian Patent Application 2007300057 filed 26 Septem e -2007 and the entire contents of that application and its 5 associated specification (inclo ling drawings and abstract) are incorporated herein by cross reference. FIELD OF INVENTION 10 This invention relates to a system, apparatus, and associated methods for the collection, processing, evaluation, transformation, and reporting of individual health care information from diverse information systems and sources. BACKGROUND OF THE INVENTION 15 Most information techno ogy (IT) applications are built on predefining, with great specificity, the types and construction of information to be received, sent, processed, and stored by the IT service or application. For many industries, this model works fairly well, In the health care industry, this model may work passably well when the 20 application is used in operating a particular institution or practice where the relevant information is fairly limited, and can be specifically defined, collected, and managed, Even in such limited circumstances, however, such applications have problems because of the inherent randomness in biologic functions. This inherent unpredictability of biologic functions means that an individual'ss health does not follow a predefined course, 25 making it a particularly difficult automation challenge. This model does not work well for an individual-centric approach to health care. Health care is transforming from a traditional, provider-centric, organizational-driven approach to an individual-centere system. This individual-centered approach cuts across all providers and patients, and the interrelationships of sources of information cannot be 30 predicted in advance. In addition, the information and relationships will vary widely from person to person, place to place, and time to time. Furthermore, because a broad 2 A range of patients, practitio ers, and other health care stakeholders will be accessing and using the information for a -'atiety, of purposes, not only are the sources not predefined, but uses of the informant re not predetermined either, Attempting to create a comprehensive, workable s em for handling individ al health care records using 5 current models results in e rm us, unwieldy databa es and applications that are expensive and slow to ope an maintain, and preven such systems from fulfilling their functions. Accordingly, what ed d is a new model aId approach to creating and maintaining individual hea e or s that is robust and flexible enough to handle health 10 information from a wide v e of unpredictable sources, and permits a broad range of patients, practitioners, and er sets to manipulate and use health information in a wide variety of unpredictable wa When used in th p ifi ation and claims, the terms "comprises" and "comprising" and variations r fiean that the specified features, steps or integers are 15 included. The terms are not b nt reted to exclude the presence of other features, steps or components. The above references a d scriptions of prior proposals or products are not intended to be, and are not to e st ued as, statements or admissions of common general knowledge in the art i tra ia. 20 SU Y\OF THE INVENTION The present invention s s stem, apparatus, and related methods for the collection, processing, evaluate , ns ormation, and reporting of individual health care 25 information from diverse inforai s stems and sources. Health care is transforming from a traditional, provider-cen 1c, rga izational-driven approach to an individual 3.
centered system, The individual health record (IHR) of the present invention provides a structure for individuals to pa Jtcipate in, and manage, their health and their medical care, while still meeting the of health care organizations and caregivers, thereby supporting collaborative c i a new way. 5 According to a fi 0 ect of the invention, there is provided a system for processing, storing and har health care information, including: a persistent data sto e evice; an information inpu ponent, adapted to receive health care information from one or more health care info - on sources; 10 a central health re r component, adapted to transform said health care information to create or mo i single composite individual health record object for a particular individual, patien r ser from said health care information, wherein cach health record object is an obj -iented software environment object and a single health record object exists for each t i lar individual, patient or user; 15 wherein the creation dification of said health record objects is performed using a comprehensive healt - ontology, wherein the system extends the individual health record object and its b or by modifying the ontology and not the individual health record object; wherein further each p e f received health care information is connected to or 20 reduced to a central health ide i with relationship and attribute information; and a user interface compo t adapted to provide access by one or more users to the system. According to a second a of the invention, there is provided a computer-based method for processing, storing andling health care information, including the steps 25 of: receiving, in a computer e ory, health care information relating to health care about an individual from one or I health care information sources; and integrating in a processor o croprocessor, the information; identifying the information a 30 transforming, in said proc or microprocessor, the information by creating and modifying a single composite in ij ial health record object for a particular individual, 4 patient or user from said health c re information, wherein each health record object is an object-oriented software anvir n ent object and a single health record object exists for each particular individual, patie t r user; wherein the creation or odification of said health record objects is performed 5 using a comprehensive he lth c ontology, wherein the method extends the individual health record object and i s bel ior by modifying the ontology and not the individual health record object; the method further i 01 connecting or red cing each piece of received health care information to a central hea identifier with relationship and attribute information; 10 and providing a user int rfac omponent adapted to provide access by one or more users to said information. According to a third asp c of the invention, there is provided a machine for processing, storing and hand ing h Ith care information, including: 15 at least one applianc deY c , said appliance device adapted to be incorporated into an existing network oif r ation technology system, said appliance device comprising the following co pone t a persistent data stora e d( 'c an information input c mpo nt, adapted to receive health care information from 20 one or more health care info rnation s urces; a central health record P ponent, adapted to transform said health care information to create or modi a si le composite individual health record object for a particular individual, patient use rorn said information, wherein the health record object is an object-oriented soft are vironment object and a single health record object 25 exists for each particular indivi ual, a ient or user; wherein the health care bjc ersists as a table in a relational database using a database interface; and further wherein the cre tion r modification of said health record object is performed using a comprehens ye a th care ontology, wherein said machine extends 30 the individual health record obje t an'd it behavior by modifying the ontology and not the individual health record object. 5 The HIR is formed by obtaining information from diverse health care information systems and sources, including, but not limited to, existing systems and information flows such as employee health records, pharmacies, laboratories, and medical claims 5 information streams. The information from these sources is transformed and re-purposed into a coherent account of the individual's overall health and care. The 1HR is not a simple collection of all health care information about the individual; instead, the information is processed by means of an individual health information model that incorporates a comprehensive e health care ontology, 10 In one exemplary e bodiment, information is received from a source, validated, parsed, transformed, match d to an existing individual, and assigned an ontology concept code. Next, a message ob ect is created, the data is repurposed, subjected to a rules evaluation, and filed in an IHR database. As information from various sources is updated or available, the JHR is dynamically updated on a continuous or periodic basis. 15 A Single Best Record (SBR) of information may be created. In other exemplary embodiments, the invention provides ways and means to interact with the information in the IHR in a variety of ways, including through health portals, portlets, and web ser ices. It allows individuals to understand and participate in their health care, and enable caregivers and consumers to collaborate and interact using 20 the same record in different ways. It embraces the emerging roles of custodian and health care advocate, and as ists health care stakeholders, including but not limited to health systems, health plans IPAs, RHIOs, employers, providers, and individuals, to meet the requirements and n eds for health care systems going forward into the future. In one exemplary embodi ent, the present invention does not replace existing 25 information systems and infr structure; instead, it provides a standards-based, service oriented infrastructure that ra idly and easily provides health-related information and components that work with su h existing systems. In another exemplary embodiment, the JHR system is contained in a self contained package or appliancee." The IHR appliance is designed to "plug and play" in 30 existing health care information technology systems and networks, with minimal effort 6 and intervention. Information is obtained from all available source systems and dynamically constructed in o th JHR. DE CR TION OF THE DRAWINGS 5 Preferred embodiments of t e inyention will hereinafter be described, by way of example only, with reference to the a co p nying drawings which: Figure 1 is an overvi w f n IHlR system in accordance with one embodiment of the present invention. Figure 2 is a diagra of c tomer portlets in a customer portal in accordance with 10 an embodiment of the presen inv ntion. Figure 3 is another vi w o an IHR system in accordance with one embodiment of the present invention. Figure 4 is yet an ther view of an IHR system in accordance with one embodiment of the present in enti n, 15 Figure 5 is another vi w of an IHR system showing a customized application of an IHR system in accordance ith ne embodiment of the present invention. Figure 6 is a diagram of d ta flows in accordance with one embodiment of the present invention, Figure 7 is a message roce sing map in accordance with one embodiment of the 20 present invention. Figure 8 is a diagram holding interface service processing in accordance with another exemplary embodimen of t e present invention. Figure 9 is a diagram sh wi g merger of entities in accordance with an exemplary embodiment of the present inve tion. 25 Figure 10 is a diagram ho ing the relationship of the ontology tool to the IHR database in accordance with an xem lary embodiment of the present invention. Figure II is a diagram ho ing authorization rights components in accordance with an exemplary embodiment f th resent invention. Figure 12 is a schematic iagr n of an example of individual's care relationships. 30 Figure 13 shows role-bas d u r authorization security components in accordance with an exemplary embodiment f the present invention. 7 Figure 14 shows role-b sed user authorization security components in accordance with an exemplary embodimen of the present invention, Figure 15 is a diagram howing elements of an appliance in accordance with an exemplary embodiment of the p esent invention, 5 Figure 16 is a diagram howing elements of an application server in accordance with an exemplary embodiment. f the present invention. Figure 17 is another view of an IHR system in accordance with one embodiment of the present invention. Figure 18 is yet anoth r view of an IHR system in accordance with one 10 embodiment of the present inven ion. Figure 19 is a diagram o data flows in accordance with one embodiment of the present invention. Figure 20 is a message pr cessing map in accordance with one embodiment of the present invention. 15 Figure 21 is a diagram sh wing the relationship of the ontology tool to the IHR database in accordance with an ex mplary embodiment of the present invention. Figure 22 is a diagram sh wing elements of an appliance in accordance with an exemplary embodiment of the pres nt invention. DETAILED DESCRJPT ON OF EXEMPLARY EMBODIMENTS 20 The present invention is system, apparatus, and related methods for the collection, processing, evaluation, t ansformation, and reporting of individual health care information from diverse and poten ially unpredictable information systems and sources, which also allows a wide variety o patients, health care givers, practitioners, and other 25 users to manipulate and use the information in a variety of potentially unpredictable ways. The individual health recor (IHR) system of the present invention provides a structure for individuals to participat in, and manage, their health and their medical care, while still meeting the needs of ealth care organizations and caregivers, thereby supporting collaborative health care i a new way. 30 The present invention uses a new business object model approach, known as Health Universal Genericity (HUG). This approach presumes that received information 8 can be represented by a h ndful of highly abstracted health objects. These abstractions include, but are not limit to, health events, health conditions, health services, health products, and health relati i ship Individual objects are created from data shared among these abstracted health obj cts.th ugh the unique interplay of "data objects," which exist 5 only to hold data in suppoi of th LHR-supported health delivery process, Each object's attributes are a composite f spe fic variables defined in the object class, extended by non-programmatically supp rted er-defined attributes. In one exemplary e bodi nt, the IHR is formed by obtaining information from diverse health care inform tion stems and sources, including, but not limited to, 10 existing systems and infon- ation ows such as employee health records, pharmacies, laboratories, and medical c aims ' formation streams. The information from these sources is transformed and re purp ed into a coherent account of the individual's overall health and care. The IHR is not a mple collection of all health care information about the individual; instead, the i form t on is processed by means of an individual health 15 information model that incorp rates comprehensive health care ontology. The system of the p -esent Invention has several unique characteristics that distinguish it from prior art sys ems. First, the level of abstraction is far higher than has been generally used in health care. High level abstract objects appropriate to each individual's health care are use , rath -than the specific, detailed objects specific to each 20 care setting used in the prior rt. e use of these high level abstract objects in the present invention allows broad adap bility and flexibility without the intervention of programming modifications and resou es that would required to effect changes in other systems. Second, the extension of th object model by binding it to the comprehensive health care ontology changes th me ing and use of the traditional object paradigm. 25 Third, the system can take poten 'ally I information about an individual (including, but not limited to, clinical, financial, perso al, health, and administrative information), and represent it in a single, unified fas gion. he system thereby can tie together not only the matching clinical-to-clinical or I nanci -to-financial transactions, but transactions or interactions across these tradition ily s arate data streams as well, This presents a 30 uniquely robust view of each idivi ual, his or her health care status, and the relationships of the health care sys em. Fourth, the system has the ability to extend the 9 health objects, and their behavior, by modifying the ontology rather than the objects themselves. This modification can be done non-programmaticalfy, thereby providing increased installability and flexibility over the prior art. Fifth, the creation of a health object from a metadata data object by the process of "centrification" (as discussed in 5 more detail below) allows both preservation of the source information and simultaneous repurposing of the information to a uniform and unified representation. It should be noted that the system of the present invention does not use an XML-like approach, where data fields and their definitions are stored as pairs but the underlying infrastructure knows nothing about either part; in the case of the present invention the infrastructure is fully 10 informed regarding both parts, In one exemplary embodiment, the set of healthcare objects are unique, and allow virtually any health instance or activity to be characterized and interrelated to other health information known about, or to be known about, about an individual. Each object may comprise methods, attributes, and inheritances. 15 Figure I shows a broad, abstract view of an IHR system. The core IHR application 10 comprises the health data 12, connectivity services 14, and Intenet Web services 16, Data is received from a variety of source systems 20. A variety of different types of users can access the IHR system through customer applications 30 or customer portlets 32 (described in more detail below). Customer portlets 32 may be used in 20 customer portals 34, as shown in Figure 2. Figures 3 and 17 show the IHR application 10 as an appliance installed in a customer's existing IT system behind a firewall 40. Information is received from a variety of source systems 20. Users include, but are not limited to, public health entities 42, retail pharmacies.43, labs 44, and hospitals 45. 25 In one exemplary embodiment, as shown in Figures 4 and 18, the IHR system comprises a persistent data storage layer 200, with a full object model 202 in the application layer supported by hibernate object and relational mapping. Part of the persistence layer comprises a content repository 204 provides a storage mechanism for IHR content items, such as binary large objects and other typically non-object oriented 30 data (e.g., images, documents, rule definitions, message templates, information content, and help files), and may comprise standardized technology (e.g., Java). Content 10 attributes or meta data a elated with content items may be used for management and selection of discrete conte ite s. Examples of attributes include, but are not limited to, ontology classes, target ag tar et gender, usage context, effective time, expiration time, keywords, status and local on. The content repository may be viewed as a generic 5 application data "super store " ix which virtually any type of content can be handled, and that separates content from ata storage technology. Content may be XML exportable and importable. A standard AP (such as JSR 170 or JSR 238) may be used to interact with a content repository, th eb providing advantages such as the ability to access other standard content repositories all w external editing, and transport content between Java 10 content repositories. The IHR Services laer 6 provides main IHR capabilities, including but not limited to centification serve es, interaction services, custodial services, and system administration services. Co. nec ivity services 14 provide interface means with source systems 20, and handle messages a d record parsing. Connection adapters may be used. 15 The web services component 08 rovides external access by users to the IHR data and functions through a variety of ortlets 32, which may include customer written applications. Jn one exempla e bodiment, web applications may be instantiated as Java Specification Request 168 (JS -168) or Web Services for Remote Portlets (WSRP) standard portlets. As seen in f gur 5, other applications 210 can call web services 208 20 to create a customized solution. Figures 6 and 19 show a en al, broad overview of data flows in accordance with one embodiment of the subjec in ention. Information and data in the form of a "Cmessage" 52 (although some o0her orm or terminology is possible) is received from a source 50, validated 54, parsed 6, a d transformed 58. These steps are accomplished 25 through integration services as rt f the connectivity services 14. The transformed data is then matched 62 to an ex stin individual through identity management services 64, and assigned an ontology con pt ode 66 (CHID, discussed below) through ontology services 68. Next, a message obj t is created 72, the data is repurposed 74, subjected to a rules evaluation 76 using the rui s e gine 78, and filed 80 in a persistent IHR database 30 90. Some of these steps may be p -for ed in another order, as shown in Figure 19, The identity management services 6 on ology services 68, and rules engine 78 ate 11 components of the busine s process services 70 element of the IH1R system. As information from various so races is updated or available, the IHR is dynamically updated on a continuous or periodic, asis. The connectivity ser ices 14 component handles the connections with health data 5 source systems. In one exe plary embodiment, the connectivity services uses an open source cross-platform HL7 i terface engine, although other platfotrms may be used. A connectivity configuration manager stores configuration data and manages the deployment environments, The platform monitors and manages the connectivity runtime components, including the c nnectivity designer used to define the specific message 10 handling processes, connectiv ty adapters, and the runtime engine. Figures 7 and 20 s ows the message processing map for an exemplary embodiment of the present invention. Two examples of source systems are shown: in Figure 20, these are a Sourc system A 91 and a Source system B 92. The data undergoes protocol 94 and enVelope 96 processes, and undergoes transform processing 15 98. The data is mapped 102 and submitted to the interface schema filing queue 104. Additional interface internal processing is shown in Figure 8. In another exemplary en ibodiment, the present invention comprises a Single Best Record (SBR). The S3R comprises a healthcare object containing the "very best" composite information known about a healthcare event, test, or the like. In current 20 healthcare electronic records systems and operations, the systems rely on individuals to examine large amounts of information about an individual patient (many instances of this information, in fact, referring to the same event), and then manually determine which portions of which instances should be considered relevant. For example, a mammogram might first be reported via an appointment request, then subsequently by a visit summary 25 when the patient checks in, then a report of the exam several days later, then a claim submissions for payment, then the payment for the exam. In prior art systems, these would be separate records and it would be up to the user to glean the important information from each, even though they all actually refer to the same actual event. The processes of the SBR of the present invention allow all of these records and data sources 30 to be evaluated and properly combined into a single SBR object, containing the "very best" information known about the mammogram from all sources. In short, fragmented 12 partial information about real world health events, received as information events, is reconstituted into a coherent account of those real world events. The SBR object may then be instantiated into the IHR system. Data received at a later time (whether a month, year, or even later) can be sigbjected to the SBR process upon receipt, contextualized into 5 the appropriate SBR object, and seamlessly made part of the individual's health record. The SBR process operates by taking each data input as an "information event." Information events do not necessarily have a one-to-one correspondence with real life events. Information events represent the way information about an individual can be received from any source at any time. From each information event, specific subsets of 10 key health data are subjected to the SBR process (i.e., evaluated and combined into the SBR object) to create or update the IHR system's knowledge about a particular individual, This process could include, for example, updating a service, a date, a condition, a product, a test, or the lile, Each information event may be compared to existing objects in the IHR system to determine if the information event is describing a 15 new health event or is providing additional information on a known health event and if so whether it is an improvement on what is already known. The SBR process thereby uniquely combines what is learned from external sources with what is already known about that health event or concept to deliver composite information where previously there had only been fragmented data. 20 In some embodiments, a person Sl3R may be created, comprising a composite set of the best demographic data the IHR system knows about an entity, Demographic data from each person data object (i.e., each event) is used to update the person SBR. In one embodiment, the IHR system is dependent on the ability to accurately identify or create an entity, and link data correctly. Identity management services (IMS) 25 62 handle these functions. In an exemplary embodiment, two types of entities are of particular importance: persons (including but not limited to, patients, members, consumers, clinicians, and individuals), and organizations (including, but not limited to, employers, payors, and providers, such as hospitals, reference labs, imaging centers, or nursing homes), IMS functions include creation, matching, merging, and unmerging for 30 each type of entity, One goal of identity m tching is to have the di parate data about an entity from multiple source be placed i or inserted into a singl record (e.g., the SBR). The persons and/or organizations within a message or inpu data are matched to the persons and organizations known to t e IHR system (or creates a new record for the entity if none 5 previously exists). The identity matching process retur s a CHID that has been assigned to the entity. Alternatively, criteria matching can be u ed to effect a match, Criteria may comprise demographic information (e.g., name birth date, gender, address, telephone number, email ad ress, mother's maiden n me), identifiers (e.g., medical record number, social securit number, member number, provider ID, driver's license 10 ID), or relationship informa ion (e.g., family data, ervice provider relationship). Probablilistie matching may also be used. For criteria based match ing, in one exemplary em odiment, a library or table of matching criteria rules may e used. Rules may e ist for person matching, or organization matching. Each r le may comprise one or more criteria which must be met 15 to achieve a successful match, Rules may be electron c system specific, As best practices are established, they my be applied to other electronic systems. If the system determiInes that no match exists, then the system may create a new entity record. In one exemplary embod Tent, all demographic so irce data is treated like any 20 other data object; any demogra hic source data received n a message, form or web service input will create an event This permits the system to display the demographic date in the relevant event, and be We to "rematch" the person and/or re-SBR as needed. In another embodiment, w en two entities 110, 112 a e recognized by the system to be the same entity, they are effe tively merged by creating a third entity 114, as shown 25 in Figure 9, The data and events from the two entities are i erged. Not only do events 116 point to the original entity, but they also point to the new ntity. New events need to be attached properly: new data is ttached to the most speci ic (lowest level) entity, as well as higher level entities. Any n'w data generated directly by or on the merged entity will be attached to that entity. Mer ed entities may themselves be merged. 30 Conversely, entities may be nmerged (i.e., linked entities are separated), Audit histories may be created for each er ity involved in the unmerged, and formerly merged 14 entities can be accessed rough the audit history, In the unmerging process, any events on the merged entity mus be manually assigned to the appropriate lower level entity. In yet another ex plar embodiment, the present system comprises a unique health ontology to overcq e limitations of the prior art in representing knowledge and 5 information. A uniform d unifying way of dealing with health information is highly desirable. Most prior ar ystems contain some type of coding scheme, internal or external, Some of the more opular schemes include the Standardized Nomenclature of Medicine (SNOMED), and I D-9 or ICD-10 (the International Classification of Disease, including the clinical modify tion variations). While these coding schemes have long 10 been proposed as needed fo alth IT systems, and have been adopted and used by many systems, they have been use primarily in retrospective studies, and have not had the desired impact on real-time e th delivery, Ontology is a body formally represented knowledge comprising a set of concepts, their definitions, an their relationship for a specific domain (in this case, 15 health and healthcare). The tology of the present system is far more than a coding scheme; it not only is a way of epresenting every concept in health care, but also a way or representing how such core ts interrelate for the purpose of supporting the health care of individuals and the ways wh ich such concepts can be referenced and invoked. In one exemplary emb iment, the system's ontology services function by 20 reducing each piece of receive information to a centrified health identifier (CHID). Each CHID has both relationship nd attribute information, allowing it to know far more about the meaning of that isolate piece of information in relation'to the individual than just the information received. Fo example, a C-section is not just a surgical procedure, There are a number of knowledged concepts" that can be inferred by virtue of the fact 25 that a patient has had a C-sectio The various health care coding schemes that are available with regard to any partjc lar patient may relate not only to the C-section but, perhaps, to other findings related o C-section, These interrelationships are represented in the ontology, so that the unive s of issues and findings to be associated with such a patient becomes part of the inher t knowledge used and conveyed by the subject 30 invention. For instance, if it is know that an individual has a C-section, the ontology also informs the system that the individu I is a female, has been pregnant (gravida > 0), and 15 has had a non-vaginal delivery of a fetus or a child, among other things. As another example, the structure and content of the ontology means that an elevated Hemoglobin A IC informs not only that the person has diabetes, but also the inheritance of an entire class of characteristics of people that have diabetes, 5 The ontology is "full of' attributes that identify characteristics of a given concept, including but not limited to how it is displayed, where it is displayed, and what privacy and confidentiality treatments apply. Data may be stored both as original source vocabulary code, and as IHR concept code (e.g., CHID). In one exemplary embodiment, the ontology of the present invention comprises 10 over 1,500,000 source vocabulary terms, referencing over 300,000 distinct concepts represented as CHIDs. There are a large plurality of linkages among the CHIDs and the concepts that can become more mature and meaningful as additional use cases are examined and incorporated into the system. Concepts can be mapped bidirectionally to and from various source vocabularies. This representation of information allows 15 operations not possible in the prior art. As a nonlimiting example, patients and caregivers can have the benefit of the effective application of rules-based care algorithms (such as are putatively applied by disease management companies) in real time, as opposed to the delayed, after-the-fact interventions that are usually applied by quality monitoring and disease management companies. 20 In another exemplary embodiment, ontology web services identify and deliver the appropriate concept from the 1HR system ontology. Examples of methods used by ontology web services include getCHID (used when a foreign key is passed in order to retrieve a mapped CHID), getForeignKey (used when a CHID is passed in order to retrieve a mapped foreign concept ID), getName (used to retrieve a system controlled 25 medical vocabulary concept term), and getForeign (used to retrieve a foreign vocabulary concept term). In exemplary embodiments, the use of the ontology to cross all sources, uses, and users of data to provide an individual-centric view and to support the determination of the proper single best record is unique. 30 Another goal of the ontology is to enable data in the IHR system to "interoperate" using rules that create alerts and reminders, update the individual's health status, monitor 16 health action progress, and si ihar activities. To achieve this, the data in the IHR system must be coded, have context nd meaning, be linked to content, and be comparable (as seen in Figures 10 and 2 ), Benefits gained from this system are improved interoperability, increased us r adoption, better clinical decision-making, reduction of 5 medical errors, improved data mining, and the support of better outcomes analysis, among others. Source vocabularies include a number of code systems and sets. These include, but are not limited to, the following; ANSI X.12 (standard for defining electronic data exchange of healthcare administrative transactions); ANSI HL-7 versions 2 and 3 10 (standards for the exchange, management and integration of electronic healthcare information); CPT (Current Procedural Terminology); HCPCS (Healthcare Common Procedure Coding System); ICD-9-CM and ICD-10 (International Classification of Diseases and Procedures); ISO (Internal Stand rds Organization); LOINC (Logical Observation Identifiers, Names and Codes); NACIS (Northern American Industry 15 Classification System); NCPDP (script ePrescribing standard); NDC (National Drug Codes); NUBC (National Uniform Billing Code); RxNom (nomenclature for clinical drugs); and SNOMED CT (Systematized Nomenclature of Medicine), Proprietary code sets from source systems may also be used as needed, In one exemplary embodiment, a central ontology may be maintained and updated 20 on a continuing basis by a service provider. When significant changes are made, the updated ontology is released. Custodians and health advocates may be able to make local extensions to their ontology. In another exemplary embodiment, the system comprises a connectivity application module that supports the IHR system approach of taking data from any 25 authenticated source at any time. The connectivity application module receives, understands, and processes data, information and messages regardless of the type, allowing almost any type or kind of source to provide information to the IHR system. In one exemplary embodiment, information from over 150 sourcing systems can be incorporated in a particular installation of the IHR system. The number of sourcing 30 systems is unlimited. 17 In yet another embodiment of the 1HR system, the presence of understandable and understood data in the system provides the opportunity to patients, caregivers, and other users to actually use the data for a wide variety of uses and applications, Such uses include, but are not limited to, quality enhancement (e.g., duplicate blocking, interaction 5 detection and resolution, real-time adherence to disease management and other protocols, and best practices enforcement), and efficacy/efficiency optimization. Many of these uses and applications may be accomplished through a rules detection and execution environment, which may be seamless incorporated into (he IHR system to provide a heretofore unavailable level of rules integration. 10 The IHR rules environment follows the objects created for the system using fully ontologized data. Each time an object is created or modified, all applicable rules are evaluated to see if particular criteria are met. The process includes, but is not limited to, the updating of all status indicators, and the sourcing and scheduling of rules involving time-dependent criteria (eg., one mammogram per year for females over 40). 15 Accordingly, in one exemplary embodiment, with every data creation or modification event, and with every tick of the clock, the potential exists for rules to execute. Rules also can trigger other rules, supporting the complexity of the health delivery system as it actually works, An individual's health status indicators thus may be as up-to-date as the data 20 received into the IHR system. Whenever new data is added to an individual's IHR (or data is modified), rules are evaluated, A rule scheduler may also be used and an object may schedule itself at specific frequencies. The scheduler executes rules evaluation for time-dependent criteria. This may include age-dependent rules. Kick-off notifications may be given at appropriate times prior to health action due dates as well. 25 In general terms, the IHR system may tse rules to categorize individuals and users, update and notify users of the individual's health status, generate health maintenance actions, process action plans, create data from other data, perform data entry business logic, protective monitoring, data entry edit checks, select appropriate CHIDs, the flow of applications, support subscription-publication services, and present 30 personalized content. Nonlimiting examples of rule applications also may include the following; create health issue objects; create health services objects; update status; 18 update an action plan; trigger a secure message; trigger a reminder; invoke a content display; list an entry; send a message to an external system; send a fax; supplement a list; and add to the health calendar. In one exemplary embodiment, business rules are managed independently of 5 application code changes. Non-programmers may be provided with (ie ability to create and change rule, This ability may be provided through add-on decision table support. Multiple rule types may be supported, and an audit trail of rule changes may be maintained. Decision tables may be used to represent conditional logic. Spreadsheet 10 programs may be used to set up rules. Rule creators can define parameters while scripts that map the rule data to the underlying object model are hidden, When a rule is true, an acti n is triggered. Actions may include, but are not limited to, the following: creation of health issue objects; creation of health service objects; update status indicator; update action plan; secure a message; reminders; content 15 display; list entry; health calendar entry; send a message to an external system; or send a fax, Another exemplary embodiment of the present invention comprises a repurposing object program (ROP), The ROP overcomes a fundamental limitation of many prior systems where the early delineation of what each data item is for, and why, forever 20 pigeonholes each data element received, In the IHIR system, the data received by the system can be used for a variety of purposes, many originally contemplated when the system was assembled. The ROP, in conjunction with the above features, results in a system allowing repurposing of the data, The combination of the above processes and components results in a process 25 known as centrification. The centrification process takes fragmented, poorly formatted, and often incomprehensible health care data, and turns it into useful, individual-centric health care information. In one exemplary embodiment the conceptualization, design, development, and implementation processes that have r ulted in the ontology with specific reference to 30 health care, have been generalized and pplied throughout the entire system. Some or all of the application constructs (such a , but not limited to, the display and rendering 19 models, labels, input fields, and content managers) are codified, allowing them to be controlled non-programmati ly. In yet another embo iment, the 1HR system uses a meta-data content control model which allows conten from a plurality of streams and sources to be matched, 5 displayed, and linked with a propriate keys provided through the ontology or other IHR system services. This provid s a level of personalization with regard to content display to both individual and profession al users that is not present in the prior art. In another exemplary nbodiment, the IHR system comprises security custodial services, Prior art security m dels are premised op having a known, predictable pattern 10 of system use, user types, d data-all installed in an environment where certain limitations can be imposed by and on the data custodian. In addition, security models in the prior art are too structured nd rigid to work in an environment where many classes of users use the same record for ifferent purposes. In contrast, the IHR system recognizes that neither the amount of in ormation to be secured for the level of detail canl be 15 presumed in advance, The HR system is designed to deal with a variety of users, including, but not limited to, th following; patients; consumers; users who delegate their security to a custodian; and to users who come and go on the system with a need for auditing oversight but not for direct custodial intervention, The MHR system is full)' adaptive: in each case, service evaluate what data to secure, what is known about the 20 entities with potential access t this data, and what the outcome of the combination should be, As shown in Figur i1, the authorization rights components may comprise scope access, operations access, nd data access elements. In an exemplary embodi ent, data access depends on the class of data, which can include protected health inform ion, sensitive health information, and authored protected 25 health information. Protected health information (PHI) is used herein to refer to information that relates to the past, present, or future physical or mental health or condition of an individual, the provision of health care to an individual, or the past, present or future payment for the provision of health care to. an individual, and that identifies or could reasonably be used to identify the individual. Sensitive PHI is used 30 herein to refer to PHI that pertains to (i) an individual's HIV status or treatment of an individual for an HIV-related illness or AIDS, (ii) an individual's substance abuse 20 condition or the treatment of an individual for a substance abuse disorder, or (iii) anl individual's mental health condition or treatment of an individual for mental illness, Authored PHI is informa ion authored by a particular user as an event initiator or performer. In various ex mplary embodiment, the treatment of individual health data 5 complies with all regulatio s and laws, including but not limited to HIPAA, In one exemplary mbodiment, the IHR custodial services comprise a security architecture based on relati ships that the IHR system knows and/or can infer between and among entities, What n IHR system user can access, called "scope," is dynamically redefined as more and mor data is known about an individual. As data is received from 10 messages and other source including but not limited to direct data entry or network or Web service interactions 'ith source systems, the relationships between entities are gleaned, codified, and us d to maintain the best known information about that relationship. So, all of the relevant connections are recorded and summarized into the SBR of each relationship. 15 When a user access s a IR system access point, such as a health portlet, the scope defined in the user' set of rights is evaluated. When the user performs an operation, only the data and information of the health records that match the relationship parameters are returned. Scope access is based on the user's relationship to the individual. An example of 20 an individual's care relations ips is shown in Figure 12. Only users with a "legitimate relationship" with the indivi ual will have access to records concerning the individual. In one exemplary embodime t, a legitimate relationship in the IR system is a health relationship. The security architect re comprises a number of other unique custodial services. 25 Prior art systems often overlo k that in health systems, security should be performed at the data element level, not th record level, and thus either restrict complete access to a patient's data, or restrict acces to a complete class of patient information (e.g,, insurance information). What is need d is the ability to restrict to any element (e.g., medical concept) of patient information . The IHR security architecture is able to restrict around 30 particular concepts or CHlID, or the values of a field or data element, or some combination thereof, This p rmits the system to restrict access or the display of any 21 attribute of an object based on the attributes of a CHID (or other value) defined in the ontology. In yet another exemplary embodiment, as seen in Figures 13 and 14, the IHR system comprises a multi-tiered, non-hierarchical ability to restrict access or display 5 based on the role of a user. Role refers to the function or responsibility assumed by a person in the context of a healthcare event. Role information documents a person's association with an identified healthcare activity. Roles include, but are not limited to, provider roles (e.g., admitting, attending, billing, consulting, collaborating, interpreting, performing, referring, servicing, supervising, treating), personal roles (self, next-of-kin, 10 emergency contact, guarantor, guardian), or organization roles (carrier, employee, employer, insured, subscriber). A user can have multiple roles 120, 121, 122, and each role can have specific rights 124, 125, 126, 127 associated with it, When the user's role or "hat" changes, the user's authorization rights change. This include scope access rights, operations access rights, and data recess rights. Thus, for example, a doctor in his or her 15 practice has different access rig s than the same doctor looking at his or her own records, or the same doctor acti g as a health insurance company review physician. Similarly, an individual may gran or restrict access to any or all portions of their IHR from any and all caregivers, based n a class of information (including sensitive personal health information, such as, but n limited to, psychiatric information, substance abuse 20 information, HIV status, AIDS data and the like). Authorized users may "break the seal" on restricted information in emerge cies if that is the appropriate disposition. The present invention provi es a variety of ways and means to interact with the information in the IHR, including, ut not limited to, through health portals, portlets, and web services. Thus, the invention provides a complete suite of information services and 25 not just an end-user application. This allows the invention to support existing information systems in ways that p evious "records" art could not. In one exemplary embodiment, Java standard portlets nd web services are used to deliver a user interface (and user interaction) through a stan lard portal. A portal is a Internet based application, and serves as a starting point or gat way to other resources or applications. Portlets are 30 user interface components or modul s for a portal. Traditionally, portlets were custom applications for specific portals, alt ough recently, portlet standards (such as JSR 168) 22 have been defined. All interaction takes place via a cominunicaiions chain extending from the portal through a portlet through the Internet service through the IHR application server. This system promotes flexibility and broad, cross-platform ubiquity in terms of accommodating users. 5 Connections betw en the IHR system and IHR portals and portlets may be encrypted. In one exempt y embodiment, a standard Internet Web browser is used to access the portal and grtlets, and the connections are 128-bit SSL-encrypted connections. In addition, he support connection to all custodial sites will be via a VPN using encryption and other security mechanisms to ensure that only authorized users can 10 access the network, and that data cannot be intercepted. Administrative services include the backing up of various components of the system, including but not limited to database files and journal queues. Backup may be performed in stages, with frequent backups to intermediate storage, and less frequent backups to long-term storage. Disaster recovery operations and fail-over database servers 15 also may be used for data and system security and continued operations. In an exemplary embe diment, the IHR system is bundled into a prepackaged, self contained package or "appliance," as shown in Figures 3, 15, 17 and 22. The IHR appliance is designed to "plug and play" in existing health care information technology systems and networks, with minimal effort and intervention. The appliance may be 20 installed behind a network firewall, Information is obtained from all available source systems and dynamically constructed into the IHR. This appliance model for an application level solution at this level is new, and provides the ability to deliver any number of appliances and have them provide the IHR functions with minimal user intervention. In addition, this model permits appliances to be added to any node as 25 necessary to deal with increases in volume without major re-architecting of the solution or the node. This allows rapid distribution and redeployment of IHR systems. The 11HR system thus allows individuals to understand and participate in their health care, and enables caregivers and consumers to collaborate and interact using the same record in different ways. It embraces the emerging roles of custodian and health 30 care advocate, and assists health care stakeholders, including but not limited to health systems, health plans, IPAs, RHIOs, employers, providers, and individuals, to meet the 23 requirements and needs for health care systems going forward into the future. In one exemplary embodiment, the present invention does not replace existing information systems and infrastructure; instead, it provides a standards-based, service-oriented infrastructure that rapidly and easily provides health-related information and components 5 that work with such existing systems. Operations available to users in various exemplary embodiments include, but are not limited to, identifying individuals, viewing an event list, filtering events, detailing events, editing events, printing events, viewin event details, managing users (e.g., adding users, editing users, editing user fields, deactivating users, identifying users), 10 identifying individuals, and manipulating health issues (e.g., filtering, viewing list, viewing detail, adding, editing, and printing health issues). Thus, it should be understood that the e bodiments and examples have been chosen and described in order to best illustrate he principles of the invention and its practical applications to thereby enable one of or( inary skill in the art to best utilize the 15 invention in various embodiments and with va ious modificatiolis as are suited for particular uses contemplated. Even though specific embodiments of this invention have been described, they are not to be taken as exhau tive. There are several variations that will be apparent to those skilled in the art. 24