TW201514909A - System and method for sharing data in a clinical network environment - Google Patents

Abstract

A method for sharing data in a clinical network environment is provided in one example embodiment and includes associating a participant with a community in a clinical network environment comprising patients, medical providers, and payors, determining participant access privileges to data in a database, and providing access to the data according to a predetermined mode of sharing associated with the data. The data includes medical data, financial data and operations data associated with patients, medical providers and payors. The predetermined mode of sharing can include pessimistic mode, optimistic mode, or opportunistic mode. According to the optimistic mode, all data in the database is accessible to all participants in the community. According to the pessimistic mode, selected data in the database is accessible to all participants in the community. According to the opportunistic mode, selected customized data in the database is accessible to specific participants in the community.

Description

System and method for sharing data in clinical network environment Cross-references to related applications

This application is a continuation of the US Patent Application No. 12/536,060, entitled "Operating System", filed on August 5, 2009, in the United States, and claims its priority in the United States. The priority of U.S. Provisional Application No. 61/086,344, filed on August 5, 2008, is hereby incorporated by reference. This application is also a continuation of the U.S. Patent Application Serial No. 12/816,804, entitled "Operating System", filed on June 16, 2010, in the U.S. Patent. Case No. 12/816,804 is a partial continuation application of US Patent Application No. 12/536,060 filed on August 5, 2009, entitled "Operation System", which itself claims 2008 8 Priority of US Provisional Application No. 61/086, 344, entitled "Operating System", filed on the 5th of the month. The disclosure of the prior applications is hereby incorporated by reference in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety

This disclosure relates generally to the field of health care systems, and more particularly to systems and methods for sharing information in a clinical network environment.

Paper medical records have existed for centuries and their modern health photos In the protection system, it was gradually replaced by computer-based records. Hospitals are increasingly using electronic medical records (EMR), electronic health records (EHR), electronic patient records (EPR), and computer-based patient records (CPR) to electronically access and manage patients' medical care. And health information. As of 2002, there were five different types of personal health records: (i) offline personal health records; (ii) web-based business personal health records; and (iii) web-based functional personal health records; ) based on the provider's personal health record; and (v) some personal health records based on the Internet. All other types of personal health records are established by the patient or by a third party that does not include the health care provider, except for the provider's personal health record. The type and form of health records have grown exponentially since 2002, and there are numerous electronic and medical records of different health and medical records from a wide variety of medical systems and other sources.

A method of sharing data in a clinical network environment is presented in an exemplary embodiment and includes: causing a participant to interact with a community within a clinical network environment including patients, medical providers, and payers Correlation, determining participant access to data in a database, and providing access to data based on a predetermined sharing pattern associated with the material. The term "clinical network environment" is used throughout this document to cover the network environment that is configured to process medical data in accordance with statutory and other privacy requirements, such as the Health Insurance Portability and Accountability Act (HIPAA). ). The term "community" as used herein refers to the realization of a group of two or more entities (eg, individuals, organizations such as companies, governments, etc.) that can be used, for example, to improve clinical decision making, research, and risk stratification. And share information and share it.

This information includes medical information, financial information, and operational data associated with patients, medical providers, and payers. The predetermined sharing mode may include a pessimistic mode, Optimistic mode or opportunity mode. According to this optimistic model, virtually all material in the database is available to virtually all participants in the community. According to this pessimistic pattern, selected material in the database is available to virtually all participants in the community. According to the opportunity mode, the selected customized materials in the database are available to specific participants in the community.

In a particular embodiment, a plurality of communities have access to different portions of the material. In some embodiments, participants may belong to more than one community. In some cases, participants may be part of an entity that participates in one or more of the communities. The participant includes at least one client whose access to the material is set by the participant according to the role of the client. The access rights of this participant are set by the community. In some embodiments, the participant's access rights are determined based on community authentication settings and participant credentials associated with the community and the participants, respectively.

10‧‧‧Health Care Monitoring System

11‧‧‧ Clinical Network/Network

116‧‧‧Network

12‧‧‧ Patients

14‧‧ Medical providers

16‧‧‧Payers

18, 102‧‧‧Information

20‧‧‧Server

22‧‧‧ Cloud

24‧‧‧ Medical Information

26‧‧‧Working materials

28‧‧‧Financial information

30‧‧‧Data Sharing Module

31‧‧‧Clinical operating system

32, 104~108‧‧‧Community

34‧‧‧Participants

36, 58‧‧‧ Client

40‧‧‧ Patient database module

41‧‧‧Database

42‧‧‧ Patient List Module

44‧‧‧Provider List Module

46‧‧‧Main patient index module

48‧‧‧Participant List Module

50‧‧‧Community Creation Module

52‧‧‧Participant Permissions Module

54‧‧‧ rule creation module

55‧‧‧Shared Mode Module

56‧‧‧Security Module

60‧‧‧ Login Module

62‧‧‧Certificate Module

64‧‧‧Check module

66‧‧‧Information Request Module

68‧‧‧ visual display

70‧‧‧ processor

72‧‧‧ memory components

74~79, 82~96, 110~114, 120~126‧‧‧

80‧‧‧ entity

100‧‧‧Form

130‧‧‧Community entrance

132‧‧‧Participant entrance

134‧‧‧Client portal

136‧‧‧Information portal

138~146‧‧‧Details

150~162, 172~182, 192~208‧‧‧ steps

170, 190‧‧‧ operations

