Patent Issued for Electronic medical record transfer systems and methods (USPTO 11424014): United Services Automobile Association

2022 SEP 09 (NewsRx) -- By a News Reporter-Staff News Editor at Insurance Daily News -- From Alexandria, Virginia, NewsRx journalists report that a patent by the inventors Arnold, Wesley Allen (Boerne, TX, US), Belko, Michael (Boerne, TX, US), Dunlap, Steven K. (Boerne, TX, US), Haverlah, Sharon Kay (Bulverde, TX, US), filed on April 6, 2020, was published online on August 23, 2022.

The patent’s assignee for patent number 11424014 is United Services Automobile Association (San Antonio, Texas, United States).

News editors obtained the following quote from the background information supplied by the inventors: “The present disclosure relates generally to electronic medical records, and more specifically, to systems and methods for acquiring, analyzing, and/or transferring electronic medical records.

“Transfer of medical records has traditionally been complicated by a lack of interoperability among medical record systems, patient authorization, subsequent authentication, and so forth. Such transfers are complicated by time delays associated with coordinating systems, obtaining patient approval, and obtaining access via authentication. For example, authentication typically includes a person of authority governing access to medical records and permitting access for each request, which requires time and introduces delay. It is now recognized that this time delay exists irrespective of the sophistication of the electronic medical record. It is also recognized that further complications may be added by a lack of standardization in medical record content, which can create communication failures and delays.”

As a supplement to the background information on this patent, NewsRx correspondents also obtained the inventors’ summary information for this patent: “One or more specific embodiments of the present disclosure will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such 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.

“Present embodiments are generally related to an electronic medical record (EMR) system for acquiring, analyzing, and transferring EMRs. In some embodiments, the EMR system includes a software utility that may be a stand-alone application or service hosted in a server that is separately called by a request source (e.g., patient portal or electronic record source) or the EMR software utility may be wholly or partially integrated as a part of the request source. The EMR software utility may permit a user to view record content, download record content, and/or determine receivers of record content via the request source (e.g., patient portal). In some embodiments, the EMR software utility may be used during various processes (e.g., analysis of an arrangement to guarantee compensation for specified illnesses or death based on payment of a premium or compensation based on such an arrangement) involving acquisition of EMRs. Indeed, the EMR software utility may enable aggregating all EMR content for each user of the utility in a single repository. In some embodiments, the user may use the EMR software utility to retrieve and send electronic record content to other institutions (e.g., provider systems) irrespective of the format or manufacture of the receiving system. Thus, a lack of interoperability between systems may be addressed for a segment of a relevant industry (e.g., healthcare systems) that may benefit from accurate, timely, and secure records. Further, since the patient (e.g., user) is performing the request directly, no time consuming consent/authorization process is used. In some embodiments, the obtained electronic record content may be transformed by the EMR software utility into a common format for EMR data which is specific and valuable to certain entities (e.g., hospitals and healthcare payment guarantors), to reduce the time and work of extracting key information. In addition, such a format may be amenable to business rules which permit rapid and automated decision capability.

“In some embodiments, a de-identified database (e.g., a database that excludes association of personal information with certain metrics or data) may be created from the content of the EMR imported by the EMR software utility. That is, EMR content that streams through the EMR software utility may be parsed, de-identified, and stored in the database such that group health records are accessible without allowing association of the data with specific individuals. The de-identified database may enable data mining of abstracted health data that may be useful for insurers, researchers, pharmaceutical manufacturers, and others. In some embodiments, the EMR software utility may perform correlations of record content for people that share similar characteristics (e.g., demographics, age, gender, nationality, common symptoms, genealogical disorders, history of illness, etc.) to a patient (e.g., the patient using the de-identified database) and generate one or more recommendations for the patient via the patient portal. As may be appreciated, accumulating all of the records of the patient enables storing the records in a single data repository for release to provider systems at the direction of the patient (e.g., without conventional consent and authorization process). Further, at the request of the patient, the EMR patient portal may retain credentials to various vendor websites (e.g., provider systems) for a specified time and may regularly update the records of the patient (e.g., by polling the websites for updated record content). Also, outbound requests and/or consents may be timed and managed at the discretion of the patient.

