WO2016003974A1 - Systeme et procede pour l'automatisation de la gestion de relation de soins de sante et de bien-être multi-locataire - Google Patents

Systeme et procede pour l'automatisation de la gestion de relation de soins de sante et de bien-être multi-locataire Download PDF

Info

Publication number
WO2016003974A1
WO2016003974A1 PCT/US2015/038438 US2015038438W WO2016003974A1 WO 2016003974 A1 WO2016003974 A1 WO 2016003974A1 US 2015038438 W US2015038438 W US 2015038438W WO 2016003974 A1 WO2016003974 A1 WO 2016003974A1
Authority
WO
WIPO (PCT)
Prior art keywords
healthcare
user
relationship management
management system
data
Prior art date
Application number
PCT/US2015/038438
Other languages
English (en)
Inventor
Tim KAUBLE
Seth ELY
Brad Bostic
Tom Cooper
Jason WOLFGANG
Original Assignee
Hc1.Com, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hc1.Com, Inc. filed Critical Hc1.Com, Inc.
Publication of WO2016003974A1 publication Critical patent/WO2016003974A1/fr

Links

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/20—ICT specially adapted for the handling or processing of medical references relating to practices or guidelines

Definitions

  • FIG. 1 illustrates a flowchart of a method for healthcare relationship management.
  • FIG. 2A illustrates a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 2B illustrates a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 2C illustrates a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 2D illustrates a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 2E illustrates a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 2F illustrates a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 2F illustrates a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 3A displays the architecture of a system for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 3B displays the architecture of a system for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 3C displays the architecture of a system for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 3D displays the architecture of a system for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 3E displays the architecture of a system for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 4 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 5 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 6 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 7 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 8 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 9 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 10 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 11 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 12 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 13 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 14 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • FIG. 15 displays a screenshot of a user interface presented in association with a system and/or method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • a healthcare organization may include, but is not limited to, a doctor's office, a hospital, a pharmacy, a laboratory, a healthcare information system, a radiology group, a healthcare service provider, an integrated delivery network, an accountable care organization, or other organization within the healthcare industry.
  • the method 100 includes receiving raw healthcare data in step 102, organizing and structuring data to find problem areas in step 104, organizing and structuring data to find contextual and relevant relationships in step 106, identifying solutions to problem areas from the data in step 107, calling the solutions to action in step 108, and ensuring accountability to the actions in step 110.
  • the method 100 includes receiving raw healthcare data in step 102.
  • a healthcare organization may receive and/or obtain raw healthcare data from a variety of resources.
  • resources may include, but are not limited to, a lab information system, radiology information system, hospital information system, electronic medical record, data warehouse, revenue cycle management system, general ledger, accounts payable provider, a billing provider, a customer relationship management solution, and others.
  • a healthcare organization receiving and/or obtaining such data may store the data in one or more locations, such as, for example, a database or data warehouse.
  • Information retrieved or obtained during step 102 may include, but is not limited to, lab test orders, lab test results, radiology orders, interpretive radiology results, physician information, patient information, prescription information, patient encounters, scheduling, insurance information, patient payment information, turnaround time, ordering location information or other information from one or more of the information resources.
  • a laboratory that processes diagnostic lab tests may store information concerning such tests and associated results in a laboratory information system and/or laboratory management system ("LIS").
  • LIS laboratory information system and/or laboratory management system
  • information from the LIS may be received through an application programming interface, web services infrastructure, or other data creation methods.
  • Data may also be created from a LIS through simple exports of data in comma separated value, raw text, sockets, or otherwise and then uploaded to the healthcare relationship management system.
  • data may be retrieved from an electronic health information repository through HL7 TCP/IP and/or an HL7 real-time feed.
  • the method 100 includes organizing and structuring data to find problem areas in step 104.
  • raw data obtained from various sources in step 102 is categorized and organized within a system in step 104.
  • opportunities for improvement may be identified through analysis of the data. For example, an organization ingesting a totality of metrics surrounding lab tests conducted may find that lab tests, on average, take longer to turn around than the organization's goal.
  • an organization ingesting prescription data for patients may find that a certain type of medication, on average, is being prescribed to more patients than expected.
  • a hospital may uncover, by ingesting prior patient prescription information, that an individual patient has experienced multiple negative results from prescribed medications during a single hospital stay identifying that a certain prescription should not be used.
  • a testing instrument may indicate a result reading that is either inconsistent or inaccurate; based off of this result, an indication can be surfaced that result remediation may be required.
  • a healthcare relationship management system enables an organization to identify contextual and relevant information within the organized and structured data related to the problem areas in step 106.
  • the problems identified in step 104 are analyzed to identify relevant and contextual data surrounding such problems. For example, if an identified problem includes a certain medication being prescribed at an above-average rate, then the contextual and relevant data related to this problem may be a listing of individual doctors and data surrounding medication prescription rates. In another example, if a problem is identified related to the average time that it takes a lab test to close, contextual and relevant data surrounding this problem may be individual worker time-to-close rates for a lab over a period of time.
  • problem areas identified from organized data on the average, over a window of time, or with a certain business group may be analyzed further to determine root cause. For example, if laboratory tests are taking, on average, longer than expected, an organization may drill into the raw data to find specifically why these lab tests are taking longer. In one instance, the data may be skewed due to an individual employee taking much longer than all other employees. In another example, a collection of testing instruments can be inspected to verify quality, consistency, and average output. In another instance, the data may show that a customer is generally slow in getting all of the information needed to perform a lab test to the organization. In another example, an organization may drill down into a finding that a certain medication is being prescribed over the expected rate to see that an individual doctor is prescribing this medication to a very high percentage of patients.
  • an organization may create actionable tasks in step 108.
  • the organization may take the data associated with the root cause and assign a solution to address the root cause to an individual employee or team within the healthcare relationship management system. The employee or team with the assigned task will then be required to remediate the root cause by implementing the solution.
  • the healthcare relationship management system can ensure the action is completed by the assignee. Then, the method 100 may repeat its steps as new data is obtained, new problem areas are discovered, new solutions are identified, etc.
  • the method 220 includes registering an input source in step 222, assigning an input source to a user in step 223, generating a device identifier in step 224, retrieving health information in step 225, categorizing health information 226, assigning user roles 227, and assigning user nodes in step 228.
  • the method 220 includes registering an input source in step 222.
  • a healthcare relationship management system may receive health care information from various sources, including, for example, electronic health record systems, systems conforming to HL7 standards, wearable technology (i.e. Fitbit, smart watches, etc.), Internet-enabled health measurement tools (scales, heart monitors, step monitors, wireless glucose meters, etc.), any exercise-based smartphone application, and other devices.
  • any of such sources may be registered to the healthcare relationship system. Registration may occur by manual entry of the device information into the healthcare relationship management system or an authorization of the device between the device and the healthcare relationship management system.
  • a device interested in registering with the healthcare relationship management system in step 222 may communicate with the healthcare relationship management system over a computer network, such as the Internet, and describe the types of data that the device would like to transmit to the healthcare relationship management system.
  • a user may manually enter information concerning the device into a database for the healthcare relationship management system in step 222.
  • the device may follow a registration path made available through web services and/or application programming interfaces at the healthcare relationship management system to create a new input source record for the device.
  • the device may communicate real time with such web services over a computer network, like the Internet.
  • an input source manufacturer may enter into a relationship with a healthcare relationship management system such that health information may flow between the healthcare relationship management system and the input source manufacturer.
  • the input source manufacturer may periodically register input sources with the healthcare relationship system as users purchase and activate devices made by the input source manufacturer. For example, a user purchases a new network-capable scale with the capability to communicate data from the scale (i.e. weight, user inputted information, etc.) to the manufacturer of the scale over a computer network.
  • the input source manufacturer desires to obtain this information from the user to provide certain services to the user.
  • the input source manufacturer may have entered into a data sharing relationship with a healthcare relationship management system such that the input source manufacturer periodically sends such information from the user registered scale to the healthcare relationship management system, such as, for example, through a web services and/or application programming interface infrastructure.
  • the method 220 includes assigning an input source to a user in a healthcare relationship management system.
  • the device registered in step 222 is assigned a user within the healthcare relationship management system such that data received at the healthcare relationship management system from the device is associated with the user, such as, for example, in a database.
  • the device may be associated with the user in a single-sign on infrastructure such that any information used within a multi-tenant healthcare relationship management system may be associated with the user at each tenant.
  • the method 220 includes generating a unique device identifier for the device in step 224.
  • the unique device identifier may be associated with the device in a database such that any information received at the healthcare relationship management system is related to the unique device identifier generated in step 224.
  • the method 220 includes retrieving health information in step 225.
  • a system may retrieve or receive health information from one or more resources, such as, for example, as discussed in step 102 of the method 100.
  • the health information is categorized in step 226.
  • portions of the health information may be categorized to identify whether information is protected health information ("PHI") under one or more regulations, laws, privacy commitments, or otherwise and, therefore, should be protected in accordance with additional care than other information.
  • portions of the health information may be categorized as confidential and, accordingly, should be treated with additional care than other information.
  • portions of the health information may be categorized under need-to-know classifications for various operational roles within an organization. Such classifications may be stored in a database, data management utility, or third party resource.
  • an enterprise performing various types of lab tests for laboratories or hospitals may categorize some information received from a LIS as PHI according to the Health Insurance Portability and Accountability Act and its supporting regulations (collectively, "HIPAA").
  • HIPAA Health Insurance Portability and Accountability Act
  • other laws may be at issue, such as the Health Information Protection Act in Canada ("HIP A").
  • the categorization indicates that this information is only to be viewed by individuals with a need to know and protected in accordance with HIPAA, HIPA, and other state and federal laws and regulations. Controlled permission can then be granted to another user in the healthcare relationship management system.
  • the categorization may be stored within a column of a database corresponding to the categorized information.
  • the categorization may be stored in a separate database with a reference to the categorized information. It should be appreciated, of course, that the categorization might be stored in any variety of ways provided that the healthcare relationship management system can retrieve the categorization and the information categorized.
  • the method 220 includes assigning user roles in step 227.
  • the healthcare relationship management system may include one or more defined users.
  • the users are assigned roles according to each user's functional role. For example, a user in the sales department may be assigned a sales role. Similarly, a user in the operations department may be assigned an operations role.
  • the method 220 includes assigning user nodes in step 228.
  • each user in the healthcare relationship management system may be assigned a node corresponding to a hierarchical view of the healthcare organization for the user.
  • the hierarchical view for the healthcare organization may take the form of a tree with stems that segment the organization into one or more business areas, regions, or other delineation.
  • a hierarchical view of an organization may be created related to each State in the United States where the organization is located.
  • a user that provides operations support in Atlanta, Georgia may be associated with the Georgia leaf in the hierarchy.
  • a user that provides managerial support over a sales team in Chicago, Illinois may be associated with the Illinois node.
  • a healthcare organization may create a hierarchical view of the organization based on a simple structure of the entity into disparate business units.
  • a large hospital may create separate nodes for different practice types, like dermatology, oncology, general practitioners, and the like. It should be appreciated, of course, that the hierarchical view of the organization may take on any structure to create a set of nodes and the examples discussed herein are merely examples.
  • each user may be assigned to more than one node.
  • a user providing sales to the Midwest region may be associated with the nodes for Illinois, Iowa, Missouri, and other Midwest States.
  • a manager overseeing IT support personnel working in the dermatology and oncology departments may be associated with both the dermatology and oncology nodes, provided, of course, that the healthcare organization has created a hierarchical view of the organization based on practice type.
  • a healthcare organization may create multiple hierarchical views.
  • the hierarchical view based on State of practice may be used in connection with the hierarchical view based on practice type.
  • a manager of dermatology and oncology sales with personnel in Missouri and Illinois may be associated with the dermatology and oncology nodes in the hierarchical view based on practice type and the nodes for Missouri and Illinois in the hierarchical view based on States of the United States.
  • the combination of assigning user roles in step 227 and assigning user nodes in step 228 may enable a healthcare organization to provide role-based and node-based access control to information.
  • a user's role may authorize his or her access to certain types of information and the user's node membership may authorize his or her access to individual records.
  • a care coordinator for a large hospital based in multiple geographic regions is given the task of calling recently discharged patients and attempting to get these patients to schedule checkups with their assigned general practitioner in the hospital.
  • the hospital itself is based in Florida and Georgia, but the care coordinator only practices in Florida. Accordingly, the care coordinator is assigned the role of care coordination in step 227 and the node of Florida in step 228. The care coordinator is not assigned to the node for Georgia.
  • the care coordinator's assigned role gives him or her access to personal information of patients stored within the healthcare relationship management system so that the care coordinator may make calls to patients.
  • the role therefore, authorizes the care coordinator to access a patient's name, phone number, email address, medical conditions; recent procedure performed in the hospital, general treatment outcome, and last date of visit to his or her general practitioner.
  • the care coordinator's role does not grant him or her access to additional information about patients stored in the system, like each patient's blood type, because this information is not necessary for the care coordinator to perform his or her job of attempting to schedule a checkup appointment for the patient with his or her general practitioner.
  • the care coordinator's node provides an additional layer of protection. If the care coordinator attempts to view patient records in Florida, the care coordinator's membership to the Florida node authorizes this access. However, if the care coordinator attempts to access a record for a patient in Georgia, the care coordinator is denied access because the care coordinator is not a member of the Georgia node.
  • the method 230 includes authenticating a user in step 231, receiving a user access query in step 232, evaluating user role authorization in step 233, retrieving categorized health information in step 234, evaluating user authorization in step 236, and rendering a page based on user authorization in step 238.
  • the method 230 includes authenticating a user in step 231.
  • a user may be required to authenticate to a healthcare relationship management system prior to obtaining access.
  • the healthcare relationship management system may be a multi-tenant portal available over a computer network, such as, for example, the Internet.
  • the healthcare relationship management system may request access credentials from a user upon the user's first attempt accessing the healthcare relationship management system.
  • a user provides access credentials and/or otherwise authenticates to his or her identity to the healthcare relationship management system prior to performing any other steps in the method 230.
  • the user device may authenticate to the healthcare relationship management system by providing a username and password, referencing a previously generated session (i.e. through a cookie), through a third-party authentication provider (i.e. OAuth, openid, or others), providing a trusted certificate, token or other one-time pad resource in addition to PIN, or other authentication mechanism.
  • a third-party authentication provider i.e. OAuth, openid, or others
  • the authentication step 231 may authenticate a user to a single sign on access control mechanism.
  • the single sign on authentication may provide the user with accepted authentication to a plurality of systems and/or applications within the healthcare relationship management system.
  • the single-sign on authentication may be enabled through methods known in the art, such as, for example, Kerberos, persistent cookies, integrated Windows authentication, and SAML.
  • the method 230 includes receiving a user access query in step 232.
  • a user through a user device may attempt to access a page for rendering as transmitted by the healthcare relationship management system over a computer network, such as, for example, the Internet.
  • a user device may include, but is not limited to, a laptop, desktop, personal computer, smartphone, tablet, wearable technology, smart television, or other network-capable electronic device.
  • the healthcare relationship management system receives a transmittal request from a user device at a front-end web-server infrastructure.
  • the method 230 includes evaluating the user role authorization in step 233.
  • the healthcare relationship management system may determine whether the user transmitting the access query for a page has authorization, by role, to view the page and/or information requested. For example, if the user is requesting a page that contains patient credit card payment information and the user is assigned to an intern role, which does not have access to any patient credit card payment information, then the healthcare relationship management system may deny the user access query and not retrieve any requested information.
  • the healthcare relationship management system may replace unauthorized data, like credit card information, with non-sensitive data, like an individual's name or unique identifier.
  • the role-based authorization may be performed in a variety of ways.
  • the application layer of the healthcare relationship management system may query a database for the user role and compare the retrieved role to the information requested in the user access query to determine whether the user is authorized, by role, to access and interact with the requested data.
  • the database, data structure, or data repository where the data is stored may have an inherent authorization model.
  • the role authorization evaluated in step 233 may indicate that the user is associated with one or more globally defined roles in a multi-tenant environment.
  • a user may be defined with generally defined roles for a multi-tenant environment that, when evaluated locally at each tenant application or system, may result in differing authorization levels.
  • the multi-tenant healthcare relationship management system may use single sign on access controls to authenticate the user in step 231 and, then, evaluate one or more globally defined roles for the multi-tenant system in step 233.
  • a multi-tenant healthcare relationship management system may define certain portal user types, such as, for example, Coach, Provider, and Patient.
  • portal user types such as, for example, Coach, Provider, and Patient.
  • Each user in the healthcare relationship management system may be assigned one or more global portal user types.
  • Each tenant system and application within the healthcare relationship management system may implement authorization levels associated with the global portal user types in various (and different) ways.
  • the New York Hospital may implement the Provider role to authorize users assigned that role to update healthcare records within the healthcare relationship management system within the New York Hospital application.
  • the Chicago Hospital may implement the Provider role only to authorize users assigned that role to view healthcare records within the healthcare relationship management system within the Chicago Hospital application.
  • the New York Hospital has applied the Provider role in a different authorization scheme that the Chicago Hospital.
  • the healthcare relationship management system retrieves categorized health information (i.e. from step 234 of the method 220) based on the user access query in step 233.
  • the application layer of a healthcare relationship management system may retrieve any data requested by the user, which the user is authorized to view based on role.
  • the healthcare relationship management system may present the data to the user device through a web services
  • the healthcare relationship management system may pull the authorized data at an application layer from a database and present the authorized data through a web server or other presentation layer.
  • the method 230 includes evaluating user node authorization in step 236.
  • each record of information requested by the user i.e. row of data, a patient, etc.
  • the user's assigned nodes i.e. through the step 228 of the method 220
  • the healthcare relationship management system may evaluate each retrieved record from step 234 to determine whether the node assignment of the user in Maine and New York is authorized to view such records.
  • the healthcare relationship management system may elect to not present such data to the user when transmitting a page for rendering the data request in step 238.
  • the management system may be configured to render a page that masks records that the user is not authorized to view based on node assignment.
  • the page for rendering on the user device may include malformed data, masked data, or otherwise unreadable data where the unauthorized data would usually be presented.
  • the page with the malformed or unreadable data enables the unauthorized employee to perform his or her job function for the data that the employee is authorized to view.
  • the results obtained in step 233 may be combined with the evaluation performed in step 236 such that data is not retrieved in the event that a user is unauthorized to view such data.
  • the data is not available for rendering in step 238 and, therefore, the unauthorized user does not see the data.
  • the method 230 may be performed to pull healthcare information based on user authorization across multiple tenant applications or system into one page view.
  • the steps 232- 236 are repeated in the method 230 to request information from multiple tenant systems or applications and render all information in step 238 according to differing authorization levels for the user across the multiple tenant applications or systems.
  • a patient may be assigned the Patient global role in the healthcare relationship management system.
  • the Patient may have seen a primary care physician at the New York Hospital related to an illness.
  • the primary care physician at the New York Hospital may have referred the patient to a specialist at the Chicago Hospital.
  • the specialist may have performed numerous laboratory tests and generated associated results using the Chicago Laboratory.
  • the New York Hospital, Chicago Hospital, and Chicago Laboratory each may be tenants within the healthcare relationship management system and have transmitted healthcare information through various stages of the patient's care, including the results from the Chicago Laboratory, symptoms and doctor's notes from the initial visit at the primary care physician at the New York Hospital, and in-depth analysis and diagnostic theories from the specialist in the Chicago Hospital.
  • the patient may authenticate to a portal provided by the healthcare relationship management system in step 231 and obtain a single sign on token.
  • an application or web page may be configured to pull information from all tenants in the healthcare relationship management system with healthcare information concerning the user: Chicago Hospital, New York Hospital, and Chicago Laboratory.
  • a user access request is performed, such as described in step 232
  • the patient's role and appropriate authorization level is evaluated, such as described in step 233
  • the requested health information is retrieved according to the authorization level, such as described in step 234, and the patient's node authorization may be evaluated, such as described in step 236.
  • the patient's web browser or application may render a single view into the entirety of the patient's care known to the healthcare relationship
  • this authentication and authorization scheme may provide access to one or more source of information in a manner that complies with state and federal laws and regulations, such as HIPAA. Accordingly, for the patient to be able to view all patient information from each tenant, each tenant must have authorized the patient's account to view the data and implemented the Patient role appropriately.
  • the patient example described above may also be configured for a provider, payer, or other user that has interest in combining healthcare information from one or more sources for analytics, diagnostics, or other purposes.
  • a healthcare payer may have a desire to view the entirety of the patient's care described above from the initial visit at the New York Hospital through the laboratory results ordered from the Chicago
  • the payer may be able to identify the quality of care received by the patient, whether inappropriate or unnecessary laboratory exams or diagnostic tests were performed, and generally see an overall story of the patient's healthcare received from start to finish. It should be appreciated that this advantage may further be realized in associated business analytics as further described herein, such as, for example, in the method 260.
  • the method 240 includes receiving a communication request in step 242, creating a communication in step 244, receiving a communication retrieval request in step 246, verifying user access in step 248, transmitting the communication in step 250, and creating an actionable task in step 252.
  • the method 240 includes receiving a communication request in step 242.
  • a healthcare relationship management system is configured to present a user with a portal for secure and data-rich communication within the system.
  • the communication portal enables users of the healthcare relationship management system to send communications to other users or themselves with references to information stored within the system.
  • the healthcare relationship management system verifies whether the recipient is authorized to view data referenced in the communication and may apply masking techniques or otherwise not present the data to an unauthorized user.
  • the healthcare relationship management system receives a communication request.
  • a user identifies a problem area, desires to communicate some data to another user, or generally has a need to send a message referencing sensitive data within a system to another user.
  • the user may access the communication portal and select an indication to send such a communication to another user.
  • the portal may present the user with a graphical user interface for creating the message, such as, for example, the graphical user interface shown in FIG. 15.
  • the portal may prompt the user to input a recipient, the subject of the message, and references to any data within the system to be included in the message.
  • the healthcare relationship management system may be configured to present to the user an interface that provides a familiar user experience for sending communications, like an interface for sending email.
  • step 244 the user selects to send the request, which causes a communication to be created within the healthcare relationship management system.
  • the system is configured to create the communication for review by the associated recipient.
  • sending a communication to another user may utilize a communication transfer protocol to transmit the communication from one server to another server outside of the control of an organization, like sending an email.
  • the communication may be created by a user and then transferred offsite or over a computer network to a third party system via SMTP or other transfer protocol.
  • the communication when sent by a user, is created within a database controlled by the system and, therefore, confined to an area controlled by the healthcare relationship management system at all times. By controlling the communication in this manner, the healthcare relationship management system can ensure that any sensitive information associated with the communication does not egress from the system itself.
  • a business analyst for a hospital may desire to communicate a report of poorly performing data metrics with sensitive PHI to a superior.
  • the business analyst may generate the report in his or her business analytics solution, save the report in a PDF, and then email the report to a superior.
  • the business analyst may create a communication in step 242 identifying the intended recipient, reference the report generated by the healthcare relationship management system and then select to send the communication. Upon sending the
  • the healthcare relationship management system is configured to create a communication in step 244 through population of a record in a controlled database for the communication.
  • the report is not saved as a PDF to the user' s computer and then transferred over a computer network to an email server. Instead, the report is generated within a healthcare relationship management system, attached to a communication within the healthcare relationship management system, and the communication is created for review by the recipient - without any information ever leaving the control of the healthcare relationship management system.
  • implementations by enabling an organization to freely communicate sensitive information (i.e. PHI, confidential information, trade secrets, or the like) without the problems of data egress from the organization through uncontrolled mail servers, unencrypted email traffic, sensitive reports being stored on user computers, or otherwise.
  • sensitive information i.e. PHI, confidential information, trade secrets, or the like
  • the systems enable free communication of such sensitive data through the confines of a healthcare relationship management system that is configured to ensure data is only viewable by parties with authorization to review the data. This seamless integration of authorization provides efficiencies for communication that are currently unavailable in the art.
  • the method 240 includes receiving a communication retrieval request from the recipient in step 246.
  • a user receiving a communication within a healthcare relationship management system may desire to receive the communication and click or otherwise interact with the healthcare relationship management system to obtain the contents of the communication.
  • the healthcare relationship management system may generate a portal interface for the user to show all communications available for the user, such as, for example, the graphical user interfaces shown in FIG. 12, FIG. 13, and FIG. 14. In this view, the user may see all communications created for the user, the sender of each communication, the subject of each communication, the date of each
  • the graphical user interface may further be configured to enable the user to click on a communication to view its contents, delete a communication, reply to a
  • the user's authorization to view information contained within the communication is verified in step 248.
  • the communication may include data categorized as sensitive for which a requisite access level is required.
  • the user's role and node membership may be verified to determine whether the user has access to such data in step 248.
  • the user access controls based on role and node described in the methods 220 and 230 may be combined with generating and sending communications in the method 240 to enable the communication of information deemed sensitive or subject to privacy regulations within the healthcare relationship management system without needing to employ an additional layer of security.
  • the system may be configured to verify authorization at any point where a user attempts to access such sensitive data. For example, a user attempting to send a communication to another user may desire to include a reference to a table showing real-time data for the last ten purchased laboratory tests from a client.
  • the sending user may be associated with a role and node providing authorization to the data included in the report.
  • the receiving user may not be authorized to view such data and, upon attempting to view the report from the message within the healthcare relationship management system, the healthcare relationship management system may be configured to deny access to the receiving user and/or generate masked or malformed data to hide the unauthorized data.
  • the communication is transmitted to the user in step 250.
  • a healthcare relationship management system may be configured to display the communication to the user in step 250 through a graphical user interface, such as, for example, the graphical user interface shown in FIG. 15.
  • the communication may include the original message from the originating user and one or more references to stored data within the healthcare relationship management system.
  • a user creates a communication in step 244 with references to reports or other data stored within a healthcare relationship management system at a certain time.
  • a recipient opens the communication.
  • the healthcare relationship management system upon sending a request to view the referenced data within the communication, is configured to receive real-time or near real-time data for display to the user.
  • the user is given an accurate and real-time look into the data originally sent in the communication. It should be appreciated that by reviewing realtime data within the communication, the recipient may be in a better position to react to the data to create actionable tasks for remediation of an identified problem from the data or otherwise.
  • a user may identify within a healthcare relationship management system that an individual nurse is, on average, slow in responding to patient questions.
  • the user may create a communication for a recipient with a reference to a report showing the average response time of the nurse over the last five days.
  • the user may include a request for the recipient to follow up with the nurse "if this is still a problem.”
  • the recipient may view the communication at a time period after the communication is created for the recipient. At this time, when the recipient opens the communication and views the referenced report, the report may pull real-time data for the nurse which purports to show that the nurse has been much quicker in responding to patient requests.
  • communications may be generated by a healthcare relationship management system for an individual user.
  • a user may configure thresholds on attributes that are monitored in real-time by a healthcare relationship management system to generate alerts when such values go outside of the threshold.
  • the alerts may be generated and flow through the
  • the notification may be sent to a user via email, SMS, social media message, MMS, Twitter direct message, or otherwise for immediate notification.
  • the alert will not include sensitive information and may direct a recipient to login to the healthcare relationship management system to view such sensitive information associated with the alert.
  • a recipient of a communication may create a task for remediation of an identified problem area within the communication in step 252.
  • the task creates an actionable and accountable request for another user to review and/or remediate a problem identified within the task.
  • the task may include, but is not required to include, referenced data within a healthcare relationship management system supporting the problem area associated with the task.
  • the task may further include a description of the problem and a suggested timeline for resolution.
  • An example task is displayed in the graphical user interface displayed in FIG. 13. As shown in FIG. 13, a task was received for the user Seth on February 21, 2014 from Andy Weixler requesting that Seth "[n]eed to check to see if Dr. Baker was billed correctly."
  • the task may include a reference to data corresponding to Dr. Baker's last bill and, when opened by the user Seth, will pull the billing data directly from the healthcare relationship management system database.
  • the method 260 includes receiving a report request in step 262, retrieving active and warehoused health information in step 264, generating a health care insight report in step 266, filtering the health care insight report in step 268, receiving a request to drill down into the health care insight report in step 270, and generating an actionable data layer in step 272.
  • health care insight may refer to, but is not limited to, a calculated data metric which drives actionable tasks based on available information, including health care information.
  • the method 260 includes receiving a request for a report in step 262.
  • a healthcare relationship management system may present to a user a graphical user interface enabling a user to identify, customize, and generate health care insight reports based on information known and/or stored by the healthcare relationship management system.
  • the health care insight reports may be pre- configured reports that may be generated against real-time or near real-time data (i.e. top sales of the month, turn-around time for the month, average turn-around time, and others). It should be appreciated that any report generated within the method 260 may be saved or otherwise configured to be easily reproduced at a later time as a pre- configured health care insight report. It should be appreciated that the step 262, and other steps of the method 260, may be repeated as a user refines, filters, and otherwise manipulates a health care insight report.
  • the method 260 includes retrieving active and warehoused health information in step 264. It should be appreciated that at least one advantage presented in the present disclosure is to present health care insight reports with a combination of real-time and warehoused data. In step 264, a healthcare relationship
  • management system may be configured to pull data for a health care insight report from an archive of information in a data warehouse in combination with real-time or near real-time data flowing to the healthcare relationship management system from third party resources and/or generated by the healthcare relationship management system.
  • the method 260 includes generating a health care insight report.
  • the request from the user in step 262 is combined with the retrieved active and data warehoused information in step 264 to generate a health care insight report in a graphical user interface in step 266.
  • the health care insight report may be generated as a table, graph, or other filtered view into data housed within the healthcare relationship management system.
  • the health care insight report may be generated through one or more health care insight tools, such as, for example, Eclipse, Jaspersoft, Palo, ActiveReports, Informatica, Proclarity, SpagoBI, Microsoft Excel, or other health care insight tools.
  • the health care insight reports may be generated through proprietary means creating one or more views into the data retrieved in step 264. Using these tools or through proprietary means, a user may build a health care insight report. In such an embodiment, a user may select any data fields known to a healthcare relationship management system to include in the report, a date window, one or more filters, and other information to generate the report.
  • FIG. 6 An example health care insight report is shown in FIG. 6.
  • the health care insight report is presented as a graphical user interface within a healthcare relationship management system.
  • the report is a graphical representation of information stored within the healthcare relationship management system.
  • the report is generated to display Turn- Around Time in hours over a period of days.
  • the health care insight report may be altered to show this data by the week, month, quarter, year, or other custom time window.
  • the report may be further filtered to include additional information known to the healthcare relationship management system (i.e. priority, panel type, panel name, etc.) to enable a user of the report to quickly and efficiently identify relevant data.
  • FIG. 8 An example health care insight report is shown in FIG. 8. As shown in FIG. 8, the health care insight report provides an aggregate view of opportunities in a sales stage pipeline over a 12 month window.
  • a user may have requested the health care insight report from a preconfigured list of health care insight reports to be generated against data warehoused information and real-time information within a healthcare relationship management system or the user may have built the health care insight report from a set of fields to include, date window, and other options.
  • lab testing volume may be monitored over a period of time and stored in a data warehouse.
  • the data warehouse in this example, may store previously obtained lab testing volume for individual days over the last year.
  • real-time or near real-time lab testing volume may be monitored on a daily basis in another database.
  • a health care insight report may be generated by the healthcare relationship management system to compare real-time or near real-time lab testing volume over the current day against previously monitored and stored lab testing volume in the data warehouse, In this example, then, the current lab testing volume may be compared against lab testing volume from last year.
  • the method 260 includes filtering a health care insight report in step 268.
  • a user may select aggregated information presented in a health care insight report to filter and/or alter the health care insight report to present different data.
  • a healthcare relationship management system presenting the health care insight report may include a graphical user interface enabling the user to select one or more data record types, attributes, date ranges, or other options in a drop-down list box, radio buttons, multi-selectable box, or other web component to enable the user to filter the health care insight report.
  • the healthcare relationship management system may regenerate the health care insight report with the filtering options. It should be appreciated that regenerating the health care insight report may be performed by repeating steps 262, 264 and 266 with the filtering options referenced in the receive report request step 262.
  • the user access controls discussed herein are applied to data presented in the health care insight report.
  • a user that is a member of one or more roles and assigned to one or more nodes may be authorized to view types of data based on role membership and records of data based on node assignment.
  • the data presented may be evaluated against the user's role membership and node assignment to determine whether to display the data requested, mask the data requested, or deny access to the data requested.
  • the method 260 includes receiving a request to drill down into a report in step 270.
  • a graphical user interface displaying a health care insight report is configured to enable a user to click on any information presented in the report to find more information related to what is presented. For example, if an aggregate data element is presented (i.e. total turnaround time for orders in a month), the user may drill down into this information to see each individual data element used to make up the aggregate number (i.e. each order and its associated information).
  • drilling down into a health care insight may be treated as generating a new health care insight report, such that the steps 262, 264, and 266 may be generated to produce the drilled down report. It should be appreciated, then, that a user may drill down into a health care insight report down to the individual data elements stored within the healthcare relationship management system. It should further be appreciated that this structure enables a user to go from an aggregate set of data to individual data records efficiently.
  • FIG. 8 and FIG. 9 present an example health care insight report generated through execution of the method 260.
  • a user may be presented with an option to drill down into individual data elements to obtain more information, such as, for example, the individual data element views presented in FIG. 10.
  • a user may click on any individual date window or aggregate representation of information within the reports.
  • a user may generate a health care insight report for the total turnaround time of laboratory tests ordered within a calendar year, broken down individually by month.
  • the user may select any individual month to drill down the health care insight report to display total turnaround time for laboratory tests within a month broken down by week.
  • the user may further drill down into the weekly health care insight report by identifying an individual week to generate a health care insight report that displays total turnaround time for individual laboratory tests broken down by day in the aggregate.
  • the user may further drill down into an individual day to generate a health care insight report that generates the individual data elements used in the aggregate representation by day, It should be appreciated, of course, that this is merely one example and that other options to drill down information by time, order, region, or other variable are available. For example, as discussed above, the health care insight report by day may be further drilled down to generate total turnaround time for laboratory tests ordered by hour, etc.
  • the method 260 includes generating an actionable data layer in step 272.
  • a healthcare relationship management system may be configured to enable a user to drill down into individual data elements and present options to the user to create tasks directly on any individual data elements or aggregated data elements.
  • the user may indicate a desire to create a task from any individual data element or a grouping of data elements for actionable and accountable remediation.
  • the user may assign a due date to the task, set a status, create a subject and description, assign the task to an individual user, set a priority and category, and carbon copy other users of the healthcare relationship management system for the task.
  • FIG. 7 An example health care insight report with an actionable task being created is shown in FIG. 7.
  • the health care insight report is directed to laboratory test turnaround time exceptions.
  • the turnaround time exceptions are related to a preconfigured threshold of turnaround time as an exception.
  • a turnaround time of 125.72, 1,027.17, 261.05 and 1,533.42 hours are each over the preconfigured threshold.
  • the individual data elements each include an order number, an ordered data, a result date, a calculated turnaround time, an option to drill into further details concerning the data element, and an opportunity to create a task for each data element.
  • the create task option has been selected to provide the popup shown.
  • the popup includes order 43131995-201308160608 as a related item, which corresponds to the first entry in the health care insight report.
  • the user has indicated a desire to create a new task from the first order presented in the turnaround time exceptions report.
  • the user has entered a subject of "Follow up with Courier”, set a same-day due date for the task, assigned the task to an individual user in the system - Goff, Carson and carbon copied a manager for the task - Brad Bostic.
  • the task will be placed into the queue of tasks for Goff, Carson for remediation.
  • Goff Carson views the task, as discussed previously, Goff, Carson will have immediate access to the related item tied to the task to find more information and, presumably, which courier to contact to determine what happened in this instance.
  • each layer of a health care insight report may be further drilled into in order to obtain more detailed information.
  • FIG. 6 displays a Flexible Metrics, Turnaround Time health care insight report, which provides aggregated information concerning the total turnaround time for a few days in August 2013.
  • the user may be presented with individual records, which comprise the aggregated information, such as, for example, in a graphical user interface similar to one shown in FIG. 7.
  • the user may then further drill into an individual data element to identify more information concerning a specific order number.
  • giving a user a direct opportunity to drill down into individual data elements from an aggregate health care insight provides an efficient way to view healthcare relationship information to improve management, find problems, determine solutions to said problems, and assign such solutions to individual resources.
  • the healthcare relationship management system may be configured to display entity specific names for variables, attributes, data types, and other information within the system.
  • an entity may desire to name specific data attributes, health care insight report types, and other items in specific manners outside of the standard naming conventions deployed.
  • the healthcare relationship management system may be configured to use an individualized set of naming conventions for a specific entity.
  • the healthcare relationship management system may enable such individual naming conventions by assigning variables at the presentation or application layer for each data element, attribute type, or other information set for which nonstandard naming conventions are to be used. Then, the healthcare relationship management system may query a database or document where the individualized naming conventions are stored to fill the variables appropriately for the specific entity. It should be appreciated that individual naming conventions may be configured to only display such unique naming conventions for users affiliated with an organization where such naming conventions are deployed. For example, if health organization A and health organization B each collectively use a healthcare relationship management system and healthcare organization A utilizes
  • a standard healthcare relationship management naming convention for the time it takes to fill a prescription may be "fill time.”
  • a healthcare organization that fills prescriptions may have an individualized naming convention where the standard "fill time” is named “close time.”
  • a healthcare relationship management system may use a user interface definition layer for the presentation of "fill time” within an individual organization, which queries a database or document to retrieve the appropriate naming convention for the entity during presentation.
  • users logging in and associated with the entity will display "close time” rather than "fill time” through the healthcare relationship management system.
  • users not affiliated with the entity would still retrieve the standard "fill time” moniker.
  • the method 280 includes receiving health information in step 281, analyzing health information with a diagnostic and wellness rules engine in step 282, generating wellness and/or diagnostic alerts in step 283, displaying alerts to a practitioner in step 284, escalate a treatment path in step 285, and incentivizing healthy behavior in step 286.
  • the method 280 includes receiving health information in step 281.
  • receiving health information in step 281 may be accomplished through the manner described in step 225 of the method 220.
  • health information may be further obtained from various sources, such as, for example wearable technology (i.e. Fitbit, smart watches, etc.), Internet- enabled health measurement tools (scales, heart monitors, step monitors, wireless glucose meters, etc.), any exercise-based smartphone application, and other devices.
  • wearable technology i.e. Fitbit, smart watches, etc.
  • Internet- enabled health measurement tools scales, heart monitors, step monitors, wireless glucose meters, etc.
  • any exercise-based smartphone application and other devices.
  • Health information from each of these devices may be obtained by integrating and pushing information into a healthcare relationship management system through an application programming interface, sockets, and/or web services infrastructure or pulled by the healthcare relationship management system through an application programming interface, sockets, and/or web services architecture enabled from the provider (i.e. Fitbit API).
  • a Fitbit application for the healthcare relationship management system may be downloaded and installed onto a patient's Fitbit that periodically uploads health information from the Fitbit to the healthcare relationship
  • the healthcare relationship managements system may have a partnership with a health information provider, like Withings with pulse monitors, blood pressure monitors, scales, and other Internet- capable health measurement technologies. It should further be appreciated that the healthcare relationship management system may obtain additional information through other sources, such as, for example, social media and marketing applications.
  • the method 280 includes analyzing health information with a diagnostic and wellness rules engine in step 282.
  • health information obtained in step 281 may be analyzed by a diagnostic and wellness rules engine to make healthcare recommendations for patients associated with the health information.
  • the health information may be processed and analyzed by the rules engine through a queue infrastructure. As health information is input to the healthcare relationship management system, it is placed on a queue and processed by the rules engine through queue management methods known in the art (i.e. FIFO, etc.). In other embodiments, the health information is analyzed periodically.
  • the diagnostic and wellness rules engine may analyze the health information against a set of rules. Each rule may be associated with one or more diagnostically relevant conclusion or wellness-based assertion based on the incoming health information.
  • the rules may be preconfigured within the healthcare relationship management system and/or configured by practitioners, patients, payers, or other users of the healthcare relationship management system. Rules may also be generated manually by users (i.e. providers) based on patient requests for care.
  • the rules engine may generate derived attributes from the health information. For example, in the event that incoming health information includes a user's weight from an Internet-enabled scale, a user's height from the Fitocracy smartphone application, and the user's sex from another source, the rules engine may generate a derived attribute associated with the user's body mass index.
  • a user may integrate a Fitbit device, an Internet-based scale, and a wireless glucose meter to the healthcare relationship management system and start uploading health information from these devices.
  • the user's weight, number of steps, sleeping activity, and glucose levels are input to the healthcare relationship management system.
  • the rules engine may ascertain the user is behaving poorly through the user's increase in weight as measured by the scale, less steps taken as measured by the Fitbit, and increased glucose levels from the wireless glucose meter.
  • the rules engine may have a rule to trigger an alert that the patient is behaving in an unhealthy manner.
  • a patient may arrive at the doctor's office with a complaint of pain in his or her foot as a result of a sports injury.
  • the doctor may recommend that the patient rest his foot and limit physical activity (including running and walking) as much as possible while the bruise heals.
  • the doctor could generate a rule within the rules engine to trigger an activity in the event that the patient uploads a run to the healthcare relationship management system through the Nike+ application or generates more than 500 steps in a day as measured by his or her Fitbit.
  • the diagnostic alert generated may be an indication that the patient is putting too much stress on his or her foot.
  • the rule was manually created by the doctor based on perceived patient symptoms during a visit.
  • the method 280 includes displaying alerts to a practitioner in step 284.
  • the alerts generated in step 283 may be transmitted to a practitioner for actions to be taken.
  • a practitioner may receive alerts transmitted from the healthcare relationship management system through a variety of ways, such as, for example, logging into the healthcare relationship management system and receiving a communication (i.e., the method 240), receiving an email, text message, page, push notifications, or other communication, or by receiving a phone call from an operating service or automated operating service.
  • a doctor in a follow-up appointment with a patient may use a smartphone, tablet, or other device to login to the healthcare relationship management system during the visit.
  • the provider may see one or more
  • the doctor may see an alert generated indicating that the patient has been less physically active. The doctor may then immediately use information gleaned from this alert in further diagnosing the patient in the visit. It should be appreciated, of course, that the doctor in this example may view the patient's health information in other ways as described herein, such as, for example, through an analytics report generated from the method 260, generally viewing healthcare information from the method 220, or in other ways.
  • the method 280 includes escalating a treatment path for a patient in step 285.
  • an alert may activate follow-up activities for the user, like triggering a doctor visit, offering a wellness video for more information on how to be healthy, initiating a marketing campaign associated with wellness, or other activities.
  • the method 280 includes incentivizing healthy behavior in step 286.
  • alerts generated in step 283 may generate gamified activities for a user that incentivize increased wellness activities that are presented to the patient via email, communication in the healthcare relationship management system, SMS, push messaging, integration with one or more smartphone applications (i.e.
  • an alert triggered indicating that a patient is not walking enough based on Fitbit information may generate an incentive message for the patient that he or she would earn a 10% coupon at a retail store in the event that the patient walks a threshold number of steps in the next twenty-four hours.
  • a rule generating an alert indicating that a patient has not uploaded a wellness activity in five days i.e. Nike+ run, Fitbit steps
  • the incentivized behavior may be related to a corporate wellness campaign for points towards a company contribution to a Health Savings Account.
  • FIG. 2F there is shown a flowchart of a method for healthcare relationship management according to at least one embodiment of the present disclosure.
  • the method includes receiving health information in step 291, analyzing health and business information with campaign rules engine in step 292, and generating a campaign event in step 293.
  • FIG. 2F displays an exemplary method 290 where the previously discussed diagnostic and wellness rules engine may be used as a campaign rules engine with health and/or business information.
  • business information may include, but is not limited to, information obtained from business intelligence reports, user interactions with the healthcare relationship management system, organization information, communications, tasks, and the like.
  • business information as used herein, may include examples like a sales user entering a new business relationship with a customer, the creation of a new provider, patient, or contact account, an incoming task, an incoming communication (i.e. email, SMS, MMS, etc.), an outgoing communication, and others.
  • the campaign rules engine may be populated with a variety of rules and business workflows. Examples will be described herein, but it should be appreciated that any business process workflow may be utilized.
  • a healthcare relationship management system receives or generates health and/or business information.
  • the health and/or business information may be received similarly to the previously discussed steps for retrieval and/or generation steps disclosed herein, such as, for example, step 225 of method 220, step 242 of method 240, step 262 of method 260, step 281 of method 280, and others.
  • the health and/or business information is analyzed against a set of rules established in a campaign rules engine. In the event that one or more rules are matched in the campaign rules engine related to the health and/or business information, the healthcare relationship management system generates a campaign event in step 293.
  • the process described herein for step 290 may follow the similar process for analysis and execution of business workflows as discussed previously herein, such as, for example, the process defined for establishing and evaluating rules in the diagnostic and wellness rules engine.
  • a sales employee enters a business information into the healthcare relationship management system related to a new toxicology lab signing up for service.
  • business information associated with the new toxicology lab include a contact name, email address, phone number, start date, and monthly commitment for service (i.e. 100 tests per month).
  • the campaign rules engine is prepopulated with a rule to send newly created labs on the system a "HOWTO" message describing features of the healthcare relationship management system.
  • the system upon the manual entry of the new toxicology lab in the healthcare relationship management system, the system automatically generates and sends the communication to the contact email address entered manually.
  • a rule may exist to automatically assign initial setup tasks to the organization that are common to the healthcare relationship management (i.e. change your password, define an administrator contact, etc.).
  • an incoming email and/or communication to the healthcare relationship management system may comprise business information as used in the method 290.
  • the email may contain content that, when processed by the campaign rule engine, creates tasks or events based on the content.
  • an incoming email and/or communication to the healthcare relationship management system may comprise business information as used in the method 290.
  • the email may contain content that, when processed by the campaign rule engine, creates tasks or events based on the content.
  • an incoming email and/or communication to the healthcare relationship management system may comprise business information as used in the method 290.
  • the email may contain content that, when processed by the campaign rule engine, creates tasks or events based on the content.
  • an incoming email and/or communication to the healthcare relationship management system may comprise business information as used in the method 290.
  • the email may contain content that, when processed by the campaign rule engine, creates tasks or events based on the content.
  • an incoming email and/or communication to the healthcare relationship management system may comprise business information as used in the method 290.
  • the email
  • communication sent to a mailbox specifically created for an organization within the healthcare relationship management system may be processed by the campaign rules engine with a pre- created rule to assign any incoming communications as tasked within the healthcare relationship management to the organization in which they are related.
  • a task is created for the organization for manual processing.
  • the method 294 includes receiving user task event in step 295, analyzing task event with campaign rules engine in step 296, and generating a campaign event in step 297. It should be appreciated that the method 294 in FIG. 2G displays usage of the campaign rules engine in another context, to analyze and automatically execute a business workflow based on user activity within the healthcare relationship management system.
  • System 300 comprises user device 310, server 320, database 330, and computer network 360.
  • user device 310 For purposes of clarity, only one user device 310 is shown in FIG. 3A. However, it is within the scope of the present disclosure that the system 300 may include any number of user devices 310 at one time.
  • the user device 310 may be configured to transmit information to and generally interact with a web services and/or application programming interface infrastructure housed on server 320 over computer network 360.
  • the user device 310 may include a web browser; mobile application, socket or tunnel, or other network connected software such that communication with the web services infrastructure on server 320 is possible over the computer network 360.
  • User device 310 includes one or more computers, smartphones, tablets, wearable technology, computing devices, or systems of a type well known in the art, such as a mainframe computer, workstation, personal computer, laptop computer, hand-held computer, cellular telephone, or personal digital assistant.
  • User device 310 comprises such software, hardware, and componentry as would occur to one of skill in the art, such as, for example, one or more microprocessors, memory systems, input/output devices, device controllers, and the like.
  • User device 310 also comprises one or more data entry means (not shown in FIG.
  • User device 310 operable by users of user device 310 for data entry, such as, for example, voice or audio control, a pointing device (such as a mouse), keyboard, touchscreen, microphone, voice recognition, and/or other data entry means known in the art.
  • User device 310 also comprises a display means (not shown in FIG. 3A) which may comprise various types of known displays such as liquid crystal diode displays, light emitting diode display, and the like upon which information may be display in a manner perceptible to the user.
  • the server 320 may be configured to receive authentication information, page rendering requests, tasks, communications, and other information from the user device 310.
  • the server 320 accesses the database 330 to store information transmitted from the user device 310 or generated through its interaction with the server 320 in the methods and disclosed herein.
  • the server 320 is configured to carry out one or more of the steps of methods described herein.
  • the user device 310 is further configured to provide input to the server 320 to carry out one or more of the steps of the methods described herein.
  • Server 320 comprises one or more server computers, computing devices, or systems of a type known in the art.
  • Server 320 further comprises such software, hardware, and componentry as would occur to one of skill in the art, such as, for example, microprocessors, memory systems, input/output devices, device controllers, display systems, and the like.
  • Server 320 may comprise one of many well-known servers and/or platforms, such as, for example, IBM's AS/400 Server, RedHat Linux, IBM's AIX UNIX Server, MICROSOFT'S WINDOWS NT Server, AWS Cloud services, Rackspace cloud services, any infrastructure as a service provider, or any platform as a service provider.
  • server 320 is shown and referred to herein as a single server.
  • server 320 may comprise a plurality of servers, virtual infrastructure, or other computing devices or systems interconnected by hardware and software systems know in the art which collectively are operable to perform the functions allocated to server 320 in accordance with the present disclosure.
  • the database 330 is configured to store healthcare information, patient information, reports, health care insight, and other information generated by the healthcare relationship management system and/or retrieved from one or more information sources.
  • Database 330 is “associated with” server 320. According to the present disclosure, database 330 can be “associated with” server 320 where, as shown in the embodiment in FIG. 3A, database 330 resides on server 320. Database 330 can also be “associated with” server 320 where database 330 resides on a server or computing device remote from server 320, provided that the remote server or computing device is capable of bi-directional data transfer with server 320, such as, for example, in Amazon AWS, Rackspace, or other virtual infrastructure, or any business network. In at least one embodiment, the remote server or computing device upon which database 330 resides is electronically connected to server 320 such that the remote server or computing device is capable of continuous bi-directional data transfer with server 320.
  • database 330 is shown in FIG. 3A, and referred to herein as a single database. It will be appreciated by those of ordinary skill in the art that database 330 may comprise a plurality of databases connected by software systems of a type well known in the art, which collectively are operable to perform the functions delegated to database 330 according to the present disclosure.
  • Database 330 may comprise relational database architecture, noSQL, OLAP, or other database architecture of a type known in the database art.
  • Database 330 may comprise one of many well-known database management systems, such as, for example, MICROSOFT'S SQL Server, MICROSOFT'S ACCESS, MongoDB, Redis. Hadoop, or IBM's DB2 database management systems, or the database management systems available from ORACLE or SYBASE.
  • Database 330 retrievably stores information that is communicated to database 330 from user device 310 or server 320.
  • User device 310 and server 320 communicate via computer network 360. If database 330 is in disparate infrastructure from server 320, database 330 may communicate with server 330 via computer network 360.
  • Computer network 360 may comprise the Internet, but this is not required.
  • the system includes third party resources 382, a data integration layer 384, a web services and/or application programming interface layer 386, and a database 388.
  • the system 382 includes one or more third party resources.
  • Third party resources may transmit data in one or more formats to the data integration layer 384 for ingestion.
  • Third party resources may include, but are not limited to, laboratory information systems, laboratory management systems, third party databases, business process management resources, or other data repositories.
  • the third party data resources may transmit healthcare data to the data integration layer 384 in any format, including, but not limited to, HL7, XML, JSON, SQL transport, Sockets, comma separated values, text, or otherwise.
  • the data integration layer 384 may comprise one or more servers configured to translate data provided from the third party resources 382 for ingestion into a healthcare relationship management system.
  • Data provided by the third party resources 382 may come in a variety of formats, some of which may be proprietary, which need transformed or otherwise altered for ingestion into a healthcare relationship management system.
  • the data integration layer 384 creates objects corresponding to the translated data using one or more web services protocols (SOAP, RESTful, etc.) or application programming interface calls to the web services layer 386, which then imports data into the database 388.
  • SOAP web services protocols
  • RESTful RESTful
  • the integration to the database 388 may be split into disparate paths for standard ingestion of content commonly used within the healthcare relationship management system and custom data specific to a healthcare organization, but this is not required.
  • FIG. 3C it is shown a logical architecture diagram of components of a healthcare relationship management system 390 with multi-tenant support and wellness automation.
  • the healthcare relationship management system 390 includes multiple portals (391a, 391b), health care insight admin services (392a, 392b), user access control layers (393a, 393b), organization layers (394a, 394b), a provider role 396, a coach role 397, a patient role 398, and an underlying single-sign on layer 399.
  • FIG. 3C only displays two tenants in a healthcare relationship management system 390 but any number of tenants may be supported.
  • the healthcare relationship management system 390 supports multiple tenant organizations 394a, 394b in the same infrastructure.
  • each tenant organization 394a, 394b may utilize a portal 391a, 391b and healthcare insight infrastructure 392a, 392b within the same system 390.
  • each organization is equipped with individualized authorization controls in a user access control layer (i.e. 393a, 393b) within the system 390 such that users only authorized to view data, generate reports, and otherwise access services for one organization cannot access resources for other organizations.
  • a user with organization 394a that is only authorized to access the healthcare insight layer 392a for such organization 394a cannot access the healthcare insight layer 392b for organization 394b.
  • Each organization may control which users known to the healthcare relationship management system 390 may access information and services for the organization, which is enforced at the user access control layer. It should be appreciated that an individual user within the healthcare relationship management system 390 may be authorized to view information and access services for multiple organizations.
  • Authentication for users and, as discussed previously, for input sources in the healthcare relationship management system 390 is performed by a single sign on service 399.
  • the single-sign on service 399 provides authentication for users and input sources that may be leveraged by user access control layers at each individual organization (i.e. 393a, 393b).
  • a user authenticates to a healthcare relationship management system by providing credentials at a login page. The credentials are authenticated at the single-sign on service 399 and then the user is directed to the page requested.
  • one or more user access control layers is used to verify the user's authorization based on information and resources requested. For example, if the user is attempting to access data associated with organization 394a, the single-sign on service 399 authenticates the user and then the user access control layer 393a is used to authorize the user's access to such data.
  • a user may request access to a page that would display information from multiple organizations.
  • the single-sign-on service 399 provides authentication for the user and access control layers are utilized to verify authorization as needed for information.
  • the single-sign on service 399 includes the support for multiple roles within the healthcare relationship management system 390.
  • a few examples of such roles are shown logically in FIG. 3C, including a provider 396, a coach 397, and a patient 398.
  • the single-sign-on service 399 may associate a user and user credentials with these roles that may then be leveraged by individual organization user access control layers.
  • the user access control layer may reference roles rather than individual users, which may create more efficient provisioning of users within the healthcare relationship management system 390. It should be appreciated that additional roles may exist within the healthcare relationship management system 390, including, for example, a device role.
  • the healthcare relationship management system 3000 includes partners 3001a, 3001b, 3001c, patients 3002, providers 3003, interfaces 3004, electronic health record systems 3005, a wellness engine 3006, various user defined interfaces 3007, healthcare relationship management 3008, an insight engine 3009, and multiple tenants 3010a, 3010b, and 3010c.
  • each tenant includes users 3011, healthcare information systems 3012, connectors 3013, and organizations 3014.
  • FIG. 3E it is shown components of a multi-tenant system for healthcare relationship management 3500 according to at least one embodiment of the present disclosure.
  • the embodiment shown in FIG. 3E expands upon the embodiment shown in FIG. 3A through the addition of one or more input sources 3560.
  • the one or more input sources 3560 may include devices, infrastructure, and other sources that may provide health information, the system 3500, including, but not limited to, application programming interfaces, user devices (i.e. Fitbit, wireless glucose monitors, network-capable scales, etc.), healthcare information systems, and other sources. These input sources may communicate with other components of the system 3500 through computer network 360.
  • FIG. 4 displays a flowchart 400 of how information may flow to and through a healthcare relationship management system, such as, for example, the system 300 in FIG. 3A and the system 380 in FIG. 3B.
  • raw data may be supplied through manual entry or ingested via an external source (i.e. LIS, EMR system, etc.).
  • the raw data may flow through a common core infrastructure or a custom infrastructure based on the data type.
  • This data may then be analyzed to generate health care insight relationships.
  • the information may be segmented, filtered, aggregated, or otherwise manipulated to generate health care insight reports, organized in health care insight tabs, and presented in an actionable format in a health care insight dashboard.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Bioethics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Pathology (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Databases & Information Systems (AREA)
  • Game Theory and Decision Science (AREA)
  • Data Mining & Analysis (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un procédé et un système informatisés pour la gestion de relation de soins de santé. Le procédé comprend la réception d'une métrique de soins de santé depuis un dispositif utilisateur, la métrique de soins de santé étant associée à un utilisateur, l'association de la métrique de soins de santé à une pluralité d'autres métriques de soins de santé dans une base de données, l'obtention, sur la base de la métrique de soins de santé et au moins une parmi les autres métriques de soins de santé, d'un état de santé, et la transmission de l'état de santé vers un second dispositif utilisateur.
PCT/US2015/038438 2014-06-30 2015-06-30 Systeme et procede pour l'automatisation de la gestion de relation de soins de sante et de bien-être multi-locataire WO2016003974A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201462019181P 2014-06-30 2014-06-30
US62/019,181 2014-06-30

Publications (1)

Publication Number Publication Date
WO2016003974A1 true WO2016003974A1 (fr) 2016-01-07

Family

ID=55019893

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/038438 WO2016003974A1 (fr) 2014-06-30 2015-06-30 Systeme et procede pour l'automatisation de la gestion de relation de soins de sante et de bien-être multi-locataire

Country Status (1)

Country Link
WO (1) WO2016003974A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040059599A1 (en) * 2002-09-25 2004-03-25 Mcivor Michael E. Patient management system
US20110313791A1 (en) * 2010-06-18 2011-12-22 Mytelehealthsolutions, Llc System and Method for a Health Campaign Manager
US8560336B2 (en) * 2007-09-18 2013-10-15 Humana Innovations Enterprises, Inc. System and method for increasing compliance with a health plan
US20140019468A1 (en) * 2012-07-16 2014-01-16 Georgetown University System and method of applying state of being to health care delivery
US20140052474A1 (en) * 2012-08-16 2014-02-20 Ginger.oi, Inc Method for modeling behavior and health changes

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040059599A1 (en) * 2002-09-25 2004-03-25 Mcivor Michael E. Patient management system
US8560336B2 (en) * 2007-09-18 2013-10-15 Humana Innovations Enterprises, Inc. System and method for increasing compliance with a health plan
US20110313791A1 (en) * 2010-06-18 2011-12-22 Mytelehealthsolutions, Llc System and Method for a Health Campaign Manager
US20140019468A1 (en) * 2012-07-16 2014-01-16 Georgetown University System and method of applying state of being to health care delivery
US20140052474A1 (en) * 2012-08-16 2014-02-20 Ginger.oi, Inc Method for modeling behavior and health changes

Similar Documents

Publication Publication Date Title
US11954470B2 (en) On-demand decentralized collection of clinical data from digital devices of remote patients
US10169607B1 (en) Individual centric personal data management process and method
JP2022510245A (ja) 集中型及び分散型の個別化医薬プラットフォーム
US20160292456A1 (en) Systems and methods for generating longitudinal data profiles from multiple data sources
US20160034647A1 (en) System for integrated business management
Shin et al. Constructing RBAC Based Security Model in u‐Healthcare Service Platform
US10476821B2 (en) System and method for secure messaging
US8935753B1 (en) Network based healthcare management system
US20090012816A1 (en) Systems and methods for clinical analysis integration services
US20140344397A1 (en) System And Method For Propagating And Assessing Programs Across A Health Network
CN113508439A (zh) 提供个性化医疗保健信息和治疗建议
US20160350482A1 (en) Agent for healthcare data application delivery
Atanasovski et al. On defining a model driven architecture for an enterprise e-health system
US11145391B1 (en) Longitudinal condition tracking system and method
US20160026377A1 (en) System and method for collecting, curating, aggregating, and displaying metrics data from and to stakeholders in the charitable sector
US10642445B2 (en) Methods and apparatus for processing medical data from a plurality of users
Steimle et al. Extended provisioning, security and analysis techniques for the ECHO health data management system
US20170061152A1 (en) System and method for multi-tenant healthcare relationship management
US11599962B2 (en) Methods and apparatus for processing medical data from a plurality of users
US20180052960A1 (en) Computer-implemented methods of promoting patient compliance with one or more recommended treatments or screening regimens
WO2016003974A1 (fr) Systeme et procede pour l'automatisation de la gestion de relation de soins de sante et de bien-être multi-locataire
Olaniyi et al. Securing Digitized Campus Clinical Health Care Delivery System.
Stevovic et al. Business process management enabled compliance-aware medical record sharing
Escarfullet et al. An object–oriented mobile health system with usability features
US11551794B1 (en) Systems and methods for analyzing longitudinal health information and generating a dynamically structured electronic file

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15815673

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15815673

Country of ref document: EP

Kind code of ref document: A1