The same reference numerals are used to refer to the same parts in the drawings, in which: FIG. 1 is a simplified block diagram, according to an example, in order to provide a more complete understanding of the disclosure. Embodiments exemplify a health care monitoring system for sharing data in a clinical network environment; FIG. 2 is a simplified diagram illustrating exemplary details of one embodiment of the health care monitoring system; FIG. 3 is a simplified diagram illustrating Another exemplary detail of one embodiment of the health care monitoring system; FIG. 4 is a simplified diagram illustrating another example detail of one embodiment of the health care monitoring system; Figure 5 is a simplified diagram illustrating another exemplary detail of one embodiment of the health care monitoring system; Figure 6 is a simplified diagram illustrating another example detail of one embodiment of the health care monitoring system; Figure 7 is a A simplified diagram illustrating another exemplary detail of one embodiment of the health care monitoring system; FIG. 8 is a simplified diagram illustrating another example detail of one embodiment of the health care monitoring system; FIG. 9 is a simplified diagram illustrating Another exemplary detail of one embodiment of the health care monitoring system; FIG. 10 is a simplified diagram illustrating another example detail of one embodiment of the health care monitoring system; FIG. 11 is a simplified diagram illustrating the health care monitoring Another example detail of one embodiment of the system; FIG. 12 is a simplified flow diagram illustrating example operations that may be associated with one embodiment of the health care monitoring system; and FIG. 13 is a simplified flowchart illustrating possible Other example operations associated with one embodiment of the health care monitoring system.

Referring to Figure 1, Figure 1 is a simplified block diagram illustrating a health care monitoring system 10 for sharing data in a clinical network environment. The health care monitoring system 10 includes a clinical network 11 (generally indicated by an arrow) containing the patient 12, the medical provider 14, and the payer 16, which can communicate the data 18 with the server 20 located in the cloud 22. In general, data 18 refers to any type of number, text, sound, and view. Information, or manuscript material, or any type of source code or object code, or any other suitable information presented in any suitable format that can be transmitted from one point to another on an electronic device and/or network. Data 18 may include medical data 24, work data 26, and financial information 28. The material sharing module 30 associated with the server 20 and executing on the clinical operating system (cOS) 31 facilitates sharing with the material 18 of the community 32 in the network 11. Each community may include one or more participants 34. Each participant may include one or more clients 36.

The term "medical data" as used herein includes information (such as facts) related to the diagnosis or treatment of current or potential health conditions (eg, illness, diabetes, obesity, aging, etc.). Medical information for a particular patient 24, including patient health information collected from the patient (or family member) (eg, information about the health of the patient or health care provided to the patient), including In one or more sources of medical information, such as hospitals, nursing homes, medical centers, clinics, health or care facilities, health care facilities, etc. Medical data 24 may include demographic information (eg, age, weight, gender) that may be relevant to the diagnosis and treatment of current or potential health conditions. Medical data 24 can be generated on a number of occasions (eg, visits to doctors, laboratory tests, home tests). The term "patient" as used herein refers to an individual who is receiving, or will receive, or has received medical care and treatment.

