Patent Application
20060004762
Not applicable.
This invention relates generally to release of patient health or medical information and more specifically to a system and method for streamlining the process of identifying and releasing health information to third parties that require access to information of specific types.
Whenever a patient meets with a doctor or has a medical/diagnostic procedure performed, one or more records are often generated that correspond to the specific appointment or procedure. While these records are generated for future use by the specific doctor and staff or health care provider associated with the meeting or procedure, these records may also be required by any of several other parties. For example, health insurance companies often need copies of records to verify that meetings/procedures have occurred and to pay out claims. As another example, when an injury leads to legal action, a lawyer may need copies of medical/health records related to a patient's health both before and after an accident occurred.
As yet one more example, where a patient uses several doctors and one or more of the doctors are not affiliated with a facility at which original records are generated, the unaffiliated doctors may nevertheless require copies of the medical records associated with the patient and controlled by the facility to provide the most informed medical advice possible. Hereinafter, unless indicated otherwise, a medical facility that controls a record will be referred to as a “record controlling entity” or an “RCE” and the phrase “third party client” or term “client” will be used to refer generally to any party that the RCE does not want to provide full access to the RCE's databases to and-that requests a record from the RCE.
In many cases current procedures and systems for maintaining medical records and obtaining medical record copies have several shortcomings. First, current record archiving processes often require a large amount of facility space. To this end, many RCEs store hard copies (i.e., paper and film) of medical records in large storage spaces, typically within RCE facilities themselves. For instance, in many cases an entire basement space within a facility is used to store catalogued paper copies of medical records.
Second, the process by which a third party client obtains record copies from an RCE often takes a long time. In this regard, in many cases when a client requires a medical record from a medical facility, the client has to provide a request for the specific record to the RCE. When an RCE receives a request, a records employee charged with managing RCE records typically performs a manual or semi-manual process to glean information from the request to determine the client's identify, the patient for which information is sought, the type of information sought and the sub-set of information sought. Next, the records employee identifies a file that should include the record including the information requested by the client and locates the file. After a record is retrieved, the employee makes copies of the portions of the record required by the client and then, pursuant to record audit guidelines adopted by many RCEs, places an entry on the record file indicating the date/time the copies were made, the third party client's identity and what section of the record was copied. The employee then replaces the hard copy record in the archive and mails or faxes the record copy to the third party client. In many cases the process above takes several days to more than a week to complete.
Third, release authorization requirements can, under certain circumstances, further prolong the record delivery process. To this end, most medical records and information are highly confidential and patients associated therewith only want the information released on an as-needed basis and, even when information is released, would prefer that only the information required by a requesting party be released. To accommodate patients and meet regulatory requirements, RCE typically enforce strict guidelines such that health/medical records cannot be released unless release has been authorized by the patient or, in some cases, a doctor or nurse (i.e., an agent) that treats the patient associated with the record. Where authorization to release has been pre-obtained, often information indicating authorization to release is placed on a file associated with a record. In these cases, when a record is retrieved by an RCE records employee, the employee confirms that release is authorized prior to making the requested copies. Where release has not been authorized, the employee may need to seek authorization prior to release thereby further slowing the record delivery process.
Fourth, because current record maintenance and retrieval processes are labor intensive and require excessive amounts of storage space, they are relatively expensive. In this regard, RCE space is relatively expensive and storing hard copies of records is costly. Moreover, while the process of retrieving and providing record copies described above may not appear too burdensome where a copy is required for a single record, in the case of a large RCE, it is not uncommon for the RCE to receive several hundreds or even thousands of record requests weekly. To process large numbers of record requests quickly, many RCEs employ a team of personnel that maintain record archives and that receive and fill record requests. Thus, many records departments struggle with the tasks required to provide records to requesting parties.
Fifth, where record retrieval, authorization verification, auditing and copying are manual, errors have been known to occur. For instance, a records employee may retrieve a record, erroneously determine that release to a specific client has been authorized and mail a copy of the record to the client. As another instance, while a client may be authorized to receive information in a record requested, the records employee may copy a wrong section of a record for mailing. As still one other instance, despite RCE audit guidelines, in some cases a records employee may forget to indicate when a copy is made and sent to a third party client or may erroneously record information regarding a copy provided to a client. Other errors are contemplated and have been know to occur.
Sixth, some times, despite a record being mailed to a recipient, circumstances result in there being a question regarding whether or not the mailed record was reviewed by the client and if the record was reviewed, by whom the record was reviewed. Here, for instance, insurance companies may refuse to pay claims when required medical records are not received by deadlines.
Seventh, in many cases only a portion of a record may be required to fulfill the needs of certain record clients. Where only a sub-set of the information on a record is required to meet a client's needs, most patients prefer that only the needed record information be released (in fact, some regulations specify that only needed information be released when requested). While this preference is understandable, determining which information on a record should be released to specific clients may be difficult and therefore require more highly trained records employees. In addition, meeting these preferences is time consuming and could lead to additional errors where records employees incorrectly determine which parts of records are required to meet client's needs.
Eighth, as with all hard copies of information, hard copies of record requests and of delivered records can be inadvertently misplaced. When a hard copy of a record request is misplaced by a records employee, often the delay that results is excessive. To this end, when a record request is misplaced, often the client will assume that the request is still being processed by the RCE and the RCE records employee may have no knowledge that the request was ever received. Similarly, when a hard copy of a record is misplaced by a client after delivery, the delivery delay is exacerbated. When a record is misplaced, often the client will assume that the request is still being processed by the RCE and the RCE records employee assumes that the request-has been filled. Misunderstandings regarding request status have been known to linger on for several weeks at a time. When a client finally recognizes that a record has been misplaced, the request process described above has to be repeated again in its entirety thereby further delaying delivery of the required record.
To deal with some of the problems described above the medical records industry has developed electronic record retention (ERR) systems where, as the label implies, patient records are stored electronically. An exemplary ERR system includes one or more servers and databases and some type of information interface (e.g. a personal computer, a laptop, hand held device (e.g., a palm computing device), etc.) where the servers, databases and interfaces are linked via a communication network. The servers run programs that help records employees identify specific records that are requested by third party clients. For instance, an exemplary program may include several fields for entering specific types of information such as patient name, dates, times, a physician's name, a specific treatment or diagnosis, etc. The servers also run programs to access specific records and to provide at least a subset of the record information to the records employee via the interface. In these cases, once a record is accessed via an interface, the employee can print out a copy of the record to be mailed or otherwise securely delivered to the client.
By storing records electronically, storage space can be reduced substantially. In addition, it is far easier and less time consuming to identify, access, review and render a copy of an electronic record than it is to perform a similar process using hard copy records.
Despite having many advantages, current ERR systems still have not addressed several of the problems described above including the archaic way in which record requests are issued and in which records are securely delivered to clients, the problems associated with misplaced requests and/or misplaced delivered records, the inability to audit when a record has been reviewed by a client that received the record, inefficiency, wasted paper, missed deadlines, human error, inaccuracy of information disclosed (wrong information, too much information, too little information), fixed information formats, information redacting problems (e.g., where information in addition to requested information exists on a record, the information may have to be blacked out, etc.
One seemingly attractive solution to issuing record requests and delivering records in a more timely fashion that could eliminate some of the problems described above would be to issue requests and deliver records via e-mail. Unfortunately, because of the sensitive nature of many patient health records, government regulations require that record requests and medical records that include information useable to identify specific patients (e.g., by name, social security umber, etc.) be distributed in a secure fashion or via a secure channel (e.g., via encryption or a point-to-point communication architecture, etc.). Because of the way in which e-mails are communicated, e-mail is not considered confidential/secure and therefore, unfortunately, e-mail cannot be used to issue requests and deliver records.
Thus, it would be advantageous to have a system whereby sensitive health records/information could be delivered to RCE clients in a secure and timely fashion. In addition, it would be advantageous to have a system that streamlines the record requesting process, the record accessing process and the process of identifying and generating parts of records that are required by specific clients. Moreover, it would be advantageous to have a system that could at least streamline the process of determining if clients are authorized to access specific records and that could generate an audit trail for all information requested and/or released.
Certain aspects commensurate in scope with the originally claimed invention are set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of certain forms the invention might take and that these aspects are not intended to limit the scope of the invention. Indeed, the invention may encompass a variety of aspects that may not be set forth below.
It has been recognized that delivery of sensitive health information can be facilitated by providing secure network channels for use by clients that require the sensitive information and posting the sensitive information for access over the secure channels. It has also been recognized that the requesting process can be streamlined in at least some cases by allowing information requests to be made over the secure channels. Moreover, it has been recognized that in at least some cases where requests are made over the secure channels, various processes can be automated for identifying the information sought, determining if the requesting client has authority to access the information sought, seeking authorization when authorization does not exist, generating releases of information (ROIs), posting the ROIs and creating access logs for each ROI that occurs.
Consistent with the above comments, according to at least one aspect of the present invention, the invention includes a method for a health care provider to release health information in an electronic format to at least one third party client where the client employs a client information interface linkable via a network to a server associated with the health care provider, the method comprising the steps of providing a secure channel on the network to link the client interface to the server, posting a subset of health information as a release of information (ROI) on the network server for access over the secure channel by the client and notifying the client that a ROI has been posted for access.
In some cases the method further includes the steps of, prior to posting, receiving a ROI request from the client requesting information associated with a specific patient and identifying an information subset at least associated with the information requested via the ROI request.
In some cases the at least one third party client includes a plurality of third party clients, each client having access to a client interface, the step of posting the ROI including providing a separate client account on the server that is accessible via the secure channel for each of the third party clients and posting the ROI for access on the client account page via the secure channel. Here, the client may generate more than one ROI request and the step of posting the ROI on the account page may include providing a list of posted ROIs for the client on the account, each list entry including a reference phrase (e.g., a hypertext phrase, a selectable icon or any other visually selectable marking) which, when selected, links the client to additional information associated with the posted ROI.
In some embodiments the step of notifying the client includes transmitting an electronic message to the client prompting the client to access the client account via the secure channel. The step of transmitting an electronic message may include transmitting an e-mail to the client. The step of transmitting an e-mail may include embedding hyperlink text in the e-mail that, when selected by the client, links the client to a log-on page for accessing the client account.
The step of notifying the client may include transmitting an electronic message (e.g., an e-mail) to the client prompting the client to access the client account via the secure channel. The step of transmitting an e-mail may include embedding a reference phrase in the e-mail that, when selected by the client, links the client to a log-on page for the for accessing the client account.
In some cases the step of transmitting an e-mail includes embedding a reference phrase in the e-mail that, when selected by the client, links the client directly to the ROI including the requested information. In some cases the step of posting includes posting the ROI for a predetermined period, the method further including the step of, after the ROI has been posted for the predetermined period, rendering the ROI inaccessible to the third party client.
The step of receiving an ROI request may include entering the ROI request via the client interface and transmitting the ROI request over the secure channel to the server. The at least one client may includes a plurality of clients, each client having access to a client interface, the step of receiving further including the steps of providing a separate client account on the server that is accessible via the secure channel for each of the third party clients and providing a ROI request window via the server on each of the client accounts that is accessible by an associated client over the secure channel via the associated client interface. The method may further include the step of providing at least one authorization window requiring a client to enter identifying information prior to accessing the client account.
In some cases the method further includes the steps of storing access information associated with each third party client having a client account maintained by the server, when a client enters identifying information, comparing the entered information with the access information, when the entered information matches access information associated with at least one of the third party clients having an account maintained by the server, providing access to the client account. Here there may be several different ROI types and each client is authorized to access at least one ROI type wherein the step of storing access information includes storing ROI types accessible by each client with client identifying information. Here, after an ROI request is entered, the step of identifying an information subset may include the information requested includes the steps of identifying an ROI type associated with the ROI request and identifying the information subset as a function of the associated ROI type.
The method further includes the step of, when an ROI request is received, storing an indication of the request in at least some embodiments. The step of storing an indication may include generating a ROI access log indicating instances of associated ROI requests. The step of storing an indication may include storing the time of the ROI request. The ROI request may indicate the identity of the client and the step of storing an indication includes storing the identity of the client. The step of storing an indication may also include storing the time at which the request was received and other information such as type of request and related data, etc.
The method may also include the step of, when a ROI is posted, storing an indication of the posting. Here, the step of storing an indication may include generating an access log indicating instances of associated posted ROIs. The step of storing an indication may include storing the time of the posting. The step of storing may also include storing the time at which the record is posted.
The method may also include, after posting the ROI, monitoring access to the posted ROI. Here, the step of monitoring may include, whenever the client accesses the posted ROI, storing an indication that the ROI was accessed. The step of storing an indication may include, for at least each ROI accessed, generating an access log indicating instances of associated ROI access. The step of storing an indication may include storing the time at which the ROI is accessed. The step of storing an indication may include storing the identity of the client that accessed the ROI. The step of storing also may include storing at least one of the time at which the ROI is accessed and the duration over which the ROI is accessed.
In at least some embodiments there are a plurality of third party clients and each client has access to a client interface and only a subset of the clients is authorized to access at least one information subset and wherein the method further includes the step of, prior to posting a ROI including information requested, determining if the client is authorized to access the ROI including the information requested. The method may further including the steps of, when a client requests an information subset that the client is not authorized to access, performing a secondary function. The step of performing a secondary function may include generating a reject notice indicating that the client is not authorized to access the requested information subset. The reject notice may indicate at least a subset of the identity of the rejected client, the time of the request and the information requested.
In at least some cases it is contemplated that at least one employee of the health care provider may have access to an employee information interface linkable to the server and the reject notice may be provided to at least one of the client via the client information interface and the at least one employee via the employee interface.
When the reject notice is provided to the employee, the method may further include the step of enabling the employee to authorize release of the information requested by the ROI request and when the employee authorizes release the information requested, posting at least a subset of information associated with the ROI request for access by the client over the secure channel via the client interface. Here, the step of enabling may include requiring the employee to indicate the source of authorization via the employee information interface and storing the source of authorization.
In some cases at least one of the patient associated with the information sought via the ROI request and an agent for the patient may have access to a patient information interface that is linkable to the server associated with the health care provider and the secondary function may include seeking authorization to release the information requested via the ROI request from the at least one of the patient and the agent via the patient interface. Here, the at least one of the patient and the agent may have a patient account maintained by the server that is accessible via the secure channel and the step of seeking authorization may include generating an electronic authorization request and posting the request to the patient account (e.g., via MyChartR software provided by Epic Systems, Inc., of Madison Wis.).
The method may further including the steps of, after seeking authorization, monitoring for a return authorization from the at least one of the patient and the agent, when a return authorization is received, storing the authorization and posting at least an information subset associated with the ROI request for access by the client over the secure channel.
At least some embodiments of the invention also include a method for a health care provider to release health information in an electronic format to third party clients where each client employs a client information interface linkable via a network to a server associated with the health care provider, the method comprising the steps of providing secure channels on the network to link the client interfaces to the server, for each client, providing a separate client account via the server accessible only over the secure channel and only by the client associated with the account for which the page is provided and for each client account, electronically posting at least a subset of information associated with the information requested by the client associated with the account as a release of information (ROI) for access over one of the secure channels.
In addition, at least some embodiments of the invention include a method for a health care provider to release health information in an electronic format to at least one third party client where the client has access to a client information interface linkable via a network to a server associated with the health care provider, the method comprising the steps of providing a secure channel on the network to link the client interface to the server, receiving a release of information (ROI) request from a third party client requesting information associated with a specific patient, identifying at least a subset of information associated with the information requested via the ROI request, placing the identified information subset in an electronic format and posting the identified information subset as a release of information (ROI) on the network for access by the client over the secure channel.
Moreover, some inventive embodiments include a method for tracking when health care information is accessed by a third party client having access to a client information interface that is linked by a network to a sever, the method comprising the steps of providing a secure channel on the network to link the client interface to the server, electronically posting a subset of health care information as a release of information (ROI) via the server for access over the secure channel, monitoring access to the posted ROI by the third party client, when the ROI is accessed by the third party client, identifying at least a subset of the time the ROI is accessed, the identity of the person accessing the ROI, the duration of access and whether or not a hard copy of the ROI is generated and storing at least a subset of the time the ROI is accessed, the identity of the person accessing the ROI, the duration of access and whether or not a hard copy of the ROI was generated as part of a ROI access log.
Furthermore, some embodiments include a method for providing notice to a patient when a health record associated therewith is requested by a third party client where the patient has access to a patient information interface that is linked to a communication network having a secure channel, the method comprising the steps of monitoring when records are requested by a client and when a record associated with a specific patient is requested by a client, transmitting a notice to the patient interface.
These and other objects, advantages and aspects of the invention will become apparent from the following description. In the description, reference is made to the accompanying drawings which form a part hereof, and in which there is shown a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention and reference is made therefore, to the claims herein for interpreting the scope of the invention.
The invention will hereafter be described with reference to the accompanying drawings, wherein like reference numerals denote like elements, and:
Several specific embodiments of the present invention are described below. It should be appreciated that in the development of any actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
In the description that follows the networked system described has been simplified in order to simplify the present explanation and it should be appreciated that far more complex systems are contemplated. For instance, the system 10 of
Referring now to the drawings wherein like reference numbers correspond to similar elements throughout the view and, more specifically, referring to
Referring still to
Matter column 44 indicates one or a subset of matters corresponding to each of the patient identification entries (e.g., 50) in column 42 where a matter is associated with a specific event or related group of events. For instance, one exemplary matter may include an office visit to a particular doctor. As another instance, a matter may include all information related to a specific accident that resulted in injury to an associated patient identified in column 42. Exemplary matters in column 44 are identified by an “M” followed by a number to distinguish one matter from another. Thus, for instance, listed matters for patient Welch include matters M-04, M-06, M-12, M-23, M-66 and M-07.
Referring still to
Referring now to
Information subset column 76, as its label implies, indicates a separate set of the information subsets (see again column 46 in
Referring once again to
To help illustrate aspects of the present invention, an exemplary record request will be assumed throughout the following specification. To this end, referring once again to
In the description that follows simplified screen shots including window views (hereinafter “windows”) are used to illustrate exemplary methods. It should be appreciated that, in at least some embodiments, it is contemplated that far more complex and detailed screen shots and windows may be provided that include many more functional icons (i.e., mouse controlled cursor selectable icons) and that the stripped down versions are provided here in order to simplify this explanation.
Referring now to
Referring also to
To search existing ROIs, the records employee fills in fields within the ROI search window 200 and then submits the search request by selecting a SUBMIT icon 216. Where the information filled into the ROI search window fields does not match an existing ROI, server 12 simply indicates that no match occurred. Where one existing ROI matches field information, server 12 provides the existing ROI including the previously filled in information. To this end, an exemplary unreleased ROI 251 including filled in information is illustrated within workspace 224 of
Referring still to
Referring still to
Referring now to
In addition to including fields for receiving entered information, various control icons are provided within workspace 224. For instance, some tool icons are provided within an ROI tool bar 222 at the top of workspace 224 including, among others, a “Change Authorization” icon 230. Herein, the term “Authorization” is used to refer to whether or not a requesting party has been authorized to receive a specific set of information being sought. Where authorization has not been stored in database 20, the phrase “Release Not Authorized” is provided in an Authorization field 260 just below ROI tool bar 228 and near the right hand edge of the workspace 251. Where the requesting party has already been authorized to receive information being sought, the status in field 260 is “Release Authorized” as illustrated in
A status field 261 is provided just below Authorization field 260 that indicates if a ROI has been released. Where the ROI has not been released, field 261 indicated “Not Released” as illustrated in
Referring still to
Referring once again to
At block 158, server 12 determines whether or not the ROI requested by the records employee has been authorized for release. At block 160, where a ROI request has not been authorized for release, control passes to block 162 where server 12 performs a secondary function. Here, in at least some cases, the secondary function may include indicating to the records employee via interface 14 that access has not been authorized. Other secondary functions are contemplated, several of which are described hereafter.
If, at block 160, access has been authorized, control loops to block 164 where server 12 identifies the release type specified via the ROI request form. Next, at block 166, server 12 assembles a record including information consistent with the ROI request. To this end, server 12 accesses release type database 70 (see again
Next, server 12 identifies the patient and matter in database table 40 that is specified in the ROI request. In the present example the patient is patient Welch (designated by number 50) and the matter is M-07 that occurred on Apr. 23, 2004. Continuing, server 12 instantiates or fills in the ROI format F5 with the information from column 46 that is associated with matter M-07 and that is specified by column 76 (see again
Here, while the un-secure e-mail cannot include patient identifying information, the e-mail may include other information that can be used to distinguish one ROI from others. For instance, the e-mail notice may identify Attorney Jones and the date that the request was submitted.
Referring now to
Consistent with the present example, after Attorney Jones successfully logs on to the ROI web portal, server 12 provides the AGM account via interface 22 used by Attorney Jones. To this end, referring to
In addition to listing the newly released ROIs, page 160 may include other mouse/cursor selectable control icons including a SEARCH icon 174, an ALL ROIs icon 175 and a NEW ROIs icon 176. SEARCH icon 174, in at least some contemplated embodiments, will be selectable to search either new or all ROIs that are posted via an account for a specific ROI. ALL ROIs icon 175 is selectable to provide a table similar to table 162 that lists all ROIs posted on an account. NEW ROIs icon 176 is selectable to provide table 162. Other functional icons are contemplated and which ones to include on an account home page is a matter of designer choice.
In at least some embodiments it is contemplated that each of the separately listed new ROIs in table 162 will be selectable to access more detailed ROI information (e.g., the requested ROI itself). For instance, in the present example, the posted new ROIs are accessed by selecting a patient's name (e.g., Welch, Michael) which is presented as a reference phrase that is visually distinguished (e.g., red or blue color) from other table 162 information and that is hyperlinked to an associated ROI.
Referring now to
According to another aspect of the present invention, when a ROI is posted for access by a requesting party on the party's account, in at least some cases, it is contemplated that it may be advantageous to restrict ROI access to a specific time period. For example, in some cases record access may be restricted to 10 days while in other cases access may be restricted to a longer period such as an entire month. Referring once again to
When icon 232 is selected, in at least some embodiments, window 270 illustrated in
Referring now to
Referring again to
In at least some embodiments it is contemplated that where an access expiration time is near and a ROI has not been accessed by a client, server 12 may be programmed to transmit supplemental e-mail to remind the requesting client that the ROI has been posted and that access will expire shortly. For instance, if an access period is 10 days and a ROI has not bee accessed by the eight day of the access period, a reminder e-mail may be sent to the requesting client. Similarly, after a posted record has expired, instead of simply eliminating the posted record, the system may provide information indicating that the record was posted and when access to the record expired. Other information may also be included with the “Expired” notice including the time the record was requested, the nature of the request and the dates during which the record was posted.
According to one other aspect of the present invention, server 12 may be programmed to maintain a ROI log for each of the ROIs requested by a third party client. To this end, various types of information associated with each request may be recorded. For example, the date and time a request is released by a records employee may be recorded. Similarly, the date and time a record is posted or released for access by a client, the date and time a ROI is accessed by a client, the person accessing a ROI, the duration of access, whether or not a ROI has been printed, etc., may all be recorded.
Referring now to
Matter column 374 identifies the matter for which log 370 is being maintained. Here, matter M-07 is identified in column 374. Column 376 lists the identity of each client that has requested any type of ROI associated with the matter in column 374. For example, in the present case, column 376 lists AGM, Amco Inc. and Bill Spec, Inc., indicating that each of three separate parties requested at least some type of ROI associated with matter M-07 in column 374.
Continuing, ROI Type column 378 indicates the type of ROI requested by each client identified in column 376. Again, consistent with the present example, the type of ROI requested by AGM is the Legal 2 type. Date/Time Requested column 380, as its label implies, lists the date and time at which a records employee submitted a request for the ROI corresponding to the matter in column 374 by the client in column 376. Similarly, Date/Time Posted column 382 indicates the date and time an ROI was posted or released for access via the account associated with the client identified in column 376.
Client Activities column 384, at its label implies, lists several types of information that provide a history of access by the client identified in column 376. To this end, exemplary column 384 indicates a date and time at which a client accessed the released ROI (e.g., May 1, 2004—4:08 p.m.), the duration over which the ROI was accessed (e.g., 22 minutes), the person who accessed the ROI (e.g., Attorney Jones) and whether or not the ROI was printed when accessed (e.g., in the present example, when the ROI was accessed on May 1, 2004, log 370 indicates that the ROI was printed). Column 384 indicates that Attorney Jones accessed the posted ROI twice, once on May 1, 2004 and a second time on May 3, 2004. Where a record has not been accessed, log 370 indicates no access by placing a NA in column 384. Thus, despite the ROI having been posted for Amco Ins. on Apr. 25, 2004, that ROI has not been accessed.
Referring now to
Referring now to
According to yet one additional aspect of the present invention, in at least some cases, it is contemplated that a requesting party may use a secure channel to request ROIs directly from server 12 thereby eliminating the need for records employees to act as intermediatories to enter ROI request information. To this end, it is contemplated that, in addition to the databases and tables described above, an access database may be included with the records database 20. To this end, an exemplary, albeit simplified, access database 350 is illustrated in
Client identification column 354 indicates each client that has been authorized to access at least some information corresponding to at least one matter associated with a patient identified in column 352. The AGM firm is identified in column 354 as being authorized to obtain at least some information corresponding to at least one matter associated with patient Welch.
Column 346 lists one or more matters for which each one of the clients in column 354 is authorized to obtain at least some information. For example, matter M-07 is identified as a matter for which the AGM firm is authorized to obtain at least some information. In some case, an “All” designation may be provided in column 346 indicating that the client associated therewith in column 354 is authorized to access at least some information corresponding to all of the matters associated with the patient identified in column 352. For example, in the illustrated database 350, Amco Ins. is authorized to obtain at least some information corresponding to all matter associated with patient Welch.
Continuing, column 348 lists one of the ROI types for each of the client and matter combinations specified by columns 354 and 346, respectively. Again, consistent with the present example, ROI type Legal 2 is specified for the combination of AGM and matter M-07 in columns 354 and 346, respectively.
Referring now to
At block 310 server 12 determines whether or not the client has a ROI account supported by server 12. Where the client does not have an account, control passes to block 312 where server 12 indicates failure to properly log-on to the system. If the client does have an account at block 310, control passes to block 314 where server 12 provides an ROI form/request entry page. To this end, referring once again to
An exemplary client ROI request window 301 is illustrated in
Referring still to
If the information sought does not exist, control passes to block 326 where server 12 provides an alternate set of instructions to the user. For example, the alternate instructions may indicate that no information is available that corresponds to the ROI request. In the alternative, the alternate instructions may indicate that the requesting party should contact a records employee working for the NFP facility to obtain the requested information. This second alternative set of instructions will, in most cases, be optimal as the instructions do not indicate whether or not the information sought exists.
When the information sought at block 324 does exist, control passes to block 328 where server 12 determines whether or not the requesting party is authorized to access the information sought. Where the party is not authorized to access the information sought, control passes to block 330 where server 12 performs a secondary function. For example, secondary function at block 330 may be to simply indicate that the client is not authorized to access the information sought. Other secondary functions 330 are contemplated and described below. Where the client is authorized to access the information sought control passes to block 332.
Referring still to block 328, a client may not be authorized to access the information sought for a variety of reasons. For instance, the client may simply not be authorized to access any information corresponding to a specific patient. As another instance, the client may be authorized to access some information corresponding to a specific patient but not associated with a specific matter. To this end, referring again to
Referring still to
According to still another aspect of the present invention, in the context of a system that allows a requesting party to directly provide a request to server 12 for an ROI, when a client is not authorized to access specific information sought, the server 12 may be programmed to provide rejected ROI requests to a records employee for further consideration. To this end, an exemplary subprocess 379 that may be substituted for the secondary function 330 in
At block 266 server 12 updates the authorization database (see again 350 in
Referring now to
Next, at block 284, server 12 monitors the patient's secure server account for authorization by the patient to release a requested ROI. To this end, although not illustrated, it is contemplated that when the patient accesses the patient's secure server account, a notice will be provided via the secure account that indicates that a specific party has requested a specific set of information corresponding to a specific matter for the patient and requesting that the patient authorize release of the information. In addition, the ROI requested may be provided for the patient to review prior to granting authorization. Here, the patient will have the option to either grant authorization to release or to deny authorization to release. Where the patient authorizes release at block 286, control passes to block 266 in
According to yet one other aspect of the invention, a record's employee or a client having access to a client interface may access audit information to confirm whether or not ROIs have been released, accessed by a requesting party, the duration of access, the accessing parties identity, whether or not the ROI was printed, etc. To this end, referring again to
Referring to
Referring again to
According to one other aspect of the present invention, a hybrid system is contemplated whereby a ROI requesting party may submit an ROI request directly to server 12 in
According to still one additional aspect of the present invention, if a ROI is mistakenly posted by a records employee, the employee can revoke access to the posted ROI thereby limiting the effect of the inadvertently released information. To this end, referring to
When icon 417 is selected, the revoke access window 479 illustrated in
Referring to
According to yet one other aspect of the present invention, clients may also be provided with the ability to revoke access to an erroneously posted ROI. In the regard, it is contemplated that most of the time the client, and not the records employee, will know if a record is erroneously posted and that the client will likely be able to determine that the record was erroneously posted prior to accessing particularly sensitive information in the ROI. For instance, if Attorney Jones requests a ROI associated with patient Welch but receives one for patient Donahue, Attorney Jones should be able to determine that an error occurred when reviewing basic ROI information such as the patient name. This, coupled with the fact that systems will likely have auditing and access tracking capabilities and that clients will likely be aware of access tracking capabilities should lead to clients revoking their own access to ROIs posted in error.
Referring to
While the invention may be susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and have been described in detail herein. However, it should be understood that the invention is not intended to be limited to the particular forms disclosed. For example, in at least some cases it is contemplated that, when an e-mail is transmitted to a requesting party indicating that an ROI has been released or posted for the party's access, a notice may be posted on a patient's server maintained account indicating that the ROI has been posted. This additional process step is identified by block 182 in
In addition, referring once again to
Moreover, while information subsets may be cobbled together prior to release and posting for access by a client, in at least some cases it is contemplated that the substantive information in the ROI may only be accessed when a client accesses the ROI. Here, while the ROI would be posted in an abbreviated form on a clients account suitable to distinguish one ROI from others no other information would be posted until the client selects the abbreviated ROI identifier. When the abbreviated identifier is selected server 12 would access the current information subsets associated therewith as well as the appropriate ROI type format and generate up to the second release. Here the advantage is that clients can obtain current information which is updated regularly.
In at least some cases it is contemplated that when an e-mail notice is sent to a client indicating that an ROI has been posted the e-mail may include reference phrases to either a log-on window for the client's account or, in some cases, directly to an associated ROI. In some cases an agent (e.g., a doctor, nurse, etc.) may act as an agent for a patient to receive authorization requests and notices of ROI via an interface.
Furthermore, while the inventive concepts are described above in the context of a system wherein a processor associated with the RCE performs most of the process steps, it should be appreciated that it is contemplated that a distributed architecture may also be used and in many cases would be preferred wherein at least some sub-processes would be performed by other than the RCE associated server. Thus, for instance, a clients interface may include at least some processing power and may run interfacing programs for entering requests and for displaying electronically posted records.
Moreover, in some embodiments it is contemplated that a RCE may not want even records employees to be able to examine at least some information in at least some records. Here, it is contemplated that when a record is requested and is retrieved by a records employee prior to electronically sending the record to the requesting party, while the employee's interface may indicate that the record has been retrieved and may provide some record information, the interface may be programmed so that sensitive information is redacted or otherwise not presented in the version of the record accessible by the records employee. In this case, while the records employee cannot access the record information, once the record is posted for access by the requester, the posted record may indicate the sensitive information despite the fact that the records employee could not review the information.
In addition, it is contemplated that the inventive system described above could include a “break the glass” concept wherein specific third party requesters could immediately access certain information when an emergency occurs. For instance, if a patient is in a life threatening accident and a physician treating the patient requires immediate access to historical data, the physician may be able to immediately obtain the historical information following identity authentication via an emergency type request.
Furthermore, while the phrase “server account page” is used above to describe the mechanism by which a client can issue a ROI request and can electronically receive posted records, it should be appreciated that the phrase is not limiting and that the present invention contemplates many different ways of electronically posting in a secure fashion for remote access. To this end, the phrase “server account page” is used to refer to any electronically accessible secure account including but not limited to an internet account, a web page or any other prime modality.
Moreover, while records are described above as being posted as essentially finished documents for electronic access, it is contemplated that posting may include posting information from which a requested record could be cobbled together when the record is ultimately accessed by a requesting party. To this end, in at least some embodiments of the invention it is contemplated that health information will be stored as information subsets as described above and, when a record is electronically posted, the act of posting will include simply providing a data construct including a record format and pointers that point to specific information in the database. Here, when the posted record is selected for access by a client, the system uses the format and the pointers to identify information required to instantiate the record and then provides the record to the client. Importantly, this embodiment allows the record content to be updated even after the posting date so that record information is most current whenever accessed by the client.
Thus, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the following appended claims.
To apprise the public of the scope of this invention, the following claims are made:
This application is related to provisional patent application No. 60/572,963 which was filed on May 20, 2004 and which has the same title as this application.
| Number | Date | Country | |
|---|---|---|---|
| 60572963 | May 2004 | US |
