Tools for access to databases via internet protocol networks

[0001] This patent document contains information subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent, as it appears in the US Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever.

[0002] Aspects of the present disclosure relate to tools for secure remote access to information over Internet protocol networks.

[0003] Sensitive data may be stored in various types of guarded databases, while a custodian is responsible for populating, updating, and guarding access to the sensitive data. Meanwhile, an information seeker may desire access to the sensitive data, and may be authorized to obtain such access. There is a need for tools to make it easier for information seekers to remotely access guarded databases.

[0004] One embodiment is directed to apparatus. In the apparatus, a trusted intermediary computer screen user interface is provided. An identification information input receives, via the computer screen user interface, information identifying an authorized information seeker. The information seeker seeks access to a remote database via an internet protocol connection. An authorization confirmation display displays, via the computer screen user interface, that the authorized information seeker is confirmed as authorized to access the remote database. An access code request input requests, via the computer screen user interface, an access code for use by the authorized information seeker to access the remote database via the internet protocol connection. An access code output outputs the access code for use by the authorized information seeker.

[0011] Sensitive data may be stored in various types of guarded databases, while a custodian is responsible for populating, updating, and guarding access to the sensitive data. Meanwhile, an information seeker may desire access to the sensitive data and may be authorized to obtain such access.

[0012] There is a need for tools to make it easier for information seekers to remotely access guarded databases. For example, medicine was traditionally a field driven by personal interaction and built on personal relationships. Doctors and other medical personnel knew the patient and his or her family, and thus, knew the persons to whom information on a patient's condition could be given.

[0013] As the field of medicine has become larger and more complex, an ever-increasing body of entities, such as insurance companies, commonly request and need medical information. Family members themselves are often geographically spread out, and not all family members may be known to the physicians and staff treating the patient. Medicine is still driven by interpersonal relationships, but more and more concern has been expressed about patient privacy and access to medical information.

[0014] In order to protect patients from unauthorized disclosure of their medical information, the U.S. Government has enacted a number of laws. One notable recent law in this area is the Health Insurance Portability and Accountability Act of 1996 (HIPAA). HIPAA places strict controls on the ability of physicians and medical staff to disclose medical information. While these controls may prevent disclosure of medical information, they can also have negative effects on the patient and his or her family.

[0015] For example, remotely located children or other relatives of a hospitalized parent may have no way of obtaining information on the parent's medical status. If a child or other relative calls the hospital, hospital personnel may be reluctant to disclose information, either because they cannot be certain of the caller's identity, or because the patient has not specifically identified the caller as an approved recipient of medical information. The problem is compounded when the child or other relative is located far from the hospital and cannot present him or herself in person to receive the desired information.

[0016] FIG. 1 is a block diagram of a system, generally indicated at 10, for HIPAA-compliant access to patient medical information by one or more patient family members (PFM) 12. In system 10, each PFM 12 is issued a unique personal identification number (PIN) that identifies the PFM 12 as authorized to request and obtain patient medical information. When a PFM 12 requests information about a patient's condition, he or she also supplies his or her PIN, which is verified by the staff of the hospital or other medical facility 14 before disclosing the requested information.

[0017] System 10 is a decentralized and uniform system for determining which family members or other individuals are authorized to access patient medical information. A medical facility 14 may collect next-of-kin data, and it may issue PINs directly to eligible family members who have been identified as authorized by the patient. In addition, trusted intermediaries, referred to as HIPAA Legal Participants (HLPs) 16, are provided and qualified to identify family members authorized to receive patient medical information and to issue PINs to those family members. As will be explained in greater detail below, an HLP 16 may be an attorney, a notary, or another individual with the knowledge, skills, and training required to authenticate a family member.

[0018] By allowing an HLP 16 to authenticate a PFM 12 and issue a PIN, assuming that the number of HLPs 16 is numerous, system 10 provides numerous ways in which a patient family member 12 might become authorized to obtain medical information about a patient, even if the family member 12 is far from the medical facility 14 and the staff of the medical facility cannot directly verify the identity of the family member.