Medical information 24 can be linked to primary health care services (eg, care and services provided by physicians and nurses under the direct guidance of physicians) and ancillary services (eg in home care, hearing tests, durable medical instruments (DME), outpatient surgery centers) (ASC), home injection, hospice care, professional care facility (SNF), cardiac test, mobile lithotripsy, fitness center, radiology, lung testing, sleep center and dialysis center, supplies and laboratories Test) associated (eg, through them, Export from them, based on them, etc.). Health care services that generate medical information 24 may include diagnostic (eg, diagnosis of health and disease), treatment (eg, treatment of health conditions and illness), and care (eg, care by a nursing home or hospital) health care services . By way of example and not limitation, medical data 24 may include clinical pathways (eg, processing a care plan, including one or more treatments that are prescribed to the patient according to a predetermined schedule); treatments (provided to ( Or in clinical and other related treatments (eg, events, activities, procedures, operations) of the patient; measurements of the instrument (eg, measurement of sphygmomanometers, blood glucose measurements, heart rate, etc.); and physicians at the time of the visit notes. Other examples of medical information 24 may include registration information (eg, contact information, social security numbers), demographic data (eg, birthday, gender, ethnicity), medications and allergies, immune status, laboratory test results, radiological images, and the like.

The term "job data" as used herein includes information relating to the supervision, design and control of procedures and business operations related to the provision of medical services by medical providers. The job profile 26 includes information relating to the efficiency and effectiveness of business operations and procedures for managing conversion inputs (e.g., materials, labor, and energy) into outputs (e.g., medical services and related products). The assignment data 26 may include the number of employees associated with the medical provider's medical services and the supply of related merchandise, resource allocation, employee schedule, resource scheduling, energy utilization, resource utilization, and the like.

The term "medical provider" is used herein to include individuals or groups that provide preventive, curative, generalized or rehabilitative health care services to multiple people in a systematic manner. Examples of medical providers 14 include health workers, internal medicine departments, hospitals, clinics, laboratories, nursing homes, primary care centers, secondary care centers, tertiary care centers, and first aid and emergency care centers. In a general sense, medical care providers are subject to the political areas in which they operate (eg, city, county, state, country). Protected by appropriate laws and regulations.

The term "financial information" as used herein includes information relating to the provision of medical services and related goods. Financial information 28 includes revenue, profits, costs, and other financial information associated with the operation of the medical provider's operations. Financial information 28 may also include payment, refunds, debts, and other financial information relating to the provision of medical services and related goods to the patient. For example, financial information 28 may include a billing code, a payment by a patient to his health insurance company, and a payment by the health insurer to a medical provider for a particular medical service. Financial information 28 may also include associated physician salary information, costs incurred by the medical provider when providing a particular medical service, and profits generated by the medical provider. The term "payer" as used herein refers to an individual or organization that pays (partially or completely) for the medical services and related goods supplied to the patient. Payers 16 may include health insurance companies, governments, and patients.

To illustrate the techniques of the health care monitoring system 10, it is important to understand the communication of a given system, such as that shown in FIG. The following basic information can be seen as the basis from which this disclosure can be properly interpreted. This information is provided for illustrative purposes only and, therefore, should not be construed in any way as the broadest scope of the disclosure.

Advances in the information technology (IT) infrastructure for health care supply have the potential to improve the safety, quality and efficiency of health care and health care. Computer-aided diagnosis can improve clinical decision making. A computer-based reminder system enhances consistency with preventive service agreements. Immediate access to computer-based clinical information such as laboratory and radiological results improves the quality of health care delivery. Similarly, in the care supply point, clinical decision supply system and other computer-aided health photos The availability of complete patient health information in the monitoring system avoids many errors and adverse events. In a general sense, patient health information can be shared across all authorized participants in a health care community through a secure IT infrastructure.

In general, such as the Health Insurance Portability and Accountability Act (HIPAA) (1996), the Health Information Technology Act for Economic and Clinical Health (HITECH) (2009), and the National Institutes of Health genome-wide association research strategy (National Institute of Health Genome Wide Association Studies Policy) (2007), EU Data Protection Order 95/46/EC and other laws regulate the collection and dissemination of medical data for patients to ensure patient privacy and reduce related concerns. Challenges for the collection and dissemination of medical data include the identification of private information under the Privacy Policy, the conversion of data to secure privacy, the use of quantitative data, and the publication of information.

Traditionally, medical providers such as hospitals, internal medicine departments, imaging centers, and clinical information systems have a culture that is conservative; medical materials are often stored in different departments, and the data in these different departments have minimal interactions or The ability of the department to use the data is much less than that of other medical providers. The existing medical information systems can be connected to arrays of resources such as billing systems, laboratories, imaging centers, and pharmacies; however, the extraction of complete patient data is clearly less comprehensive and practical. In addition, due to medical data privacy rules and regulations, data sharing between different medical providers serving the same patient is limited. Patients have limited access to their own data and the information in individual health care facilities remains completely isolated. Obviously, for a common goal (such as providing medical care to one or more patients), if multiple warehouse information can be linked together, and if seamless information can be provided between the relevant stakeholders Sharing has obvious advantages.

The functional requirements for medical data exchange are far more complex than those used for simple web-based file exchanges to share music, movies, and video, such as those available on Internet sites like FACEBOOK and YOUTUBE. And public. Examples of functional requirements and technical challenges for Internet-based systems for sharing medical data include: ensuring privacy and confidentiality of data; efficiently and reliably (eg, transmitting without loss) moving and storing large data files (eg radiographic images); assembling patient data, for example by registration, containing information on all segments of medical information from all sources (and their actual location) for a given patient; matching records and accurately Check the patient's identity; standardize access to the data and review the access; and aggregate and consume the data at the point of care. Compared to traditionally encountered people in simpler social networking situations and other Internet-based file exchanges, it is impractical to deploy and maintain in a health care environment without having to make the mistake of meeting these functional requirements. And a more complex data sharing system for monitoring.

Some mechanisms exist in a health care environment that promotes the sharing of medical information. For example, the CommonWell Health Alliance has a data sharing platform that allows members of the alliance to share patient data based on patient consent. The system provides a means for health care IT providers to pair patients with their health care records as they move between multiple care facilities. The system is based on patient consent and authorization to develop HIPAA-compliant means to share medical information and link records between multiple care locations. Patients can manage their consent through a patient portal application interface. Patient consent and guidance are stored in a central repository. The Patient Pairing API and Record Location API can pair a specific patient to a corresponding record and properly obtain records from their respective storage locations in the network. Of course However, the system does not expose coordinates between different member roles (eg, patients, providers, payers), and even more, may not provide different access rights to different participating members.

The health care monitoring system 10 is configured to address these (and other) issues that provide systems and methods for sharing information in a clinical network environment. An embodiment of the health care monitoring system 10 can provide an infrastructure for associating one or more participants 34 with one or more communities 32 in the clinical network 11. The data sharing module 30 can determine participant access to the material 18 of the database (e.g., stored in the cloud 22) and provide access to the material 18 based on a predetermined predetermined pattern associated with the material. The shared reservation mode may include a pessimistic mode, an optimistic mode, and an opportunity mode. According to this optimistic pattern, substantially all of the data 18 within the database is available to virtually all of the participants 34 in a particular community (e.g., community 1). The optimistic mode may not support the data section. According to this pessimistic pattern, for all participants 34 in that particular community (e.g., community 1), selected material 18 within the database is available. The pessimistic mode may be more supportive of the data section. According to the opportunity mode, for a particular participant 34 in the community (e.g., community 1), the selected custom material 18 within the repository is available. Opportunity mode may be more supportive of scoped data (eg, disparate data that is grouped together or customized according to predetermined attributes; for example, a data element X is assigned to tasks A, B, and C, which can be task A , B and C are free to access, but not available to tasks D and E), and less support for undefined data.

In a particular embodiment, community 32 may have access to different portions of material 18 stored in the repository. In some embodiments, the participant 34 may belong to more than one community (eg, belonging to Community 1 and Community 2). In some cases, participants 34 It can be part of an entity that participates in more than one community (eg, participating in Community 1 and Community 2). In a particular embodiment, client 36's access to material 18 may be set by the corresponding participant based on the client role. For example, a hospital's primary medical provider may have access to a portion of the data 18, while the primary financial provider of the same hospital may have access to different portions of the data. Moreover, in many embodiments, the access rights of each participant can be set by the community. For example, Participant 1 of Community 1 may have access to a portion of the material 18; Participant 2 of the same Community 1 may have access to different portions of the material 18. In some embodiments, the access rights of each participant may be determined based on community authentication settings and participant credentials associated with the community and the participants, respectively.

In various embodiments, each community may be identified by a community identifier that may link the patient 12, the medical provider 14, and the payer 16 between the plurality of entities. For example, a specific patient 1 can visit the medical provider 1 for the primary care. Assume that patient 1 visits the medical provider 2 for emergency care under certain circumstances. It is assumed that the medical providers 1 and 2 are within the community 1, and the community 1 is established and managed by a health insurance company (e.g., payer 1) whose patient 1 has his policy. According to various embodiments of the health care monitoring system 10, the medical provider 2 may access the information 1 of the patient 1 at the medical provider 1 through the community 1 although the medical provider 2 may have used the IT with the medical provider 1 Infrastructure and systems incompatible IT infrastructure and systems.

Depending on the level of participation, each participant can be associated with more than one community identifier. The Community Enterprise Level Primary Patient Index (EMPI) may be implemented in some embodiments. Content sharing, in some embodiments, may be in the level of the folder, ie the folder content may be properly shared or not shared by any content. For example, the privacy settings in the folder can be specified by the folder owner, and This setting may be appropriately related to the sharing mode (eg, optimism, pessimism, opportunity, etc.). The folder level privacy setting may extend as appropriate to substantially all of the content of the folder.

As for the infrastructure of the health care monitoring system 10, the network topology of the network 11 can include any number of servers, routers, gateways, and other interconnected nodes to form a large and complex network. A node may be any electronic device, client, server, peer point, service program, application, or other entity that can transmit, receive, or post information on a communication channel in the network. The components of Figure 1 can be connected to one another through one or more interfaces that employ any suitable connection technique (wired or wireless) that provides a viable path for electronic communications. Moreover, any or more of these elements may be combined or removed from the architecture based on particular assembly requirements.

The health care monitoring system 10 may include a configuration of TCP/IP communications that can be used for electronic transmission or reception of data packets in the network. The health care monitoring system 10 can also operate in conjunction with Client Packet Agreement/Internet Protocol (UDP/IP) or any other appropriate agreement, as appropriate and based on specific needs. Moreover, gateways, routers, switches, and any other suitable node (physical or virtual) may be used to facilitate electronic communication between various nodes in the network.

It should be noted that the numerical values and textual characters given to the elements of FIG. 1 do not represent any form of hierarchical relationship; these marks are used arbitrarily and only for teaching. Such indicia should not be interpreted in any way to limit their likelihood, functionality or application in a potential environment that may benefit from the features of the health care monitoring system 10. It should be understood that the health care monitoring system 10 shown in Figure 1 is simplified for ease of illustration.

The example network environment can be deployed on a physical infrastructure that may include one or more networks, and may even be combined in any form, including but not limited to, a local area network (LAN), a wireless local area network (WLAN). ), virtual local area network (VLAN), metropolitan area network (MAN), wide area network (WAN), virtual private network (VPN), internal network (intranet), external network (Extranet), any other suitable architecture Or any combination of systems, or those that facilitate communication in the network.

In some embodiments, a communication link may represent any electrical connection supporting a LAN environment, such as, for example, a cable, Ethernet, wireless technology (eg, IEEE 802.11x), asynchronous transfer mode (ATM), fiber optics, etc., or Any suitable combination of them. In other embodiments, the communication link may represent a remote connection through any suitable medium and/or through any other network, such as a wide area network (e.g., the Internet), such as Digital Subscriber Loop (DSL), telephone. Line, T1 line, T3 line, wireless, satellite, fiber, cable, Ethernet, etc., or any combination thereof.

In various embodiments, the clinical operating system (cOS) 31 may combine the data 18 with the federated central repository to aggregate data 18 (between others) from the patient 12, the medical provider 14, and the payer 16 18 Converting from a completely different format to a uniform format (eg, an XML-based format), and storing the data 18 to an appropriate data store in the cloud 22 (eg, a federated central repository; a data store for assembling data). The cOS 31 can include a plurality of self-contained interactive modules and service layers for linking proprietary (and public) systems and capturing and translating them while allowing flexible connections to existing and new applications. Information so that they can work together in a software ecosystem.

According to various embodiments, the server 20 includes a software program or a package A computing device executing the program provides a particular type of service to user software executing on the same computing device or on other computing devices of the network 116. Client 36 may include any electronic device, client, server, peer point, service program, application, or other entity that can transmit, receive, or forward information over a network (e.g., network 11). Examples of client 36 include computers, laptops, smart phones, printers, and the like. Client 36 may be configured with an appropriate interface (e.g., a web browser) that may display material 18, including browser code. In a general sense, client 36 may provide a user interface, such as a graphical user interface (GUI), and may perform some or all of the processing of the subject requests from "server 20 that maintains the data and processes the request." For ease of illustration, a single server 20 and some clients 36 are illustrated. Indeed, in the broad scope of these embodiments, the health care monitoring system 10 can include any number of servers and clients.

In some embodiments, the data sharing module 30 can be an application installed on a server 20 located in a remote network (eg, the cloud) from the patient 12, the medical provider 14, and the payer 16. 22) Medium. As used herein, the term "application" can encompass an executable file containing a plurality of instructions that can be understood and executed by a computer, and can further include a plurality of library modules loaded during execution, Target file, system file, hardware logic, software logic, or any other executable module. In other embodiments, the data sharing module 30 can be installed on a server 20 located in the same local area network as the patient 12, the medical provider 14, and/or the payer 16. In some embodiments, the data sharing module 30 can be installed on a single computer or server; in other embodiments, the data sharing module 30 can be a distributed application that resides on a plurality of devices, including virtual machines. Various hardware and software implementations are possible for the data sharing module 30, which are included in the embodiments. Wide range.