“To help illustrate the manner in which the present embodiments may be used in a system, FIG. 1 is a block diagram of an embodiment of a system 10 that may be utilized to acquire, process, and transfer electronic medical records (EMRs) 12 using an EMR software utility 14. The EMR software utility 14 may enable transferring EMRs 12 from one provider system 16 to another provider system 16 or retrieving the EMRs 12 from one or more provider systems 16 and storing the EMRs 12 in a centralized data repository (e.g., database 18) to create a personalized medical record. Each provider system 16 may maintain a single secure connection with the server 22 when transferring the EMRs 12. A “personalized medical record” may refer to an aggregation of EMRs 12 for a single patient from disparate sources in a single data repository, such as database 18. The provider systems 16 may include service providers (e.g., healthcare providers, healthcare reimbursement guarantors), and the like. The database 18 may be stored locally in the memory 20 of the server 22 or remotely on another server. Further, the EMR software utility 14 may de-identify the EMRs 12 when importing the EMRs 12 into the database 18 by removing any personal identifiers (e.g., name, social security number, birth date). In some embodiments, the de-identified information may be used by the EMR software utility 14 and/or other services to perform certain data analytics to provide recommendations to a patient or healthcare professional, determine trends among similarly situated individuals, or the like.

“In some embodiments, the EMR software utility 14 may be stored on a memory 20 of a server 22 that also includes a processor 24 generally capable of storing and executing instructions to provide certain functionality described below. As noted above, the EMR software utility 14 may be a stand-alone service or application programming interface (API) that is called upon by a request source, such as a patient portal 26 and/or any suitable electronic record source 28, or the EMR software utility 14 may be wholly or partially encapsulated in the patient portal 26 or the electronic record source 28. The patient portal 26 may refer to a secure online website that provides access to patients to personal health information from anywhere with an Internet connection. An electronic record source may refer to a replication service that stores a copy of EMR content. In certain situations, the electronic record source may be called upon to provide the copy of the EMR content (e.g., when data at a service provider is corrupted). Further, the replication service may make requests to import EMR content when used by a provider system and the requests may be handled by the EMR software utility 14.”

The claims supplied by the inventors are:

“1. One or more non-transitory, computer-readable mediums storing computer instructions that, when executed by a processor, cause the processor to: receive one or more inputs from one or more request sources, wherein the one or more inputs comprise one or more user credentials to provide to an electronic medical record (EMR) source provider system; validate the one or more user credentials via communication with the EMR source provider system without an external authorization process; retrieve one or more EMRs from the EMR source provider system after the one or more user credentials are validated by the EMR source provider system; reformat the one or more EMRs into a common format to be compatible with both a receiving provider system and the EMR source provider system; store the reformatted one or more EMRs in a single data repository; receive a first set of data related to a first set of health characteristics of a user from a first device associated with the user; receive a second set of data related to a second set of health characteristics of the user from a second device associated with the user, wherein the second device is different from the first device, and wherein the first set of data is associated with a first weight and the second set of data is associated with a second weight, wherein the first weight is greater than the second weight; apply the first weight to the first set of data to generate a first weighted set of data; apply the second weight to the second set of data to generate a second weighted set of data; determine one or more correlations between the reformatted one or more EMRs, the first weighted set of data, the second weighted set of data, and a set of EMRs for similarly situated users, wherein the one or more correlations are indicative of a medical performance of the user relative to the similarly situated users; generate one or more recommendations for the user in response to the one or more correlations; and generate one or more visualizations representative of the one or more recommendations for display via an electronic display.

“2. The one or more non-transitory, computer-readable mediums of claim 1, wherein the computer instructions that cause the processor to store the reformatted one or more EMRs in the single data repository comprises de-identifying the reformatted one or more EMRs by removing personal information associated with the user.

“3. The one or more non-transitory, computer-readable mediums of claim 2, wherein the computer instructions are configured to cause the processor to: data mine health data of the one or more de-identified reformatted EMRs to determine one or more additional correlations for one or more other users sharing one or more similar characteristics to the user; and generate the one or more recommendations based on the one or more additional correlations.

“4. The one or more non-transitory, computer-readable mediums of claim 1, wherein the EMR source provider system is configured to: retain the one or more user credentials for a particular time; update the one or more EMRs with the one or more reformatted EMRs by periodically polling for updated record content from the single data repository.

“5. The one or more non-transitory, computer-readable mediums of claim 1, wherein the one or more request sources comprise a patient portal, an electronic record source, or some combination thereof.