[0019] As one example, assume that a person with several family members becomes ill. Furthermore, assume that some or all of the patient's family members do not live near the patient. Using system 10, the distant family members could go to an HLP 16, for example, the family attorney, a notary, or another such professional, provide identification and proof of a relationship with the ill relative, and be granted a PIN by the HLP 16. The medical facility 14 would validate and recognize the PIN, and would then provide any requested medical information to which the requester is entitled.

[0020] The illustrated system 10 comprises four databases: a HIPAA Legal Participant Authorization Database (HADB) 18, a PIN Issuing Database (PIDB) 20, a PIN Look-Up Database (PLDB) 24, and a Patient Family Database (PFDB) 22. In the illustrated embodiment of system 10, the databases 18, 20, 22, 24 are implemented with appropriate secure database software, and communicate with each other and with other elements of system 10 by an appropriate secure protocol and infrastructure, such as the secure hypertext transfer protocol (HTTPS) using the World Wide Web (WWW) infrastructure. Other types of networks and interface protocols may be used in alternate embodiments. For example, communication between the databases 18, 20, 22, 24 could also be accomplished by S/MIME or another secure e-mail protocol. Additionally, although four databases 18, 20, 22, 24 are shown in the illustrated embodiment of system 10, the functions of two or more of the databases 18, 20, 22, 24 may be combined as necessary or appropriate. The functions of a single database may also be distributed over several networked databases.

[0021] Of the databases, HADB 18 serves as a database and associated registration system containing records for each of the HLPs 18. Thus, a record in HADB 18 might contain the name and address of the HLP 16, the date of registration, indications of the qualifications of the HLP 16 and the manner in which identity and qualifications were proved, and the unique user name and password of the HLP 16 that are used in PIN issuing transactions. HADB 18 may be coupled to other registration and administration systems that are not shown in FIG. 1. The particular fields of information that are stored in the HADB 18 and its associated systems may be any fields necessary or desirable for registration of and control over the HLPs 16.

[0022] The particular qualifications required of the HLP 16 and/or the method of qualifying depend on the particular regulatory framework and law at the national and/or local levels. Although the HLP 16 is schematically shown in FIG. 1 as presenting his or her credentials to the HADB 18 for simplicity of illustration, in general, a prospective HLP would present his or her credentials to an arbitrator, certifying authority, or automated certifying system coupled to the HADB 18, and if the prospective HLP met the requirements, he or she would be entered into the HADB 18 and provided with a username and password that would allow the HLP 16 to access the PIDB 20 and PFDB 22.

[0023] Although a username and password are provided in the illustrated embodiment of system 10, other access identifiers could be used in alternate embodiments. For example, the HLP 16 could be provided with a digital certificate or public/private key set for use in accessing the system, which may be especially useful if communication with the databases is by S/MIME or another secure e-mail protocol.

[0024] The particular qualifications necessary to qualify as an HLP 16 and the form of the certifying or credentialing authority would be determined by local or national regulators; however, system 10 may be configured to accommodate HLPs 16 of different qualification levels. For example, if a prospective HLP is a notary, he or she might be required to take and pass an examination on the laws and procedures relevant to practice as an HLP 16. However, if a prospective HLP is an attorney, he or she might not be required to take and pass the same examination as a notary, or might not be required to take an examination at all. Information from the HADB 18 could also be used to administer continuing legal education or other periodic recertification programs, for example, by checking the date of registration of an HLP 16 against the indications of the credentials of the HLP 16 that may be stored in the HADB 18. Ancillary programs using information from the HADB 18 may be run on the same platform containing the HADB 18 or on different platforms, depending on the implementation.