Patient 12, medical provider 14 and payer 16 can enter data 18 into health care monitoring system 10 through various computers, measuring instruments, public and proprietary software applications and systems, and other hardware and software components. Promote the operation of countless medical data sources and facilitate the transmission of data 18 with Cloud 24. Such a system can present a variety of completely different operating systems and platforms for the server 20, including EMRs, hospital information systems (HIS), laboratory and pathology systems (laboratory information systems, LIS), and contrast systems (PACS, RIS). ), dispensing systems, scheduling systems, medical devices, etc. In some embodiments, each medical data source may be a separate system, each having its own computer network, data format, and proprietary applications. In other embodiments, substantially all of the medical data sources may be part of a single system (eg, a corporate network, software, etc.) that can interface with each other and with the health care monitoring system 10.

The cloud 22 is a collection of hardware and software that forms a shared pool of computing resources (eg, networks, servers, storage, applications, service programs, etc.), and the computing resources are suitably prepared Provide on-demand self-service, network access, resource sharing, resiliency and measurable services and other features. The cloud 22 can be configured as a private cloud (eg, an infrastructure used by a single enterprise/organization), a social cloud (eg, an infrastructure shared between several organizations to support a particular community with a common concern), There are clouds (such as the infrastructure available to a wide range of people), or the right combination of two or more completely different types of clouds. The cloud 22 can be operated by a cloud service provider that can provide at least client access to the cloud 22 and authorization to use cloud resources in accordance with a predetermined service level agreement.