“6. The one or more non-transitory, computer-readable mediums of claim 1, wherein the computer instructions, when executed by the processor, cause the processor to: transmit the one or more reformatted EMRs to the receiving provider system in response to an original format of the one or more EMRs being incompatible with the receiving provider system; and transmit the one or more EMRs to the receiving provider system without reformatting the retrieved EMRs in response to the original format of the one or more EMRs not being incompatible with the receiving provider system.

“7. The one or more non-transitory, computer-readable mediums of claim 1, wherein the computer instructions, when executed by the processor, cause the processor to: receive the one or more user credentials from the one or more request sources; retrieve the one or more EMRs from the EMR source provider system in response to the one or more user credentials being validated by the EMR source provider system without any separate authorization process; reformat the one or more EMRs into the common format; and store the reformatted one or more EMRs in the single data repository.

“8. The one or more non-transitory, computer-readable mediums of claim 1, wherein the first set of health characteristics comprises data measured automatically via a wearable device.

“9. The one or more non-transitory, computer-readable mediums of claim 1, wherein the second set of health characteristics comprises data measured manually via input from the user.

“10. The one or more non-transitory, computer-readable mediums of claim 1, wherein the computer instructions, when executed by the processor, cause the processor to: receive a request to retain the one or more user credentials to provide to the EMR source provider system for a specified time limit; retrieve one or more subsequent EMRs from the EMR source provider system at various time intervals throughout the specified time limit; and update a personalized medical record with the one or more subsequent EMRs.

“11. The one or more non-transitory, computer-readable mediums of claim 1, wherein the computer instructions, when executed by the processor, cause the processor to modify the first weight, the second weight, or both, based on additional data associated with the first set of data, the second set of data, or both, received from the EMR source provider system.

“12. A method, comprising: receiving one or more inputs, via a processor, from one or more request sources, wherein the one or more inputs comprise one or more user credentials to provide to an electronic medical record (EMR) source provider system and a selection of a receiving provider system, and the one or more request sources comprise a patient portal or an electronic record source; retrieving, via the processor, one or more EMRs from the EMR source provider system in response to the one or more user credentials being validated by the EMR source provider system without a separate authorization process; reformatting, via the processor, the one or more EMRs into a common format to be compatible with both the receiving provider system and the EMR source provider system; storing, via the processor, the reformatted one or more EMRs in a single data repository; transmitting, via the processor, the reformatted one or more EMRs to the receiving provider system; receiving, via the processor, a first set of data related to a first set of health characteristics from a first device associated with a user; receiving, via the processor, a second set of data related to a second set of health characteristics of the user from a second device associated with the user, wherein the second device is different from the first device, and wherein the first set of data is associated with a first weight and the second set of data is associated with a second weight, wherein the first weight is greater than the second weight; applying the first weight to the first set of data to generate a first weighted set of data and the second weight to the second set of data to generate a second weighted set of data; determining, via the processor, one or more correlations between the reformatted one or more EMRs, the first weighted set of data, the second weighted set of data, and a set of EMRs for individuals having similar properties to the user wherein the one or more correlations are indicative of a medical performance of the user relative to the individuals having similar properties to the user; generating, via the processor, one or more recommendations for the user in response to the one or more correlations; and generating, via the processor, one or more visualizations representative of the one or more recommendation for display via an electronic display.

“13. The method of claim 12, wherein the similar properties comprise a same occupation.

“14. The method of claim 12, wherein reformatting the one or more EMRs into the common format comprises parsing file forms of the one or more EMRs to be in a standard format that is accepted by the receiving provider system.

“15. The method of claim 12, comprising encrypting the one or more EMRs using a public and a private key pair in response to detecting that the one or more EMRs comprises personal identification information.

“16. The method of claim 15, wherein determining the one or more correlations comprises identifying patterns between one or more risk factors of the individuals having the similar properties to the user, behavior of the individuals having the similar properties to the user, one or more incident timings of the individuals having the similar properties to the user, or a combination thereof.

“17. The method of claim 12, comprising: determining, via the processor, that a new medication prescribed to the user should not be taken based on the one or more correlations.”

There are additional claims. Please visit full patent to read further.

For additional information on this patent, see: Arnold, Wesley Allen. Electronic medical record transfer systems and methods. U.S. Patent Number 11424014, filed April 6, 2020, and published online on August 23, 2022. Patent URL: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=11424014.PN.&OS=PN/11424014RS=PN/11424014

(Our reports deliver fact-based news of research and discoveries from around the world.)