[0025] As was noted above, the HLP 16 receives credentials, such as a username and password, to access the PIDB 20 and PFDB 22. Of those databases, the PIDB 20 is the database that directly administers the allocation and, when necessary, revocation of PINs. Information stored in the PIDB 20 may include an identifier of the PFM 12, the issued PIN number, and an identifier of the issuing HLP 16. The identifier of the PFM 12 in the PIDB 20 may be a link to the records of the PFDB 22, which would contain data such as fuller information on the PFM 12, including an identifier of the PFM 12, an identifier of the patient or patients whose medical information the PFM 12 is authorized to receive, and any indications as to the duration or restrictions on the authorization. As shown in FIG. 1, data in the PFDB 22 is generally supplied either by the medical facility 14 or by the HLP 16; the data in the PIDB 20 is generally supplied by the HLP 16, although in other embodiments, the medical facility 14 (e.g., an HLP 16 within the facility 14) may supply a PIN directly to a PFM 12.

[0026] Information from the PIDB 20 and PFDB 22 is brought together for end-user use by the PLDB 24. The PLDB 24 receives information on active PINs from the PIDB 20 and on PFMs 12 from the PFDB 22. The data from both databases 20, 22 is merged, related, or otherwise associated such that the records relating to PFM 12 access to patient medical information may be accessed by personnel of the medical facility 14 in order to authenticate PFM 12 requests for information. Access to the PLDB 24 may be logged and stored in the PLDB 24 or another system in order to provide a record of which PFMs 12 requested information, and specific medical facility users may have individual usernames and passwords or other credentials for accessing the PLDB 24.

[0027] An exemplary method 100 for using system 10 is shown in FIG. 2, a high-level flow diagram. Prior to the tasks of procedure 100, one or more HLPs 16 would be credentialed and entered into the HADB 18 using whatever procedures are determined to be necessary by the appropriate regulatory authorities. The medical facility 14 would also be registered as an authorized user of system 10 using appropriate procedures.

[0028] Method 100 begins at act 102 and continues with act 104. At act 104, the medical facility 14 (or, in some embodiments, the patient him or herself) provides next-of-kin and other family member information to the PFDB 22, specifying those individuals that can have access to the patient's medical information. This information is typically provided by the patient on admission or first visit forms. However, in exigent circumstances, no next-of-kin or other family member information may be available from the patient and act 104 may be omitted or may be provided in advance by the patient through the use of an HLP. At act 106, a PFM 12 becomes aware of his or her family member's illness and approaches an HLP 16 with appropriate identification and proof of relationship to obtain a PIN. The HLP 16 reviews the identification and proof of relationship offered by the PFM 12 and method 100 continues with act 108, in which the HLP 16 decides whether or not the PFM 12 is bona fide and is indeed a relative of the indicated patient. If the PFM 12 is bona fide (act 108:YES), the HLP 16 issues the PIN at act 112 by performing an appropriate transaction using the PIDB 20 (in accordance with the rules and guidelines of the applicable regulatory framework). If the PFM 12 is not bona fide in the view of the HLP 16 and should not be authorized to access the patient's medical records (act 108:NO), method 100 terminates and returns at act 128. With respect to act 106, the initial contact with an HLP 16 may also occur before a patient becomes ill, if illness or a need for a PIN is foreseen.

[0029] Once an HLP 16 has issued a PIN to a PFM 12, the HLP 16 also updates the PFDB 22 with appropriate information on the PFM at act 114. At act 116, the PIN is sent from the issuing PIDB 20 to the PLDB 24. At act 117, the PFM data entered by the HLP 16 is sent to the PLDB 24. (Acts 116 and 117 may be performed in any order or simultaneously. Alternatively, PIDB 20 and PFDB 22 could be polled for updates at regular intervals.)

[0030] The next portion of method 100 begins at act 118, when the PFM 12, having been issued a PIN, makes a request to the medical facility 14 for information on the patient's status. At that point, the medical facility 14 verifies the PIN at act 120 using the PLDB 24. If the PFM 12 is authorized (act 122:YES), the facility 14 provides the data at act 124. If the PFM 12 is not authorized (act 122:NO), the PLDB 24 logs are updated to reflect the improper access attempt at act 126 before method 100 completes at act 128. After the facility provides the requested data at act 124, the PLDB 24 access logs are also updated before method 100 ends at act 128.