Referring to FIG. 2, FIG. 2 is a simplified block diagram of an example of a data sharing module 30 exemplified in accordance with an embodiment of the health care monitoring system 10. Data sharing module 30 can include a patient database module 40 that can access a database 41 for storing data 18, a patient list module 42, a provider list module 44, and a primary patient index module. 46. A participant list module 48, a community creation module 50, a participant permission module 52, a rule creation module 54, and a security module 56. The patient database module 40 can control access to the database 41 of the stored data 18. The data 18 may be stored in the repository 41 in any suitable format, form, form, list, etc., based on particular system requirements. The patient list module 42 can include a list of patients 12 whose information can be accessed through the health care monitoring system 10. The provider manifest module 44 may include a list of medical providers 14 that may service the patient 12 within the framework of the health care monitoring system 10.

The primary patient index module 46 can aggregate registration records from various medical providers 14 (and other sources, if available) to store patient name, birthday, gender, ethnicity, social security number with the patient's medical record. And information about the place of residence. The primary patient index provides a clear and complete view of the individual patient being treated by the medical provider 14 and a large-scale view of the demographic population. The participant list module 48 can include a list of participants 34 in each community indexed according to appropriate criteria, such as participant name, logo, and community identity.

In various embodiments, an administrator can use the information used by the patient list module 42, the provider list module 44, the primary patient index module 46, and the participant list module 48 to assemble a data sharing model. Group 30. In some embodiments, the information may be manually entered; in other embodiments, the information may be retrieved by the data sharing module 30 from the medical records and associated records entered (or stored) in the health care monitoring system 10.

The community creation module 50 can create a community 32, for example, associating participants 34 with a particular community based on a predetermined configuration. For example, a community manager can take advantage of The information sharing module 30 is associated with information about which participant 34 belongs to which community 32. In some embodiments, the community creation module 50 can interface with the participant list module 48 to Decide on the appropriate participants in the community. In some embodiments, the community creation module 50 can generate unique authentication settings for each community. The community authentication settings for a particular community can be applied to all participants 34 of that particular community. The community creation module 50 can also generate participant permission settings based on information from the participant rights module 52, as well as participant authentication settings. The participant rights settings and participant authentication settings can be controlled by or through the participant rights module 52. Participant permission settings and authentication settings can be applied to all clients 36 associated with individual participants. Each participant (eg, Participant 1) within a particular community (eg, Community 1) may have different rights settings and authentication settings than other participants within the particular community (eg, Participant 2) .

The rule creation module 54 can generate access rules for the participants 34 within the community 32 based on the rights settings and authentication settings from the participant rights module 52 and a sharing mode module 55. The shared mode module 55 can include a sharing mode that permits different portions of the material 18 in the repository 41 to be licensed. The resulting rules may include community access rules (such as which community is allowed to access which material), participant access rules (such as which participant is allowed to access which material), and user access rules (such as which use) Which data is allowed to be accessed). The security module 56 can include participant access rights and authentication settings from the participant rights module 52 in an authentication or security program.

During operation, an example client 58 can enter login credentials (e.g., username, password, passcode) into the health care monitoring system, for example, via a portal to the network. The login module 60 of the data sharing module 30 can receive the login credentials. The authentication module 62 can interface with the security module 56 and determine for the participant 34 whether the login credentials match the authentication settings. If they match, the rule checking module 64 can check Rules to determine which material 18 is accessible by client 58. A data access request can be generated by the data request module 66, which can transmit the request to the patient database module 40. The patient database module 40 can retrieve the requested material 18 from the database 41 and communicate it to the client 58 where the data can be appropriately displayed on the visual display 68. The data sharing module 30 can use the processor 70 and the memory component 72 to perform the operations described herein.

Referring to FIG. 3, FIG. 3 is a simplified block diagram illustrating example details of an embodiment of a health care monitoring system 10, for example, assume that participant 1 participates in community 1 and community 2; and participant 2 participates only in the community 1. Community 1 may have access to portion 74 (Part A) of material 18; Community 2 may have access to different portions 75 (Part B) of material 18. Assume that participant 1 has access to portion 76 (part A1) of portion A, and participant 2 has access to different portion 77 (part A2) of portion A. It is also assumed that the client 1 belonging to the participant 1 can access the portion 78 (partial A1_C1), and the client 2 belonging to the participant 1 can access the portion 79 (partial A1_C2). Participants 1 and 2 may have community specific authentication credentials to access Community 1. However, participants 1 and 2 may have independent and distinguishable participant authentication settings to enter community 1. Participant 1 can have different sets of community-specific authentication credentials to access Community 2. Similarly, clients 1 and 2 may have a user-specific authentication credential to access portions of their respective data 18.

When the client 1 logs in to access the health care monitoring system 10, the authentication settings of the first level may include the access space of the login community 1. The second level of authentication settings may include access to participant 1's access space. The third level of authentication settings may include access to the client 1's access space. In the access space of client 1, portion 78 of data 18 is accessible to client 1. Similarly, client 2 can also perform authentication settings. Three levels are reached to access the access space of client 2, in which portion 79 of material 18 can be accessed.

