Patent Publication Number: US-10769243-B2

Title: System for onboarding participants of health services programs

Description:
CROSS-REFERENCE(S) TO RELATED APPLICATION(S) 
     This application is a continuation in part of U.S. patent application Ser. No. 14/608,988, filed on Jan. 29, 2015, entitled “System for Electronically Administering Health Services,” the entire contents of which are hereby incorporated by reference into the present application. 
    
    
     BACKGROUND OF THE INVENTION 
     The present invention is directed to the field of health care, and more particularly, to a system and method for onboarding participants of health services programs. 
     Health services programs typically involve providing a variety of health related resources and content to individuals (users). Health services programs may address a variety of health concerns, such as weight loss, nutrition counseling, diabetes control, smoking cessation, pain management, stress reduction, depression counseling, addiction treatment, physical therapy, and the like. Resources for such programs may include providers (such as doctors, nurses, counselors, coaches) conducting live sessions with individuals, whether in person, by telephone, or otherwise, and individually or in groups; and delivering relevant content to individuals. Content may include: (1) informational articles (such as newsletters, reports, bulletins, recipes, exercises, e-mails, and blogs); (2) multimedia files (such as educational videos, pre-recorded webinars and audio tracks); and (3) interactive tools (such as health calculators, calendars, journals and trackers, such as for tracking weight, mood, exercise, and the like). 
     Health services programs may be tailored to individuals according to their age, health, gender and eligibility for benefits. With the recent implementation of the U.S. Affordable Care Act (ACA) of 2010, providing health services programs which ensure continuing/follow-on care for individuals is of heightened importance. 
     Today, providers may connect with individuals electronically (via the Internet), by telephone or in person. Providers may also deliver relevant content to individuals, such as via e-mail or websites. However, providers must typically operate within the limited framework of a host platform which provides such capabilities in a disassociated manner. For example, a provider may use a networked personal computer (PC) to access an electronic communication mechanism. The provider may then access a separate server to push content to the individual. Also, the provider may then access yet another server to record notes, update scheduling information and/or perform other administrative tasks. However, switching between these environments oftentimes leads to inefficiency and potentially risks update errors. 
     In addition, individuals may undergo multiple “change-in-life” events over time. Change-in-life events can include, for example, changing one&#39;s name, marital status, listing of dependents, employment, insurance, health status, and so forth. As a result, providing a health services program to the same individual over time, including tracking the individual&#39;s progress, is challenging. Adding to this difficulty, health information itself also typically requires security and safe handling to ensure patient privacy. For example, the U.S. Health Insurance Portability and Accountability Act of 1996 (HIPAA) establishes certain guidelines for the secure treatment of Protected Health Information (PHI). 
     What is needed is an improved mechanism for more efficiently performing the necessary tasks for administering a health services program. Also, a mechanism for providing health services program to individuals, despite change-in-life events, is needed. Also, there is a need for an improved system for onboarding participants of health services programs. 
     This background information is provided to reveal information believed by the applicant to be of possible relevance to the present technology. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present technology. 
     SUMMARY OF THE INVENTION 
     The present inventors have determined that health services programs may be efficiently administered by providing a plurality of health services modules that are “horizontally integrated” on a platform. A rules engine is operative to identify enumerated events such that an event in one module triggers the rules engine to propagate a related event in one or more other modules. Such health services modules may be components operable for one or more of (1) live video conferencing, (2) scheduling, and/or (3) health services program data/content. Additional health services modules (“add-on modules”) may also be provided on the platform and similarly horizontally integrated, such as for (1) daily check-in, (2) managing medications, (3) updating/monitoring health number, (4) social access, and/or (5) rewards. 
     As used herein, “horizontally integrated”/“horizontal integration” refers to connections between modules at a common hierarchy level such that an update in one module propagates a related update in another module. Integration of the aforementioned modules results in an enabled platform that is readily portable to host platforms and optimized for delivering health services programs with increased efficiency. Horizontal integration is accomplished using a rules engine connected to each module that is configured to monitor enumerated events in the modules and propagate a change in other module corresponding to the enumerated event. Integrations include the ability to link various modules into a curriculum of care and coaching, for a cohesive program that incorporates various modules for the optimization of outcomes through the education and influence of patients and plan members. 
     Module updates may be propagated as follows: (1) selecting disease management or health content via health services program data may initiate scheduling with providers for counseling sessions or classes, and may initiate countdowns, reminders and/or a “start now” link for video conferencing; (2) selecting scheduling data may initiate delivery of particular health content, and may initiate countdowns, reminders and/or a “start now” link for video conferencing; and (3) selecting video conferencing may initiate delivery of particular health content (such as a provider pushing an article), may provide optional recording of video conferencing data (such as a recorded mp3 or an automated transcript), may capture the call date/time, duration, completion, attendees or the like in scheduling data, and/or may trigger a follow up appointment in scheduling data. The modules may be integrated using API interfaces and may tie in to a host platform providing health content and scheduling information via embedded service calls. 
     In addition, “unique identification codes” may be associated with (1) classes of health services programs or “health cubes,” and (2) health information about particular individuals possessing the unique identification codes. Moreover, unique identification codes may be linked to health services programs and related content for individuals groups of health programs, qualification criteria and pricing specified by specific clients. By determining common relationships between health information associated with differing identification codes, the identification codes can be linked to persistently provide health benefits for the same individual over time, despite changes in codes. Also, by associating a measurement result specific to an individual with a unique identification code, specific programs based the measurement result can be recommended, and participation by individuals can be encouraged. Participation and use of modules creates track-able and reportable activities that can be leveraged in analytics and reporting, for purposes such as incentives management and progress reporting. 
     The system may be deployed in scalable environments, such as via cloud computing, to provide cost-effective program offerings. Accordingly, by integrating embodiments of the present invention, host platforms may deliver health programs while focusing on the quality of the health benefit offerings. Integration can be achieved via portable modules making Application Program Interface (API) calls or via white label pages that may be embedded. 
     The system may also utilize Java Script Object Notation (JSON), Representational State Transfer (REST) and/or other standards, architectural styles or techniques to provide integration capability with host platforms. In addition, information can be advantageously extracted via pre-prepared reports, such as via Extensible Markup Language (XML), Extensible Stylesheet Language Transformations (XSLT) and/or XML Schema Definition (XSD) files. 
     The system may also provide Data as a Service (DaaS) by storing health information about individuals and/or related aspects. Configurable data analytics and quantitative and qualitative analysis results may also be determined and made available, such as via secure reports and/or API calls. 
     It is also contemplated to provide a curriculum-building program for easily creating and defining health services activities or other assets, grouping such assets into an event, including with notifications, incentives, and so forth, and arranging such events along a program timeline. The combination of content and delivery as prescribed in an administrator designed engagement curriculum is a unique approach for scripting partial and total experiences for individuals and groups of individual users. 
     Specifically, one aspect of the invention may provide a horizontally integrated system for administering a health services program executable on an electronic computer according to a program stored in a non-transient medium to implement: a plurality of modules, including: (a) a video conferencing module configured to enable live video conferencing over a computer network: and (b) a health services module configured to index a plurality of health services content; and a rules engine in communication with each of the plurality of modules. The rules engine may be configured to provide an update to at least one of the plurality of modules according to an event that occurs in another of the plurality of modules. 
     The plurality of modules could also include a scheduling module configured to receive scheduling information relating to a plurality of time slots for health services. The plurality of modules could also include one or more “add-on” modules. 
     Another aspect may provide a method for administering a health services program from an electronic computer providing a video conferencing module configured to enable live video conferencing sessions over a computer network, a health services module configured to index a plurality of health services content, and a scheduling module configured to receive scheduling information relating to a plurality of time slots for health services. The method may include: (a) monitoring an event that occurs in a first module, the first module being at least one of the video conferencing module, the health services module and the scheduling module; and (b) providing an update in a second module according to the event, the second module being at least one of the video conferencing module, the health services module and the scheduling module. 
     Another aspect may provide a system for building a curriculum for providing health services, the system executable on an electronic computer according to a program stored in a non-transient medium to: (a) provide a first health services program that includes a first set of health services activities; (b) provide a second health services program that includes a second set of health services activities, the second health services program different from the first health services program; and (b) graphically display the first and second sets of health services activities with respect to a common timeline. 
     In addition, the present inventors have determined that a registration card or similar document (such as a boarding pass) may be used to effectively onboard participants of health services programs. A data structure may store a plurality of unique identification codes linked to data elements providing personally identifiable information of participants. A document may then be generated to include an indicium, such as a QR code and/or bar code, for indicating the unique identification code for the participant, a personal identifier and a logistics detail for a biometric event. Upon receiving the unique identification code from the document, such as at the biometric event, the data element in the data structure may then be linked to an electronic medical record of the participant. 
     As a result, a biometric screening event may be streamlined by giving a participant a single document which may be used, among other things, to tie into the participant&#39;s medical record, provide an instruction indicating a type of biometric measurement to be taken, capture results, and the like, while identifying the participant quickly by simply verifying a government-issued identification. 
     Accordingly, another aspect may provide an improved system for onboarding a participant of a health services program. The system may include: a data structure containing a plurality of unique identification codes, each of the unique identification codes being linked to a data element providing personally identifiable information of a participant; and a document for providing to a participant. The document may include: (a) an indicium indicating a unique identification code from among the plurality of unique identification codes in the data structure; (b) a personal identifier of the participant, the personal identifier being included in a data element providing personally identifiable information of the participant, the data element being linked to the unique identification code in the data structure; and (c) a logistics detail for a biometric event. Upon receiving the unique identification code from the document, the data element providing personally identifiable information of the participant may be further linked to an electronic medical record of the participant. 
     Another aspect may also provide an improved method for onboarding a participant of a health services program. The method may include: storing a plurality of unique identification codes in a data structure, each of the unique identification codes being linked to a data element providing personally identifiable information of a participant; providing a document to a participant, the document including: (a) an indicium indicating a unique identification code from among the plurality of unique identification codes in the data structure; (b) a personal identifier of the participant, the personal identifier being included in a data element providing personally identifiable information of the participant, the data element being linked to the unique identification code in the data structure; and (c) a logistics detail for a biometric event; and upon receiving the unique identification code from the document, linking the data element providing personally identifiable information of the participant to an electronic medical record of the participant. 
     These and other features and advantages of the invention will become apparent to those skilled in the art from the following detailed description and the accompanying drawings. It should be understood, however, that the detailed description and specific examples, while indicating preferred embodiments of the present invention, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the present invention without departing from the spirit thereof, and the invention includes all such modifications. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Preferred exemplary embodiments of the invention are illustrated in the accompanying drawings in which like reference numerals represent like parts throughout, and in which: 
         FIG. 1  is a block diagram illustrating a horizontally integrated system for administering a health services program in communication with a host platform in accordance with an embodiment of the invention; 
         FIG. 2  is a diagram illustrating a first data structure linking unique identification codes to health cubes in accordance with an embodiment of the invention; 
         FIG. 3  is a diagram illustrating an exemplar mechanism for providing unique identification codes to individuals in accordance with an embodiment of the invention; 
         FIG. 4  is a diagram illustrating a second data structure for linking unique identification codes to health information of individuals in accordance with an embodiment of the invention; 
         FIG. 5  is a diagram illustrating a plurality of health services activities, including content and time slots, arranged with respect to a timeline via a graphical display in accordance with an embodiment of the invention; 
         FIG. 6  is a block diagram illustrating operation of the horizontally integrated system of  FIG. 1  in a system environment; 
         FIG. 7  is a diagram illustrating a graphical view for delivery of the health services program of  FIG. 1  to an individual; 
         FIG. 8  is a diagram illustrating expanded tiles of the graphical view of  FIG. 7 ; 
         FIG. 9  is a flow diagram illustrating an exemplar system for onboarding participants of health services programs; and 
         FIG. 10  is an exemplar document for providing to participants with respect to  FIG. 9 . 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     System Architecture 
     Referring now to  FIG. 1 , a computing environment  10  includes a horizontally integrated system  12  for administering a health services program in accordance with an embodiment of the invention. The horizontally integrated system  12  may be implemented, for example, via a cloud computing server, a private cloud or intranet server, or private desktop, and may be in communication with a host system  14 . The horizontally integrated system  12  includes a plurality of modules, including a video conferencing module  16 , a health services module  18  and a scheduling module  20 . The video conferencing module  16 , the health services module  18  and the scheduling module  20  may be software architectural components operable for computing functions including live video conferencing, indexing health services program data/content and scheduling, respectively. A rules engine  22  is in communication with each of the plurality of modules. 
     The video conferencing module  16  is configured to enable live video conferencing over a computer network such as the Internet. The video conferencing module  16  may implement an Internet telephony architecture which may be based on a peer-to-peer connection scheme. The video conferencing module  16  may open multiple ports via communications port  24  to enable communications with multiple clients, which may correspond to individuals (users) and providers (doctors, nurses, counselors, coaches, and the like), among multiple simultaneous sessions. Accordingly, video conferencing sessions may be one-to-one (such as a private counseling session between an individual and a provider) or one-to-many (such as a group session led by a provider with multiple attendees in which many attendees can see and talk to the provider and/or each other during sessions). 
     The health services module  18  is configured to index a plurality of health services content. As such, the health services module  18  may communicate with the host system  14 , via the rules engine  22 , to retrieve raw health services programs and content data which may be stored in a host platform content database  26 . Health services programs may include a variety of content pre-arranged by the host for addressing various health concerns such as weight loss, nutrition counseling, diabetes control, smoking cessation, pain management, stress reduction, depression counseling, addiction treatment, physical therapy, and the like. Content may include: (1) informational articles (such as newsletters, reports, bulletins, recipes, exercises, e-mails, blogs, and the like); (2) multimedia files (such as educational videos, pre-recorded webinars or audio tracks, and the like); (3) interactive tools (such as health calculators, calendars or journals), and the like. 
     As described below with respect to  FIG. 2 , the health services module  18  may use a first data structure  30  (which could be separately stored) to link “unique identification codes” to “health cubes” including health services programs and related content for individuals. In addition, as described below with respect to  FIG. 4 , the health services module  18  may use a second data structure  32  (which could be separately stored) to link the unique identification codes to health information about individuals possessing the unique identification codes. Upon receiving a unique identification code from an individual, the health services module  18  may determine programs and content eligible to the individual based on the health cube and health information linked to the unique identification code. Accordingly, the rules engine  22  may operate to limit the health services module  18  to delivering content according to the unique identification code which may be set by eligibility status. 
     The scheduling module  20  is configured to receive scheduling information relating to a plurality of time slots for health services. Accordingly, the scheduling module  20  may communicate with the host system  14 , via the rules engine  22 , to retrieve raw scheduling and calendaring data which may be stored in a host platform scheduling database  28 . This may include time slots on given dates by particular providers for particular topics. For example, one health coach may have a 30 minute time slot available four times a week for smoking cessation, while another health coach may have a 45 minute time slot two times a week for diabetes control. 
     The scheduling module  20  may use a local data structure  34  (which may be separately stored) for indexing scheduling data for providers and maintaining a virtual calendaring and appointment system. Accordingly, the scheduling module  20  may allow an individual to view time slot availabilities (by times and dates) for the various providers and/or various subjects of interest. For example, an individual may find, via the scheduling module  20 , a time slot for a particular pain management coach or a next available pain management coach, and may request an appointment accordingly. Requesting the appointment may temporarily hold the time slot reserved while the scheduling module  20  executes to confirm eligibility, confirm availability, request/secure payment, finalize the appointment and/or send notifications. 
     The rules engine  22 , in communication with each of the plurality of modules, is configured to provide an update to the video conferencing module  16 , the health services module  18  and/or the scheduling module  20  according to monitored events that occurs in other modules. In other words, the rules engine  22  may identify an enumerated event in a first module, such that the event triggers the rules engine to propagate a related event in a second, thereby providing horizontal integration between the first and second modules. 
     By way of example, a video conferencing session via the video conferencing module  16  may be an event which triggers the rules engine  22  to update the scheduling module  20 , such as to record a completion of the video conferencing session on the particular date/time with a particular duration, or which triggers the rules engine  22  to update the health services module  18  to deliver content to an individual that is related to the video conferencing session (such as a nutrition article related to a diabetes control session). Similarly, a selection of a time slot via the scheduling module  20  may be an event which triggers the rules engine  22  to update the health services module  18  to deliver or otherwise make available content related to the selection back to the individual, or which triggers the rules engine  22  to update the video conferencing module  16  to initiate a timer according to the selection of the time slot, which could serve as a continuous reminder or countdown the session, followed by a button to automatically launch the session. Likewise, a selection of content via the health services module  18  may be an event which triggers the rules engine  22  to update the video conferencing module  16  to suggest a video conferencing session to join (such as a selecting a tobacco article leading to suggestion to join a smoking cessation session), or may be an event which triggers the rules engine  22  to update the scheduling module  20  to suggest a time slot, such as for a particular provider or health subject, related to the selection (such as a selecting a tobacco article leading to a suggestion to schedule a time with a smoking cessation counselor). 
     Accordingly, the rules engine  22  enables connections between the aforementioned modules at a common hierarchy level such that an update in one module propagates a related update in another module. Integration of the aforementioned modules results in an optimized platform that is readily portable to host platforms, including those with user/provider ports and raw content, such as the host system  14 . 
     Additional health services modules (“add-on modules”) may also be provided on the horizontally integrated system  12  within the spirit of the invention. For example, an add-on module  36  may be simultaneously or subsequently deployed to the horizontally integrated system  12  to provide additional functionality. The rules engine  22  may have predefined hooks for monitoring events and propagating updates for various possible add-on modules, and/or the rules engine  22  may be updated, such as in software or firmware, to utilize new hooks for monitoring events and propagating updates. Examples of the add-on module  36  include: (1) a daily check-in module; (2) a managing medications module; (3) an updating/monitoring health number module; (4) a social access module; and/or (5) a rewards module. Additional aspects of the aforementioned modules are described with respect to  FIGS. 7 and 8 . 
     The rules engine  22  and the aforementioned modules may each include an Application Program Interface (API) element  38  for enabling cross communication and/or exposing integrated functionality. The API element  38  may also facilitate portability of the horizontally integrated system  12  for connection with the host system  14 . 
     The rules engine  22  may also be in communication with an analytic engine  40 . The analytic engine  40  may provide interactive functionality directed toward reporting and analytics for managers and executives. The analytic engine  40  may include an API element  38  for communicating with other modules, and may communicate with an analytic data structure  42  for mass information storage, and/or for exposing integrated functionality. Accordingly, the analytic engine  40  may provide Data as a Service (DaaS) and may allow, among other things, out of the box reports for executives and managers; data analytics with point and click access to various cross sectional information; and support for information storage or data warehousing for extended periods, such as greater than seven years. 
     In the environment  10 , the horizontally integrated system  12 , via the rules engine  22 , may also be in communication with a real time clock (RTC)  44  or another precision time protocol element. The RTC  44  may provide close synchronization between the aforementioned modules. 
     In embodiments, the rules engine  22  may also allow, among other things, providing industry standard authentication protocol information for sharing across enterprise platforms, such as in accordance with open standard for authorization (OAuth) 1.0; authenticating and updating profiles and branding information of health systems, providers, insurers, agents, brokers or employers; authenticating and updating profile information of counselors; configuring privileges given to organizations, members and counselors to obtain access to other modules; providing internal accounting, accounts payable and receivables for billing and invoicing; implementing extracts, transfers and loads (ELF) of information to and from external systems such as incentives management, claims management, pharmacies and electronic medical record (EMR) systems; providing dynamic content publishing, such as of articles, recipes and videos; and providing alerts and notifications sent via e-mail and/or Short Message Service (SMS) text messaging during various stages of workflow. 
     The horizontally integrated system  12  may be deployed in scalable environments, such as cloud computing a private cloud or intranet, or a private desktop, to provide cost-effective program offerings. The horizontally integrated system  12  could be provided via “Software as a Service” (SaaS), and embodiments may also utilize JSON, REST and/or other standards, architectural styles or techniques to provide integration capability with host system  14  as known in the art. In addition, information in the modular architecture can be advantageously extracted via pre-prepared reports, such as via XML, XSLT and/or XSD files. 
     In operation, the host system  14  may deliver content to the horizontally integrated system  12 , such as from the host platform content database  26  and the host platform scheduling database  28 . An individual or user may then access the host system  14  via a user interface  50 . Similarly, a provider may access the host system  14  via a provider interface  52 , and an administrative agent may access the host system  14  via an admin interface  54 . Differing access points allow differing access rights and privileges in the environment  10 , with the admin interface  54  essentially allowing maintenance ability. Moreover, each access point may be customized with respect to its own sets of rights and privileges. For example, various levels of the provider interface  52  may grant access to specific pieces of an individual&#39;s information based on permissions granted to the provider by the client or entity. Accordingly, a health coach, for example, might see all of an individual&#39;s information, including personal health information, via the provider interface  52 , while a case manager might only see contact and status information via the same provider interface  52 . 
     The host system  14  may provide front end interfaces to users and providers, such as external web site access via the user interface  50 , and internal web site access via the provider interface  52 . The host system  14  then receives requests from the user interface  50  and/or the provider interface  52 , and forwards the requests to the horizontally integrated system  12  for processing. The horizontally integrated system  12 , in turn, processes the requests and returns processed data to the host system  14  for serving to the user interface  50  and/or the provider interface  52 . 
     Data Flow 
     Referring now to  FIG. 2 , a diagram illustrating the first data structure  30  linking unique identification codes  62  to health cubes  64  which include health services programs and related content for individuals is provided in accordance with an embodiment of the invention. The unique identification codes  62  may include any number of data patterns of varying configurations and length. For example, in an embodiment, alpha numeric patterns, such as “33-AQR-54665” or “MZ-4XMZ-U9F,” may be used. 
     The health cubes  64  may represent classes of structured health services programs  66 , each including a plurality of pre-approved, relevant content  68 . Health services programs  66  may represent structured curriculums for a variety of health subjects, such as weight loss, nutrition counseling, diabetes control, smoking cessation, pain management, stress reduction, depression counseling, addiction treatment, physical therapy, and the like. Pre-approved, relevant content  68  for each program may include: (1) informational articles (such as newsletters, reports, bulletins, recipes, exercises, e-mails, blogs, and the like); (2) multimedia files (such as educational videos, pre-recorded webinars or audio tracks, and the like); (3) interactive tools (such as health calculators, calendars or journals); and (4) scheduling for live sessions. 
     The health cubes  64  are divided according to categories, tiers or groups, such as groups “A,” “B” and “C,” which provide health services programs and content for individuals with identification codes associated with the group. Associations may be configured, for example, based on health insurance benefits that individuals are eligible to receive. In addition, or alternatively, content  68  of the health cubes  64  may be unstructured or free from particular health services programs  66 . By way of example, as illustrated in  FIG. 2 , “Code  1 ,” “Code  2 ” and “Code  3 ” may be linked to health cube “A” for a first set of health services programs and content, while “Code  4 ” and “Code  5 ” may be linked to health cube “B” for a second set of health services programs and content. Accordingly, Codes  1 ,  2  and  3  may be provided to three individuals associated with a first employer, while Codes  4  and  5  may be provided to two individuals associated with second employer. 
     Referring now to  FIG. 3 , a diagram illustrating an exemplar mechanism for providing unique identification codes to individuals is provided in accordance with an embodiment of the invention. An individual  70  may participate in an event which produces a measurement result  72  specific to the individual  70 . For example, the individual  70  may be part of group in which many individuals have their blood pressure, height/weight, eyesight or other health related characteristics measured. 
     Next, a unique identification code  62  is provided to the particular individual  70 , such as a registration card  76  prompting the individual  70  to take action to register the unique identification code  62 . The registration card  76  may include, for example, a uniform resource locator (URL) or web address prompting the individual  70  to go online, such as to the host system  14  via the user interface  50 , to submit the unique identification code  62  for registration. In addition, or alternatively, the registration card  76  may include a quick response (QR) code  78 , a bar code  80  and/or any other indicia for the individual  70  to scan, such as via a smart phone or tablet, for faster action to register the unique identification code  62 . The individual  70  may be encouraged to do so, for example, to receive the measurement result  72 , reports or analyses relating to the measurement result  72  and/or program data or content associated with the measurement result  72 . The registration card  76  may also include health information  82  about the individual  70 , such as the individual&#39;s name or employer, as well as information about the provider. 
     The unique identification code  62  and/or the registration card  76  may be mailed, e-mailed, personally delivered, or otherwise distributed to the individual  70 . In addition, unique identification code  62  and/or the registration card  76  could also be provided without participation in an event and/or without the measurement result  72 . However, participation in an event and/or producing the measurement result  72  may be effective tools for encouraging participation by the individual  70 . 
     Alternatively, eligibility lists may be provided which can be checked, for example, during a registration process. As such, codes assigned to a client may then, in turn, be assigned to individual payers. 
     Referring now to  FIG. 4 , a diagram illustrating the second data structure  32  linking unique identification codes  62  to health information of individuals possessing the unique identification codes is provided in accordance with an embodiment of the invention. Health information about individuals, such as that collected during the event described with respect to  FIG. 3 , is then linked to the unique identification code  62 . For example, health information  94  corresponding to health data about the individual  70  may be linked to “Code  1 .” In addition, data spaces  96  may be reserved for linking health information about other individuals to other unique identification codes. The health information  94  may comprise a first data element  98  corresponding to the measurement result  72  and a second data element  100  corresponding to personally identifiable information and/or protected health information about the individual, such as the health information  82 . Accordingly, programs and content eligibility may be determined for an individual, and limited accordingly, based on the health cube and health information linked to the unique identification code. 
     If an individual has been in different programs, such as via the same or different clients or entities providing codes, the individual can be linked via common health information associated with the codes. For example, if multiple codes are determined to be associated with common personally identifiable information, those codes may be linked such that current and future information about an individual is accurately maintained. 
     A curriculum building process provides for easily creating and defining health services activities or other assets, grouping such assets into one or more events, including with notifications, incentives, and so forth, and arranging such one or more events along a program timeline. Accordingly, the combination of content and delivery as prescribed in an administrator designed engagement curriculum is a unique approach for scripting partial and total experiences for individuals and groups of individual users. 
     Referring now to  FIG. 5 , a diagram  101  illustrates a plurality of health services activities  102 , including content and time slots, arranged with respect to a common timeline  104  via a graphical display in accordance with an embodiment of the invention. When an individual selects a program  66 , content  68  with respect to the program may be graphically displayed to the individual over the timeline  104  via the rules engine  22 . This may be particularly useful for work load balancing, particularly when multiple programs are enrolled. 
     For example, a user may select enrollment in a first program “A” which may correspond to diabetes control. As a result, a first set of health services activities denoted “A 1 ” through “A 9 ” may appear as ticks, marks or other notations that are individually mapped with respect to the timeline  104  which may represent weeks. In week 1, health services activity A 1  may correspond to a live video conferencing session with a diabetes counselor; in week 2, health services activity A 2  may correspond to another live video conferencing session with a diabetes counselor, and health services activity A 3  may correspond to content for review, such as an informational article; and so forth. The user may also select enrollment in a second program “B,” which may correspond to smoking cessation. As a result, a second set of health services activities denoted “B 1 ” through “B 11 ” may also appear as ticks, marks or other notations that are individually mapped with respect to the timeline  104 . Also, the second set of health services activities B 1  through B 11  may be displayed with the first set of health services activities A 1  through A 9  on the timeline  104  to illustrate load balancing. 
     The health services activities  102  may be color coded to correspond to an activity type. For example, health services activities  102  corresponding to live video conferencing sessions may be orange, health services activities  102  corresponding to content may be red, and so forth. Moreover, the health services activities  102  may each be hyperlinks or other points of access for further information about the respective activity, such as via the modules of the horizontally integrated system  12 . 
     In addition, a client or entity may define a permissible set of live session types and allow a member to request a session that is not defined as part of a program. For example, a member could be in a program with a defined set of events, and also be allowed to request an additional event, such as a live session with a counselor, that is not defined as part of the program. The additional event could be provided, for example, for a fee or complimentarily. 
     Also, the curriculum design allows for the rules engine  22  to update the rules engine update health services activities according to events that occur in one or more of the modules. For example, notifications, alerts and/or incentives may be automatically applied to curriculum components such as health services activities  102 . A data structure, such as a reference table, may be maintained for tracking such updates, including notifications, alerts and/or incentives, and communicating with other modules of the horizontally integrated system  12 . 
     System Environment 
     Referring now to  FIG. 6 , a block diagram illustrating operation of the horizontally integrated system  12  in a system environment is provided in accordance with an embodiment of the invention. The individual  70  may use a computer  112 , smart phone, tablet or other computing device to access, via a computer network  114  (which may be the Internet), the host system  14 . In an SaaS configuration, the host system  14  may then, in turn, access a cloud computing environment  118  (or alternatively, a private cloud or intranet or desktop). The cloud computing environment  118  may include a server  116  which includes a network interface  120 , a processor  122  and a non-transient memory  124  for executing the horizontally integrated system  12  as described above with respect to  FIG. 1 . The server  116  may also be in communication with a mass storage  130  for holding the first data structure  30 , the second data structure  32 , and the like. 
     The host system  14  may provide a host company&#39;s website, for example, and communicate with the horizontally integrated system  12  via API&#39;s or embedded service calls. In an alternative arrangement, the horizontally integrated system  12  may be directly integrated in the host system  14 , or may be distributed over multiple computer systems. A separate manager system  134  may also be provided for admin access and maintenance ability. 
     In operation, the individual  70  may navigate to the host system  14  and submit a unique registration code via the user interface  50 . The host system  14  may, in turn, forward the unique registration code to the server  116 . The server  116  may, in turn, execute, for example, the health services module  18  to register the individual  70 . The server  116  may then execute to display a measurement result specific to the individual  70  to the computer  112 , and may determine and display a program data and content relevant to the measurement result and the individual  70 . For example, if the measurement result relates to a vision test, the server  116  could execute to provide a visual acuity result to the individual  70  and an analysis of the result as compared to age or peers, in addition to a vision insurance benefit for eyeglasses, a newsletter concerning maintaining good eye health, an advertisement for discounts on eyeglasses, and so forth. 
     The individual  70  may proceed to obtain allowable content via the health services module  18 . The individual  70  may also proceed to schedule time slots via the scheduling module  20 . The individual  70  may also proceed to engage in live video conferencing session via the video conferencing module  16 . The individual  70  may also view health services activities  102  with respect to a time line for work load balancing via the computer  112 . 
     User Experience 
     Referring now to  FIG. 7 , a diagram illustrating a first graphical view  150  for delivery of the health services program of  FIG. 1  to an individual thereby providing a user experience is provided in accordance with an embodiment of the invention. Upon authentication of a unique identification code or proper login credentials, the individual  70  may be presented with the first graphical view  150  via the computer  112 . The first graphical view  150  may include a welcome screen with a header  152  followed by a banner  154 . The header  152  may include links for obtaining help, obtaining mail messages, accessing account settings, logging out and/or similar functions. The banner  154  may include links indicating the time and date, upcoming events and reminders, pending tasks for the individual, health tips for the individual, and/or a quick pulse question for the individual (relating, for example, to mood, opinion or knowledge). An area below graphically displays a plurality of tiled links  156  generally relating to the implemented modules of the horizontally integrated system  12 . The links may appear, for example, as a plurality of tiled icons. 
     For example, a first tiled link  160 , which may be titled “Live Session,” may relate to the video conferencing module  16 . An active timer  162  may be actively displayed over the first tiled link  160  to serve as a countdown (and continuous reminder) for the next live video conferencing session. Clicking on the active timer  162  during the countdown may be an event in the video conferencing module  16  which triggers the rules engine  22  to display scheduling information for the next live video conferencing session to the graphical display via the scheduling module  20 . When it is time to join a next video conferencing session, the timer  162  may transition to a “Join Now” link to initiate the video conferencing session when clicked. Accordingly, the rules engine  22  may monitor events from and provide updates to video conferencing module  16  as described above with respect to  FIG. 1 . 
     A second tiled link  164 , which may be titled “Schedule,” may relate to the scheduling module  20 . Scheduling indicia  166  may be actively displayed over the second tiled link  164  to serve as a notification of a pending scheduling activity for a time slot. Accordingly, the rules engine  22  may monitor events from and provide updates to the scheduling module  20  as described above with respect to  FIG. 1 . 
     A third tiled link  168 , which may be titled “Daily Check-In,” may relate to the daily check-in module, which may be an add-on module. The daily check-in module may provide, for example, information relating to goals, notes, journal activity, and so forth, and may link to other modules which may provide related content. Accordingly, the rules engine  22  may monitor events from and provide updates to the daily check-in module. 
     A fourth tiled link  170 , which may be titled “Program Resources,” may relate to the health services module  18 . Accessing the health services module  18  may allow access to programs and content which may include links, for example to scheduling and video conferencing sessions. Accordingly, the rules engine  22  may monitor events from and provide updates to the health services module  18  as described above with respect to  FIG. 1 . 
     A fifth tiled link  172 , which may be titled “Medications,” may relate to the managing medications module, which may be an add-on module. The medications module may allow inputting and tracking medications. Certain medications could trigger the rules engine  22 , for example, to propose a video conferencing session, a time slot or content related to the medication, or provide a reward, via the rewards module, for consistently taking the medication. Accordingly, the rules engine  22  may monitor events from and provide updates to the social access module. 
     A sixth tiled link  174 , which may be titled “Health Numbers,” may relate to the updating/monitoring health number module, which may be an add-on module. The updating/monitoring health number module may allow entering health numbers, such as cholesterol levels, triglyceride levels, blood pressure, weight, and so forth, for tracking and monitoring over time. Certain health numbers could trigger the rules engine  22 , for example, to propose a video conferencing session, a time slot or content, such as a stress reduction program and content for consistently high blood pressure levels. Accordingly, the rules engine  22  may monitor events from and provide updates to the updating/monitoring health number module. 
     A seventh tiled link  176 , which may be titled “Social,” may relate to the social access module, which may be an add-on module. The social access module may allow sharing updates or links with others, for example, as a link to content from the health services module  18 . Accordingly, the rules engine  22  may monitor events from and provide updates to the social access module. 
     An eight tiled link  178 , which may be titled “Rewards,” may relate to the rewards module, which may be an add-on module. The rewards module may track incentives, such as cash rewards and discounts, for various events, such as attending video conferencing sessions, viewing content, and so forth. Accordingly, the rules engine  22  may monitor events from and provide updates to the rewards module. 
     Referring now to  FIG. 8 , a diagram illustrating expanded tiles of a second graphical view  200  is provided. The individual  70  could swipe across screens between the first and second graphical views  150  and  200 , respectively, selecting one or more of the aforementioned tiled links to dynamically display more information associated with the tiled links. For example, the first tiled link  160  (“Live Session”) may include the timer  162 , now timing a duration of an active video conferencing session, and a communications window  202  for the video conferencing. The second tiled link  164  (“Schedule”) may include a calendar  204  and an appointments/reminders area  206  for highlighting upcoming appointments and reminder times. The third tiled link  168  (“Daily Check-In”) may include a goals/notes area  208  for tracking goals and recording notes and an activity tracker  210 . The fourth tiled link  170  (“Program Resources”) may include a links area  212  to a plurality of programs and content, as well as a multimedia area  214  for viewing content. The fifth tiled link  172  (“Medications”) may include a medications listing area  216 , with icons for adding or subtracting medications, and a timeline area  218  for tracking dates/times for taking medications. The sixth tiled link  174  (“Health Numbers”) may include a data entry area  220  for inputting health numbers, along with links, for example, for updating the information and/or retrieving historical information. The seventh tiled link  176  (“Social”) may include a social update area  222  for preparing statements, content, links or otherwise for sharing, as well as social links  224  for selecting social media outlets. The eight tiled link  178  (“Rewards”) may include a rewards area  226  for tracking rewards and incentives. 
     A link from various sources, such as from the events/reminders in the banner  154 , the daily check-in module, the health numbers module, or the like, may lead to displaying the measurement result  72  described above with respect to  FIG. 3 . For example, a pop-up window  230 , specific to the individual  70 , may be displayed upon selecting one of the aforementioned links, along with related program data and content  232  which may correspond to the measurement result  72 . 
     Onboarding Participants 
     Referring now to  FIG. 9 , a flow diagram illustrating an exemplar system  300  for onboarding participants of health services programs is provided. A participant  302  may initially provide personally identifiable information in a registration step  304 . The personally identifiable information may comprise any information that is specific to the participant  302  for the purpose of uniquely identifying the participant  302  from other participants. The personally identifiable information may include, for example, one or more of the following: the participant&#39;s name, age, date of birth, home and/or work address, phone number, email address, social security number, insurance information, an electronic medical record, and the like. The personally identifiable information may be received by an employee, provider, system operator, or otherwise, and may correspondingly be entered as a data element  306  in a data structure  308  (which data structure  308  may be part of a first database stored in a non-transient medium and executing on a server). 
     In addition, the data structure  308  may operably store a plurality of unique identification codes  310  (or unique registration codes), illustrated by way of example as “Code  1 ,” “Code  2 ,” “Code  3 ,” and so forth. The unique identification codes may comprise alpha numeric (and/or symbolic) patterns or sequences, such “33-AQR-54665,” “MZ-4XMZ-U9F,” or “RCH 113442 042214 A E,” so long as the codes are sufficiently unique from one another. 
     Upon receiving and entering the data element  306  providing the personally identifiable information in the data structure  308 , the data element  306  may be linked to a particular unique identification code  310  (such as Code  1 ). In this manner, as personally identifiable information of additional participants are further entered into the data structure  308 , additional corresponding data elements  306  may similarly be linked to additional unique identification codes  310 . As a result, each participant entered in the data structure  308  may be associated with a particular unique identification code  310 . 
     Next, the participant  302  may be linked in the data structure  308  to one or more biometric events, each having logistics information  312 . A biometric event (or health screening event) may be any health related activity that may be provided for the participant  302 . A biometric event may be organized by an employer, a provider, or the like, and may preferably include obtaining a biometric measurement of the participant  302 . Biometric measurements may include, for example, measuring a participant&#39;s heart rate, blood pressure, cholesterol level, glucose level, height, weight, visual acuity, auditory acuity, physical fitness, dexterity, and the like. A participant may be linked to a biometric event based, for example, on a selection of benefits available from an employer, including such as a corresponding health cube  64  as described above with respect to  FIG. 2 . The logistics information  312  may include, for example, a date, time and/or location (such as an address and/or provider name) for the biometric event, illustrated as “Event  1 ” by way of example. The logistics information  312  may be provided by an employer or other entity, and may be entered in the data structure  308  to correspond with select participants  302  for biometric events accordingly. 
     In addition, the data element  306  may be further linked to an instruction  314  for a provider at the biometric event. For example, the instruction  314 , which may be accessed later by the provider at the biometric event for indicating useful information to the provider, such as no blood testing, in need of visual or auditory acuity testing and/or other similar pieces of information. 
     Next, in a generation step  316 , a document  318 , which may be a registration card or “boarding pass,” may be generated by the system  300  and provided to the participant  302 . The document  318  may include an indicium  320  for indicating the particular unique identification code  310  (from among the plurality of unique identification codes  310  in the data structure  308 ) linked to the participant  302 . The indicium may comprise, for example, a QR code and/or bar code that may be scanned to reveal the unique identification code  310 , and/or the unique identification code  310  in alphanumeric form. In one aspect, additional security may be provided by including on the document  318  information associated with an image for the patient. For example, upon reading the indicium  320 , an image of the patient, such as from the patient&#39;s employee file, could be displayed on a provider&#39;s screen in order to further confirm the patient&#39;s identity. 
     The document  318  may also include a personal identifier  322  of the participant  302 . The personal identifier  322  may be an aspect of the data element  306  (providing the personally identifiable information of the participant  302 ) linked to the particular unique identification code  310  in the data structure  308 . For example, the personal identifier  322  may be the name of the participant  302 . 
     The document  318  may also include a logistics detail  324  and/or other instruction information for the biometric event. The logistics detail  324  may be an aspect of the logistics information  312 , such as the date, time and/or a location for the biometric event. In one aspect, the indicium  320  could be further applied to provide the logistics detail and/or other instruction information. 
     Next, in providing step  330 , the document  318  is provided to the participant  302 . The document  318  may be provided to the participant  302  as a virtual document that may be displayed on a screen of an electronic device, such as a tablet or smartphone. In addition, or alternatively, the document  318  may be provided as a physical document (such as in paper form) operable for handling by the participant  302 . 
     Next, in onboarding step  332 , the participant  302  may attend the biometric event (Event  1 ) at the appointed time and location in accordance with the logistics detail  324  provided on the document  318 . At the biometric event, a provider or system operator may then read the indicium  320  to determine the unique identification code  310 , and in turn the data element  306 , of the participant  302 . In addition, the provider or system operator may optionally verify the participant&#39;s identity using a secondary source, such as a government-issued identification shown by the participant  302 . The provider or system operator may also observe the instruction  314  linked to the data element  306 . 
     Next, in measurement step  340 , a biometric measurement result  342  may be obtained from the participant  302  by the provider or system operator. The biometric measurement result  342  may be a measure, for example, of the participant&#39;s heart rate, blood pressure, cholesterol level, glucose level, height, weight, visual acuity, auditory acuity, physical fitness, dexterity, or the like. The biometric measurement result  342  may then be linked to the data element  306  (providing personally identifiable information of the participant  302 ) in the data structure  308 . 
     Having successfully on-boarded the participant  302  from the registration step  304  through measurement step  340 , in a connection step  344 , the provider or system operator may then link the data element  306  (providing personally identifiable information of the participant  302 ) to an electronic medical record  350  of the participant  302  (which electronic medical record  350  may be part of a second database  352  stored in a non-transient medium and executing on a server, and/or a part of the data element  306  in the data structure  308 ). The electronic medical record  350  of the participant  302  may be one of plurality of electronic medical records for various individuals, some of which may be participants. The electronic medical record  350  may be a collection of electronic health information about an individual in digital format that may be capable of being shared across different health care settings. 
     Referring now to  FIG. 10 , an exemplar document  318  for providing to participants as described above with respect to  FIG. 9  is provided. The document  318  may have the appearance and feel of a traditional airline boarding pass. The document  318  may be a paper document or a virtual document displayed on a screen  360  of an electronic device, such as a tablet, smartphone or other computer. 
     Accordingly, the participant  302  could select a first link  362  to print the document  318 , which may produce a physical document (in paper form) that may be handled by the participant  302 . The participant  302  could also select a second link  364  to push the document  318  to a smartphone or mobile computing device if it is not already being viewed in such form. The participant  302  could also select a third link  366  to close the window to cease displaying the document  318 . 
     In one aspect of the invention, the document  318  may optionally comprise two portions which may be physically or virtually detachable from one another. A first portion  370  may comprise a larger portion of the document  318  which may be taken by the operator or system provider at the biometric event and kept on file. A second portion  372  may comprise a smaller portion of the document  318  which may be retained by the participant  302  for the participant&#39;s proof of participation and/or records. Both the first portion  370  and the second portion  372  of the document  318  may include the indicium for indicating the particular unique identification code  310 , the personal identifier and the logistics detail for the biometric event as described above with respect to  FIG. 9 . 
     For example, the first portion  370  may include a bar code  380  for indicating the unique identification code  310 , in addition to the unique identification code  310  in alphanumeric form  382 . The first portion  370  may also include the participant&#39;s name  384  as a personal identifier. The first portion  370  may also include a date, time and location  386  for the biometric event as the logistics detail. 
     Similarly, the second portion  372  may include a QR code  390  for indicating the unique identification code  310 , in addition to the unique identification code  310  in alphanumeric form  392 . The second portion  372  may also include the participant&#39;s name  394  as a personal identifier. The second portion  372  may also include a location  396  for the biometric event as the logistics detail. 
     Alternative embodiments may implement various features described above in hardware and/or software and with varying levels of integration. In addition, alternative embodiments may combine or further separate or distribute hardware elements, or software elements, as may be appropriate for the task. 
     Although the best mode contemplated by the inventors of carrying out the present invention is disclosed above, practice of the above invention is not limited thereto. It will be manifest that various additions, modifications and rearrangements of the features of the present invention may be made without deviating from the spirit and the scope of the underlying inventive concept.