METHODS AND APPARATUS FOR RESPONDING TO REQUEST FOR CLINICAL INFORMATION
A hub-spoke patient information service in which a patient's data can be obtained from a network of independent data sources through a centralized service. The hub of the service stores patient identification information and the spokes store the patient's clinical data. In a preferred embodiment, the spokes are independent sources (e.g. each spoke is generally unrelated to other spokes) and include hospitals, doctor offices, clinics, insurance companies, or other entities that store or track clinical data. Preferably, the data sources use a first authentication to properly identify or authentic the service. Once access is granted, the spoke sources are queried for the patient's data. In response, each data source provides the type of patient data available from the source. The user is shown the types of data available without generally showing the actual data. The user can then select the specific patient data to retrieve from the spoke sources.
Latest QSI MANAGEMENT, LLC Patents:
This application is a continuation of U.S. application No. 12/519245 filed Jun. 15, 2009. U.S. application No. 12/519245 filed Jun. 15, 2009 entitled Methods And Apparatus For Responding To Request For Clinical Information is based on PCT/US2007/026270 which was filed on Dec. 20, 2007 and claims the benefit of U.S. Provisional Application No. 60/871064 filed Dec. 20, 2006. This and all other extrinsic materials discussed herein are incorporated by reference in their entirety. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.
FIELD OF THE INVENTIONThe field of the invention is medical data storage and retrieval.
BACKGROUNDWhen an individual visits a hospital, clinic, or physician, numerous patient records related to the visit are created. Patient records traditionally have been maintained in paper form by the provider responsible for creating the records, but more recently patient records are migrating to various electronic forms. As a result, significant efforts have been placed on creating a national/regional network for access to patient records, regardless of the location of the records, or the specific healthcare provider creating the records.
Numerous problems exist in developing a national/regional network for access to patient records. One problem is that there are hundreds of thousands of medical service providers (hospitals, clinics, doctor's offices, etc . . . ) that operate more or less autonomously. As a result there is considerable inconsistency with respect to the software and equipment used to capture and store the data, the fields of data captured, the formats used, archiving policies, and so forth. A second problem is that each provider wants ultimate control over its own data, but wants easy access to data generated by others. Still a third problem is that patients want to keep their records confidential.
Several different systems have been proposed. A fully centralized approach is known where the data records are stored in a central record repository. (See e.g., US 2006/0129434 to Smitherman, US 2007/0055552 to St. Clair, US 2007/0016450 to Bhora). However, this model requires broad agreement among healthcare providers that all data records will be managed by a central authority. Moreover, the scaling, reliability, and privacy issues associated with a central record repository are formidable.
A fully decentralized approach is also known, which allows a provider to access records distributed across multiple healthcare database management systems as though they were stored locally at the provider. Using this approach, electronic records regarding a given patient can be assembled on demand to provide a complete healthcare history of the individual. For example, Connecting For Health consortium (see http://www.connectingforhealth.org/assets/reports/linking_report—2—2005.pdf), provides a central store that only maintains: (a) name, address, age, gender and other non-unique patient identification information; and (b) links to records in the local databases. (See also e.g., US 2005/0246205 to Wang). A drawback to using a decentralized approach is that users can receive incomplete patient records because of the diverse set of data sources, and the inability to extract relevant information from some of the sources. Moreover, many providers can be unwilling or unable to manage a local infrastructure.
US 2005/0027995 to Menschik teaches a decentralized network for mediating peer-to-peer transfer of patent medical data including a plurality of decentralized agents associated with a health care provider and connected to a central network. Unfortunately, Menschik requires all peers to authenticate all other peers, which results in an unwieldy, distributed mesh of trust. Such an approach lacks scalability because the number of authenticated relationships increases on the order of N2 where N is the number of peers in the system. The system becomes impractical for N anywhere near as large as that required for a national medical network.
In between the centralized and decentralized approaches are hybrid approaches where some patient records can be centralized and others are stored in a decentralized network. (See e.g., US 2007/0214016 to Bennett). There are several new problems with these hybrid approaches. For example, problems can arise in deciding whether to store a particular record in a centralized or local data store. In addition, the relative importance of a particular electronic healthcare record can change with the occurrence of contemporaneous events, and therefore the record might not be placed properly in the right data store.
Currently, there is no solution that resolves all of the problems. Consequently, there is still a need for a system that combines demographic, clinical, and other practice-related data from multiple independent data sources, that can be conveniently mined and scaled easily as new data sources are added to the system.
SUMMARY OF THE INVENTIONThe present invention provides apparatus, systems and methods in which a patient's data can be obtained from a network of independent data sources through a centralized service. The service preferably comprises a hub-spoke network of data sources. The hub of the service stores patient identification information and the spokes store the patient's clinical data. In a preferred embodiment, the spokes are independent sources (e.g. each spoke is generally unrelated to other spokes) and include hospitals, doctor offices, clinics, insurance companies, or other entities that store or track clinical data.
In one aspect, users can log on to the service to access the patient's data. The patient's identification information can be used identify a set of “spokes” data sources having the patient's data. Preferably, the data sources use a first authentication to properly identify or authentic the service. Once access is granted, the spoke sources are queried for the patient's data. In response, each data source provides the type of patient data available from the source. The user is shown the types of data available without generally showing the actual data. The user can then select the specific patient data to retrieve from the spoke sources. At least a subset of the patient's is retrieved from at least one of the spoke source using a second authentication.
Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawings in which like numerals represent like components.
User 110 is defined as any doctor, hospital, clinic, healthcare organization, and/or research facility, geographically located anywhere that uses patient clinical data for the purposes of patient care and/or research regardless of where the data physically resides.
For purposes of the present invention, the “patient clinical data” of interest includes patient histories, medical records, lab tests, X-rays, prescriptions, diagnosis', treatment information, and other patient clinical data stored in a local “data store” 132A, 132B, . . . 132N at spoke sources 130A, 130B, . . . 130N. The term “data store” is used euphemistically to represent any storage of data including a file system, a web site, a database, or other system where data can be accessed.
Each of the spoke sources 130A, 130B, . . . 130N represent any individual, entity, or organization that provides health care related goods or services to, or on behalf of, a patient. For example spoke sources 100A, 100B, . . . 130N include primary care physicians, clinics, hospitals, research facilities, and other entities that provide healthcare services. Spoke sources 130A, 130B, . . . 130N can also include other health-care related entities including pharmacies, pathology laboratories, insurance companies, rehabilitation centers, or other entities requiring access to the patients clinical data. More generally, spoke sources 130A, 130B, . . . 130N represent any entity that maintains a local data store of patient clinical data. For simplicity purposes only three spoke sources have been shown in
It will be appreciated that privacy and security are important to the communication of patient clinical data. In the described embodiments, the various components of the hub-spoke network 100 communicate securely over the Internet using any suitable algorithms or protocols that provide confidentiality, authentication, or data integrity (e.g. HTTPS, SSL, SSH, AES, 3DES, PGP, RADIUS, Kerberos, or other security methods) or alternatively, hub-spoke network 100 can be configured to communicate over a virtual private network.
The systems and methods of the present invention can be implemented in any number of ways, preferably including at least one instance of a first software 230 that exports from spoke source data stores 220 to the central data store 210, and at least one instance of a second software 250 that uses the patient identification information to access additional corresponding patient clinical data in accordance with authentication controls, described below. Instances of both the first software 230 and the second software 250 can advantageously be implemented at the spoke source data stores 220, although one or both can also be implemented at the central data store 210, or elsewhere.
First software 230 extracts or at least transfers patient identification information and some types of patient clinical data available, generally without showing the patient's data falling within the types of but not all patient data to the central store 210. Of course, central data store 210 is logically, and not necessarily geographically central to the spoke source data stores 220, and indeed might itself be distributed or include some sort of edge cache. For example, first software 230 can be embodied by an SQL database storing store patient data. When the database is queried, the data can be collect and sent over a secure HTTPS link to a central service having the central data store.
Information stored in central data store 210 is accessible by any number of instances of interfaces (described below), two of which are shown here as interfaces 240A and 240B. Interface 240A could be operated, for example, by a physician or other personnel at a facility associated with one of the spoke source data stores 220. Interface 240A works with the instance of the second software 250 to pull information from the central data store 210 and possibly from one or more of the spoke source data stores 220 (according to authentication). Interface 240B could be operated, for example, by personnel at the Centers For Disease Control, or some other government or non-government agency, and would again pull information from the central data store 210 and possibly from one or more of the spoke source data stores 220 (according to authentication).
In preferred embodiments, at step 510 the central data store stores some identification information of the patient (
At step 520, the hub-spoke patient information service authenticates a user that wishes to access the service. Additionally, a fee can be charged for accessing hub-spoke service, as shown by step 524. Preferred fees can include per usage fees, commissions, subscription fees, fees related to the quantity of data requested, or other compensation for usage of the hub-spoke service. Authentication of the user can be accomplished by a user name and password field using any suitable user authentication (e.g. RADIUS, Kerberos or other authentication methods). In preferred embodiments, step 520 includes step 522; providing a user with different levels of access depending on the user's access level.
For example, Level 1 access can be given to each individual patient, allowing a patient to: (a) at least partially control access by others to at least some of his/her own clinical data via the system; (b) at least partially determine a source of at least some of his/her own clinical data stored on the database; (c) at least partially determine information relating to historical queries against the database for at least some of his/her own clinical data stored on the database; (d) selectively release contact information for himself/herself to other non-medically related members of the public; (e) selectively release contact information for himself/herself to only certain classes of inquirers; and (f) sell information stored on the database for his/her own profit.
Level 2 access is given to the author of the medical records, for example the physician or other healthcare provider who created the record. An individual with Level 2 access can read all documents within the service as well as update and create new records. Level 3 access can provide access to an institution or group practice, wherein the patients will typically receive a variety of healthcare services that can come from any spectrum of inpatient, emergency, laboratory, imaging, and some other types of outpatient services associated with the institution or group practice. All healthcare providers who are registered as care providers under an institutional license are granted Level 3 access. Level 4 access can provide access under emergency circumstances, for example where a patient can be unconscious or otherwise non-responsive. Level 5 access can provide access to governmental agencies, for example the CIA, NSA, FBI, and other governmental agencies. One should appreciate that additional and/or different levels of access are contemplated.
Referring again to
Upon authentication of the hub-spoke service with the identified spoke sources, at step 540 in
Optionally Step 540, can also include step 544, in which the hub-spoke service obtains a patient's authorization before retrieving a patient's clinical data. Preferred authorization methods include signed documents, electronic signature, or verbal authorization. In alternative embodiments, authorization information to retrieve information to table 400 in
Once the patient clinical data is located on the central store, the hub-spoke service, at step 550, populates a table 400 (as shown in
At step 558 in
It is contemplated that step 550 can include the hub providing the types of data available, as shown by step 554 in
At step 560, the hub-spoke service enables the user to select the patient's clinical data to be retrieved from the set of identified spoke sources, as shown by the X's in selection columns 450 in
Once the user has selected the appropriate boxes for the patient's clinical information to be retrieved from the set of identified spoke sources, the user clicks on the retrieve selected data button 430. At step 570, the hub-spoke service retrieves a subset of the patient clinical data (i.e. selected data) from at least one of the set of spoke sources using a second authentication. In preferred embodiments, the retrieved information is displayed in a separate screen (not shown). Contemplated second authentication can include system-to-system authentication as describe previously. Additionally, it is contemplated that data exchange of confidential patient data can be performed using suitable encryption techniques or protocols (e.g. AES, 3DES, SSL, SSH, HTTPS, or other secure data exchanges).
It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms “comprises” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps can be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refers to at least one of something selected from the group consisting of A, B, C . . . and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc.
Claims
1. A hub-spoke system for obtaining patient's clinical data, the hub-spoke system comprising:
- a set of spoke sources, wherein each spoke source in the set of spoke sources is configured to store clinical data of a patient associated with different types of clinical data; and
- a hub communicatively coupled with the set of spoke sources, wherein the hub comprises a patient identification database configured to store identification information of the patient and is configured to:
- authenticate a user to access the hub; query, upon receiving a request by the user, the set of spoke sources using a first authentication to authenticate the hub with the set of spoke sources; retrieve, immediately after receiving the request, a first subset of clinical data of the patient available to the user from the set of spoke sources based on the first authentication; provide a user interface that presents to the user a clinical data report comprising the first subset of clinical data, wherein the clinical data report lists the different types of clinical data, generally showing the subset of patient's clinical data falling within some, but not all, of the different types, wherein each type of clinical data is shown with an indicator indicating whether the type of clinical data is or is not available for the user to retrieve; enable the user to select a type of clinical data to be retrieved from the set of spoke sources; retrieve a second subset of the clinical data from at least one spoke source of the set of spoke sources using a second different authentication; and provide a new user interface for the user by including the second subset of the clinical data in the clinical data report.
2. The hub-spoke system of claim 1, wherein the hub is further configured to obtain patient authorization to retrieve the patient's clinical data.
3. The hub-spoke system of claim 1, wherein the hub is further configured to disambiguate the patient's first subset of clinical data and the second subset of clinical data.
4. The hub-spoke system of claim 1, wherein the plurality of different types of clinical data include at least one of a diagnosis, a treatment, a test result, and an outcome.
5. The hub-spoke system of claim 1, wherein the patient's identification information includes a national patient identifier.
6. The hub-spoke system of claim 1, wherein the hub is further configured to hide the patient's clinical data.
7. The hub-spoke system of claim 1, wherein the hub is further configured to show the user a date corresponding to a time when the patient's clinical data became available.
8. The hub-spoke system of claim 1, wherein the clinical data report lists the plurality of different types of clinical data without showing an identification of the spoke sources.
9. The hub-spoke system of claim 1, wherein the hub is further configured to provide the user access to different levels of the patient's clinical data based on the first authentication.
10. The hub-spoke system of claim 9, wherein the hub is further configured to enable the patient to authorize access to the different levels of the patient's clinical data.
11. The hub-spoke system of claim 1, wherein the hub is further configured to provide a natural language interface to query the service for the patient's clinical data.
12. The hub-spoke system of claim 1, wherein the hub is further configured to provide a language translation interface to display the patient's clinical data in a selected language.
13. The hub-spoke system of claim. 1, wherein the second authentication is different for each of the set of spoke sources.
14. The hub-spoke system of claim 1, wherein the hub is further configured to encrypt the patient's clinical data.
15. The hub-spoke system of claim 1, wherein the first authentication is common across the set of spoke sources.
16. The hub-spoke system of claim 1, wherein the hub is further configured to charge the user a fee for accessing the service.
Type: Application
Filed: Oct 25, 2013
Publication Date: Feb 27, 2014
Applicant: QSI MANAGEMENT, LLC (Irvine, CA)
Inventors: Bryan Rosenberger (Pennsburg, PA), Timothy Eggena (Hamilton), Robert Nary (Voorhees, NJ), Robert Hale (Atlanta, GA), Patrick Cline (Southlake, TX), Robert Ellis (Ocean Grove, NJ)
Application Number: 14/063,514
International Classification: G06F 19/00 (20060101);