Referring to FIG. 4, FIG. 4 is a simplified diagram showing an example of a community 32 that is generated by a plurality of entities A-F in accordance with an embodiment of the health care monitoring system 10. An "entity" can include an individual or organization (eg, business, business, government agency, etc.). In the illustrated example, entity A may be a payer (eg, an insurance company) operating with one or more medical providers (eg, entity B-F). Community 32 may be generated by concatenating the first portion of entity A, the second portion of entity B, and the third portion of entity C. The portions of entities A, B, and C that form part of community 32 may constitute participants 34. Portions of entities A, B, and C that are not part of community 32 may not have access to material that is available to participant 34. Such access rights can be appropriately affected between each participant or influenced by the community manager.

Referring to FIG. 5, FIG. 5 is a simplified diagram illustrating an example entity 80 in accordance with one embodiment of a health care monitoring system 10. Entity 80 may include various components that form participants within one or more communities. For example, portion 82 can be a participant who is exclusive to community 1. Section 84 can be a participant who is exclusive to Community 2. Section 86 can be a participant only in communities 1 and 2. Part 88 can be a participant in community 3. Part 90 can be a participant only in communities 1 and 3. Section 92 can be a participant only in communities 2 and 3. Section 94 can be a participant within communities 1, 2, and 3. Part 96 can be a participant in Community 4, and so on.

Referring to FIG. 6, FIG. 6 is a simplified diagram showing an example of a plurality of communities according to an embodiment of the health care monitoring system 10. to make. Table 100 indicates an array of entities 1, 2, 3, and 4 that are participants in one or more communities 1-10. For example, entity 1 may be a participant of communities 1, 2, 3, 7, 8, and 10. Entity 2 may be a participant in Communities 1, 2, 5, and 7-10. Each entity may choose to participate in one or more communities based on a particular transaction or other need. For example, entity 1 may be a medical provider serving a patient, and the patients are members of a particular insurance company named entity 2. These patients may also use entity 3 as an emergency medical provider. Entity 1 may choose to participate in a community that includes entities 2 and 3. For example, entity 1 may have access to patient data maintained by entity 3 by participating in the community, thus enabling better medical decisions and clinical outcomes to be achieved.

Referring to Figure 7, Figure 7 is a simplified illustration of example details in accordance with one embodiment of a health care system 10. Portions of the material 102 in the patient database (e.g., database 41) may be accessed by participants in different communities 104-108. For example, a participant at community 104 may access portion 110 of material 102; a participant at community 106 may access portion 112 of material 102; and participants in community 108 may access material 102 Part of 114. Portions 110 and 112 may overlap; however, participants in community 104 may not be able to access data outside of the overlap in portion 112. Access rights to different communities may be distinguished by appropriate security procedures (eg, authentication settings such as login credentials).

Referring to Figure 8, Figure 8 is a simplified diagram illustrating example details in accordance with one embodiment of a health care system 10. The data of the patient database (eg, database 41) may be accessed by different participants based on the corresponding participant rights and the sharing mode of the data. For example, according to the optimistic sharing model, virtually all participants have access to portion 110 of the data in the patient database (eg, database 41; see also the example of the previous schema). On the other hand, according to the pessimistic sharing mode, the selected portion 120 can be accessed by substantially all participants in the community 104. In the random sharing mode, the customized portions 122, 124, and 126 (only a few of them) can be accessed by several selected participants, such as Participant 1, Participant 3, and Participant N, respectively. In some embodiments, several participants of the material that are accessible in the random mode may be selected based on individual participant access rights. Various other sharing modes are also encompassed within the broad scope of the embodiments.

Referring to Figure 9, Figure 9 is a simplified diagram illustrating an example visual display 68 in accordance with an embodiment of a health care system 10. Visual display 68 may include one or more community portals 130. Each community portal 130 may include one or more participant portals 132. Each participant portal 132 may include one or more client portals 134. Each client portal 134 may include a data portal 136 in which material accessible to the corresponding client may be displayed. In some embodiments, the data portal 136 can be accessed in the participant portal 132, for example, when the material is evenly shared among all clients of the individual participants. In some embodiments, the material portal 136 can be accessed in the community portal 130, for example, when the material is shared with substantially all of the participants in the community according to an optimistic pattern. In other embodiments, when the selected material is shared according to a pessimistic pattern, the selected material may be viewed in the data portal 136 in the community portal 130.

Referring to FIG. 10, FIG. 10 is a simplified diagram illustrating an example of details of data sharing in accordance with an embodiment of the health care system 10. Based on detail 138, each community 32 may be associated with an authentication setting that identifies a particular community. This authentication setting can be set by a community manager. According to detail 140, each participant can be associated with a permission setting that can be set by the community manager. For example, the payer participant may have access to virtually all financial resources in the patient database (eg, database 41). Permissions, and does not have permission to view selected medical materials. On the other hand, the medical provider participant may have access to virtually all medical data in the patient database (eg, database 41) and does not have access to the selected financial information. In some embodiments, the participant rights settings may be grouped according to the degree of participation of the corresponding participants. For example, participants may choose to participate only in the level of shared patient medical data and refuse access to the participant's operational data. In accordance with the broad scope of the embodiments, any level of participation may be covered and associated with appropriate permission settings.

Based on detail 142, each client in a particular participant may be associated with a client role setting that may be specified or assembled by the participant manager. In some embodiments, the client role setting may be transparent to the community. For example, a community participant access setting may allow substantially all clients of the participant to access the data accessible to the corresponding participant. However, the data may be subject to the client's own client within the participant's own role. In other example embodiments, the access rights of the client may be set by the community manager based on specifications (eg, access rules, etc.) provided by the corresponding participants.