[0031] As can be seen from method 100, one advantage of system 10 is that very few assumptions are made about the infrastructure or communications avenues available to the PFM 12. For example, the contact between the HLP 16 and the PFM 12 may be in person, and the PFM 12 may request information from the medical facility 14 by telephone, in person, or by any other suitable mechanism. Only the HLP 16 and the medical facility 14 are assumed to have secure database access. Such “off-band” communications between the PFM 12 and the other aspects of system 10, which require very little infrastructure and very little action on the part of the PFM 12, provide convenience for the PFM 12, particularly in exigent circumstances, while maintaining the security of system 10.

[0032] However, if more advanced communication infrastructure is available to the PFM 12, use of that infrastructure could be included in other embodiments of a system such as system 10. For example, if the PFM 12 has access to S/MIME or another form of secure e-mail, or has another form of identifying access code from a public access code infrastructure (PKI) encryption/authentication scheme, that key could be used to identify the PFM 12 to the HLP 16 by WWW or e-mail communication, such that a personal or other appearance was not required. The PFM 12 could then also use S/MIME, a key, or an authenticated HTTPS-capable web browser in electronic communications with the medical facility 14.

[0033] Although the example of system 10 and method 100 are described in terms of rights to access the records of a single patient, a PIN issued to a PFM 12 may link the PFM 12 to the records of multiple patients. Additionally, although the description has set forth family members as a particular category, PINs may be issued to other individuals with a need to know, such as a person with power of attorney to handle the affairs of another, or, in particular cases, emergency management and other government personnel. The group of individuals to whom PINs may be issued for any particular patient is limited only by the applicable regulatory scheme.

[0034] However, a PIN might not entitle a PFM 12 to complete access to a patient's records. For example, in some embodiments, a PIN might entitle a PFM 12 only to a general status indication, such as “critical,” “critical but stable,” “stable,” or “good.” In other embodiments, the PFM 12 might be able to access additional information, such as information on vital signs, any scheduled medical procedures, current medications, and prognosis.

[0035] The use of system 10 to qualify HLPs 16 and issue PINs to PFMs 12 has been set forth. However, system 10 also includes functions that allow HLP credentials and PINs to be revoked, either automatically or for cause. As was set forth above, the records in the PIDB 20 and the PLDB 24 may include an expiration date for the PIN, after which the PIN is automatically deactivated by the PIDB 20 and PLDB 24. Additionally, circumstances may arise in which the patient him or herself requests that the access rights of some or all family members be revoked. In that case, the medical facility 14 could request that the appropriate PINs be deactivated, by interaction with either the PFDB 22 or PLDB 24. A medical facility 14 would also have the discretion to deactivate a PIN if, in the judgment of the medical staff, the PIN is being abused or has been stolen. In most embodiments, deactivated PINs will be retained by the databases 20, 22, 24 in order to provide a record of who had access to information at any one time.

[0036] As with PINs, the credentials of HLPs 16 could be set to expire after a defined period of time, and could be deactivated after expiration of that time period. For example, if the credentials of an HLP 16, such as a notary commission, are set to expire on a particular date, the rights of the HLP 16 to issue PINs could also be set to expire on that date. In another embodiment, HLP credentials could expire every year, with recertification required for reinstatement. HLPs 16 are generally monitored by an accrediting association, such as a state bar. If that accrediting organization finds that the HLP 16 is no longer qualified to practice (for example, because of misconduct), the accrediting organization may also communicate with the HADB 18 to have the credentials of the HLP 16 revoked or deactivated. In general, although system 10 is not itself necessarily a public key infrastructure system, system 10 may share some features of public key infrastructures, which have a defined procedure for revoking credentials and certificates.

