Abstract:
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.

Description:
COPYRIGHT NOTICE 
   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. 
   FIELD OF THE DISCLOSURE 
   Aspects of the present disclosure relate to tools for secure remote access to information over Internet protocol networks. 
   BACKGROUND 
   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. 
   SUMMARY OF THE DISCLOSURE 
   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. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Embodiments will be described with reference to the following drawing figures, in which like numerals represent like items throughout the figures, and in which: 
       FIG. 1  is a block diagram of a system for remotely providing access to information according to an embodiment; 
       FIG. 2  is a flow diagram of an exemplary method by which the system of  FIG. 1  may be used to access patient medical information; 
       FIG. 3  is a block diagram of another embodiment of the system of  FIG. 1 , including a patient status database that may be accessed by family members; 
       FIG. 4  is an illustration of a client interface to the patient status database of  FIG. 3 , showing the kinds of information that might be accessed by a family member; 
       FIG. 5  shows a trusted intermediary screen. 
   

   DETAILED DESCRIPTION 
   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. 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&#39;s condition could be given. 
   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. 
   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. 
   For example, remotely located children or other relatives of a hospitalized parent may have no way of obtaining information on the parent&#39;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&#39;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. 
     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&#39;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. 
   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. 
   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. 
   As one example, assume that a person with several family members becomes ill. Furthermore, assume that some or all of the patient&#39;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. 
   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. 
   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 . 
   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 . 
   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. 
   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. 
   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 . 
   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 . 
   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. 
   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&#39;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&#39;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&#39;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. 
   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.) 
   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&#39;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 . 
   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 . 
   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 . 
   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. 
   However, a PIN might not entitle a PFM  12  to complete access to a patient&#39;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. 
   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. 
   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. 
   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&#39;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&#39;s chart. 
     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&#39;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. 
     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&#39;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&#39;s PIN expiration date and the name of the granting HLP  16  are shown. 
   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&#39;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&#39;s condition, including the diagnosis, the patient&#39;s general condition, and information on any scheduled medical procedures. As shown in  FIG. 4 , the patient&#39;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&#39;s social security number. In other embodiments, the PFM  12  may be denied or permitted access to other information. 
     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 . 
   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. 
   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. 
   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.