Based on detail 144, the profile 18 can be associated with a profile owner and a sharing mode setting that is set by the patient's consent. For example, data accessed by a particular community may be owned by one of the participants in the community. The data owner can appropriately set the sharing mode (for example, pessimism, optimism, opportunity). In some embodiments, the data may be owned by a particular participant, but may be related to the private medical information of a patient. Access to this material may be controlled based on the patient's permission plus the data owner's sharing mode settings. Based on the data sharing model, patient permission, client role, participant permissions, and community authentication settings, as illustrated by detail 146, a subset of the data 18 may be for a particular client of a particular participant within a particular community. Accessible.

Referring to Figure 11, Figure 11 is a simplified diagram illustrating example operations that may be associated with an embodiment of the health care monitoring system 10. At step 150, a user can log into the community portal 130 using the community authentication settings. At step 152, the user may log into the participant portal 132 using participant credentials (eg, authentication settings such as username, password, etc.). At step 154, a request for material may be sent at participant portal 132. At step 156, the requested material may be viewed at participant portal 132, such as at data portal 136. Alternatively (or additionally), the user can log in to the client portal 134 using user credentials (eg, username, password, etc.). At step 160, a request for material may be sent at the client portal 134. At step 162, the requested material may be viewed at the client portal 134, for example, at the data portal 136.

Referring to FIG. 12, FIG. 12 is a simplified diagram of an example operation 170 that may be associated with an embodiment of the health care monitoring system 10 when a data request is received. At step 172, the decision whether the material is allowed to be shared may be made by the data owner. If no, the data request may be rejected and the operation may be terminated. If the data sharing has been agreed by the data owner, at step 174, the patient's decision to agree to share the patient data can be made. If no, the data request may be rejected and the operation may be terminated. If the patient allows data sharing, at step 176, the sharing mode can be determined. If the sharing mode is optimistic, in step 178, substantially all of the material can be shared with substantially all of the participants in the community. If the sharing mode is pessimistic, in step 180, the selected material can be shared with virtually all participants in the community. If the sharing mode is an opportunity, at step 182, the customized material (eg, the delimited data) can be shared with different participants in the community.

Referring to Figure 13, Figure 13 is a simplified diagram illustrating an example operation 190 that may be associated with an embodiment of a health care monitoring system 10. At step 192, health care supervisor The measurement system 10 receives login credentials (eg, username, password, pin code, passkey, etc.). At step 194, the login credentials are authenticated (e.g., via appropriate security procedures, such as checking credentials, security credentials, etc.). At step 196, the community associated with the login credentials can be determined. At step 198, the participants associated with the login credentials, along with the client access rights, may be determined. Please note that if the authentication fails at any time, the access rights of the health care monitoring system 10 may be completely or partially rejected.

At step 200, a data request is accepted. At step 202, a sharing mode of the requested material is determined. At step 204, a decision is made whether or not to agree to the access. If the access is permitted according to the community authentication setting, the participant credential setting, and the client role setting data sharing mode, in step 206, the requested data may be obtained from the patient database (for example, the database 41) and displayed. At an appropriate entrance, such as display portal 138. If access is not allowed at step 204, the data request may be denied at step 208, for example, using a "deny access" error message or other appropriate request rejection mechanism.

Please note that in this specification, "one embodiment", "example embodiment", "another embodiment", "some embodiments", "various embodiments", "other embodiments", "replacement" References to various features (e.g., elements, structures, modes, components, steps, operations, characteristics, etc.) within the embodiments and the like are intended to mean that any such features are included in one or more of the disclosures disclosed herein. Many embodiments are possible, but may or may not necessarily be incorporated into some embodiments.

In an example implementation, at least some portions of the actions illustrated herein may be implemented in software, for example, in data sharing module 30. In some embodiments, one or more of these features may be implemented in hardware, the hard system being provided outside of these elements, or incorporated into any suitable thing to achieve the desired work. can. Various network elements may include software (or interactive software) that can coordinate actions to achieve the operations as described herein. In other embodiments, these elements may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate their operation.

Furthermore, the data sharing module 30 (and/or its associated architecture) as described herein may also include appropriate interfaces for receiving, transmitting, and/or other means of transmitting data or information in a network environment. Moreover, some of the processors and memory elements associated with the various nodes may be removed or otherwise merged to allow a single processor and a single memory element to be responsible for certain activities. In general, the configurations depicted in such figures may be more logical in other ways of expression, however, an entity architecture may include various permutations, combinations, and/or combinations of these elements. It must be noted that there are numerous possible design configurations that can be used to achieve the operational objectives described herein. As a result, the associated infrastructure has numerous alternative configurations, design choices, device possibilities, hardware assembly, software implementation, device selection, and the like.

In some example embodiments, one or more memory elements (e.g., memory element 72, database 41) may store data for performing the operations as described herein. This includes memory elements that can store instructions (e.g., software, logic, code, etc.) in non-transitory media, such that the instructions are executed to perform the activities described herein.

The processor can execute any type of instruction associated with the material to achieve the operations described in detail in this specification. In one example, a processor (eg, processor 70) can convert an element or an item (eg, material) from one state or thing to another state or to another. In other examples, the activities described herein may be implemented in fixed logic or planable logic (eg, software/computer instructions executed by a processor), and such elements as defined herein may be of certain types. Planable processing , programmable digital logic (eg, field programmable gate array (FPGA), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), including digital logic , software, code, electronic instruction ASIC, flash memory, compact disc, CD-ROM, DVD ROM, magnetic or optical card, other types of machine readable media suitable for storing electronic instructions, or any suitable combination thereof.

In operation, the components within the health care monitoring system 10 can include one or more memory components (e.g., memory component 72, library 41) for storing information for use in achieving the operations as described herein. When appropriate and based on specific needs, these devices may further store information in any suitable type of non-transitory storage medium (eg, random access memory (RAM), read only memory (ROM), field programmable logic gate arrays (FPGA), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), etc., software, hardware, or any other suitable component, device, component , or in an object.