[0037] Middleware and other database support applications may be used as desired to provide convenient interfaces to the information supplied by system 10. For example, in some embodiments, if the patient's chart is kept electronically, an updated list of authorized PFMs 12 and their PINs could be pulled automatically from PLDB 24 and included in the patient's chart.

[0038] FIG. 3 illustrates system 50, which is similar to system 10 and demonstrates an alternative way in which a PFM 12 might interface with the medical facility 14 to obtain medical information on a patient. In system 50, the medical facility 14 uses its information systems to regularly update a Patient Status Database (PSD) 52. The PFM 12 uses his or her PIN, along with the patient's identifying information, to interface with the PSD 52 using, for example, a World Wide Web browser client and accessing the PSD 52 using the HTTPS protocol. Access to the PSD 52 may also be by S/MIME or another secure communication mechanism.

[0039] FIG. 4 illustrates one example of the graphical portion of a World Wide Web browser-based secure interface 70 to PSD 52 in system 50. The data presented in interface 70 will vary from implementation to implementation, and may include any relevant data in PSD 52 or in other databases 18, 20, 22, 24 to which the PSD 52 is connected. In the illustrated example, interface 70 has a hospital identification portion 72, a user identification portion 74, and a patient information portion 76. The hospital identification portion 72 indicates which hospital's data is being accessed (in the illustrated case, “Healing Hands Hospital”). The user identification portion 74 identifies the username of the user accessing the database, and may provide other information about access rights. For example, in the illustrated embodiment, the user's PIN expiration date and the name of the granting HLP 16 are shown.

[0040] The patient information portion 76 contains information about the patient. The particular information provided will vary, depending on regulatory disclosure requirements, available information, and the access level or restrictions (if any) of the user who accesses the PSD 52. In the illustrated embodiment, the patient's name, number, attending physician and telephone number, nursing staff telephone number, location, and room phone number are provided. Also provided is basic information on the patient's condition, including the diagnosis, the patient's general condition, and information on any scheduled medical procedures. As shown in FIG. 4, the patient's diagnosis in this case is “myocardial infarction” and the patient is scheduled to undergo a cardiac catheterization, the time and place of which are given, along with the name of the physician performing the procedure. However, the patient information portion 76 of FIG. 4 shows that in the illustrated embodiment, the particular PFM 12 is denied access to the patient's social security number. In other embodiments, the PFM 12 may be denied or permitted access to other information.

[0041] FIG. 5 shows a user interface, specifically a trusted intermediary screen 80 in the illustrated embodiment. The trusted intermediary, in the embodiment, is a HIPAA Legal Participant (HLP). The illustrated screen 80 includes an ID information input graphical tool 82, for the input of ID information pertaining to a given patient family member (PFM) seeking access to patient information. An authorization confirmation graphical tool 84 indicates to the user whether he or she is authorized to provide a PIN to the requesting PFM. Once authorized, the PIN request graphical tool 86 becomes active, allowing the user to request a PIN for the given PFM. The issued PIN can be, for example, printed via a print graphical tool 88 and/or transmitted securely via a secure PIN transmission graphical tool 90.

[0042] A graphical tool may include, for example, an icon or button that can be activated by clicking a mouse with a curser situated over the icon or button. A graphical tool may include a form or textual input represented on a computer screen. A graphical tool may include a menu of displayed symbols or text that could be chosen by pointing to and clicking over a given symbol or text. The graphical tool can also include a drop down menu, or any other type of graphical tool. Alternatively, other tools may be provided to allow a user to control and operate any of the functions referred to in the interface shown in FIG. 5, e.g., with the use of a command line type interface.

[0043] Although portions of the foregoing have been described with reference to the HIPAA regulatory framework, systems and methods such as system 10 and method 100 may be adapted to and used with any framework that necessitates remote, distributed identity verification for access to information.

[0044] The claims, as originally presented and as they may be amended, encompass variations, alternatives, modifications, improvements, equivalents, and substantial equivalents of the embodiments and the teachings disclosed herein, including those that are presently unforeseen or unappreciated, and that, for example, may arise from applicants/patentees, and others.