Information that is tracked, transmitted, received, or stored in the health care monitoring system 10 may be provided to any database, register, form, cache, queue, control list, or storage based on specific needs and implementations. In the structure, they can all be referred to at any appropriate time. Any memory item mentioned in this article should be interpreted as being within the scope of the term "memory component" in the broad sense. Similarly, any of the possible processing elements, modules, and machines described in this specification should be construed as being within the broad term "processor".

It is also important to note that the operations and steps described in connection with the foregoing figures are merely illustrative of some of the many possible solutions that may be performed by the system, or in the system. Some of these operations can be removed or removed when needed, or those steps can be adjusted fairly without departing from the scope of the concepts discussed. Or change. Moreover, the timing of these operations may be fairly replaced, while still achieving the results taught by the present disclosure. The foregoing operational procedures are presented for purposes of example and discussion. The system provides substantial flexibility in which any suitable arrangement, time arrangement, configuration, and immediate mechanism can be provided without departing from the teachings of the concepts discussed.

Although the present invention has been described in detail with reference to the particular arrangements and configurations, these example configurations and arrangements can be varied substantially without departing from the scope of the disclosure. For example, although the disclosure has been described with reference to special communication exchanges relating to specific network access and protocols, the health care monitoring system 10 is also applicable to other switching or routing protocols. Even though the health care monitoring system 10 is exemplified with reference to particular components and operations that facilitate communication processing, these components and operations may be replaced by any suitable architecture or process for achieving the desired efficacy of the health care monitoring system 10.

Many other variations, substitutions, alterations, substitutions, and adaptations are known to those skilled in the art, and the disclosure is intended to cover all such variations, substitutions, changes, substitutions, and adjustments. Within the scope of the patent application. In order to assist the patent agency and any readers who assist in granting any patent in this application to explain the scope of the patent application, the applicant wishes to remind the applicant: (a) does not intend to include any attached request to invoke the application at the time. 35 USC, Article 112, paragraph 6, unless the “devices used for” or “steps for” are specifically used in a particular request; and (b) is not intended to be used in any of the The statement is intended to limit the disclosure in any way that is not reflected in the appended claims.

10‧‧‧Health Care Monitoring System

11‧‧‧ Clinical Network

12‧‧‧ Patients

14‧‧ Medical providers

16‧‧‧Payers

18‧‧‧Information

20‧‧‧Server

22‧‧‧ Cloud

24‧‧‧ Medical Information

26‧‧‧Working materials

28‧‧‧Financial information

30‧‧‧Data Sharing Module

31‧‧‧Clinical operating system

32‧‧‧Community

34‧‧‧Participants

36‧‧‧Client

Claims (20)

A method comprising: associating a participant with a community within a clinical network environment, the clinical network environment comprising a plurality of patients, a medical provider, and a payer; determining a database Participant access to the information, wherein the information includes medical information, financial information, and operational data, wherein the information is associated with at least one of a patient, a medical provider, and a payer; and based on the information The associated one of the predetermined sharing modes provides access to the material, wherein the predetermined sharing mode is selected from the group consisting of a pessimistic mode, an optimistic mode, and an opportunity mode. The method of claim 1, wherein substantially all of the material in the database is available to substantially all of the participants in the community according to the optimistic pattern. The method of claim 1, wherein, according to the pessimistic pattern, substantially all of the participants in the community can obtain selected materials in the database. The method of claim 1, wherein, according to the opportunity mode, a particular participant in the community can obtain the selected subscription material in the database. The method of claim 1, wherein the plurality of communities have access to different portions of the material. The method of claim 1, wherein the participant belongs to more than one community. The method of claim 1, wherein the participant is part of an entity that participates in one or more of the communities. The method of claim 1, wherein the access rights of the participant are set by the community. The method of claim 1, wherein the participant comprises at least one client, wherein the client access to the material is set by the participant according to the role of the client. The method of claim 1, wherein the participant's access rights are determined based on community authentication settings and participant credentials associated with the community and the participant, respectively. A logic written in a non-transitory medium, comprising a plurality of execution instructions, and when executed by a processor, operable to: cause a participant to be associated with a community within a clinical network environment The clinical network environment consists of multiple patients, medical providers and payers; it determines the access rights of participants to the information in a database, which includes medical data, financial information and operational data. Wherein the information is associated with at least one of a patient, a medical provider, and a payer; and providing access to the data based on a predetermined sharing mode associated with the profile, wherein the predetermined sharing mode is selected Since the group consists of pessimistic mode, optimistic mode and opportunity mode. As in the logic of claim 11, wherein, according to the optimistic pattern, substantially all of the material in the database is available to substantially all participants in the community. The logic of claim 11, wherein, according to the pessimistic pattern, substantially all of the participants in the community have access to selected materials in the database. The logic of claim 11, wherein, according to the opportunity mode, a particular participant in the community can obtain the selected subscription material in the database. The logic of claim 11, wherein the access rights of the participant are based on The community and the community certification settings associated with the participant and the participant credentials are determined. A device comprising: a community creation module; a rule creation module; a memory component for storing data; and a processor executing instructions associated with the data, wherein the processor and the memory component are common Operating such that the device is configured to associate a participant with a community within a clinical network environment that includes a plurality of patients, medical providers, and payers; Participant access to information in a database, wherein the information includes medical data, financial information, and operational data, wherein the information is associated with at least one of a patient, a medical provider, and a payer; And providing access to the material according to a predetermined sharing mode associated with the material, wherein the predetermined sharing mode is selected from the group consisting of a pessimistic mode, an optimistic mode, and an opportunity mode. The device of claim 16, wherein, according to the optimistic pattern, substantially all of the material in the database is available to substantially all of the participants in the community. The device of claim 16, wherein, according to the pessimistic pattern, substantially all of the participants in the community have access to selected materials in the database. The device of claim 16, wherein, according to the opportunity mode, a particular participant in the community can obtain the selected subscription material in the database. The device of claim 16, wherein the access rights of the participant are based on The community and the community certification settings associated with the participant and the participant credentials are determined.