US20230077823A1 - System and method to access casualty health information in an emergency situation - Google Patents
System and method to access casualty health information in an emergency situation Download PDFInfo
- Publication number
- US20230077823A1 US20230077823A1 US18/051,044 US202218051044A US2023077823A1 US 20230077823 A1 US20230077823 A1 US 20230077823A1 US 202218051044 A US202218051044 A US 202218051044A US 2023077823 A1 US2023077823 A1 US 2023077823A1
- Authority
- US
- United States
- Prior art keywords
- ehr
- casualty
- provider
- identification
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000036541 health Effects 0.000 title claims abstract description 35
- 238000000034 method Methods 0.000 title claims abstract description 26
- 230000037361 pathway Effects 0.000 claims abstract description 21
- 238000004590 computer program Methods 0.000 claims abstract description 9
- 238000012384 transportation and delivery Methods 0.000 abstract description 3
- 238000011282 treatment Methods 0.000 description 7
- 230000004044 response Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000001815 facial effect Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000006378 damage Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 229940079593 drug Drugs 0.000 description 2
- 239000003814 drug Substances 0.000 description 2
- 208000014674 injury Diseases 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000000630 rising effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 206010012289 Dementia Diseases 0.000 description 1
- LFQSCWFLJHTTHZ-UHFFFAOYSA-N Ethanol Chemical compound CCO LFQSCWFLJHTTHZ-UHFFFAOYSA-N 0.000 description 1
- 208000003443 Unconsciousness Diseases 0.000 description 1
- 208000027418 Wounds and injury Diseases 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000000739 chaotic effect Effects 0.000 description 1
- 238000002405 diagnostic procedure Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 229910000078 germane Inorganic materials 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000035772 mutation Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 229910052709 silver Inorganic materials 0.000 description 1
- 239000004332 silver Substances 0.000 description 1
- 230000008733 trauma Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H70/00—ICT specially adapted for the handling or processing of medical references
- G16H70/20—ICT specially adapted for the handling or processing of medical references relating to practices or guidelines
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
Definitions
- the present invention relates to electronic health records (EHR) and, more particularly, to the determining the existence of patient EHRs for use by emergency medical services (EMS) providers.
- EHR electronic health records
- EMS emergency medical services
- EHR electronic health records
- HIPAA Health Insurance Portability and Accountability Act
- a system for automatically determining the existence of an electronic health record corresponding to an identified casualty across one or more electronic health records (EHR) providers includes a server hosting a casualty identification and EHR matching service.
- the server includes a patient identification module configured to identify a casualty based on an identification of the casualty received from a mobile computing device operated by an emergency medical services (EMS) provider.
- EMS emergency medical services
- a recognized patient messaging system (RPMS) is configured to query one or more electronic health records (EHR) service providers for the existence of a corresponding EHR belonging to the identified casualty upon receipt of the identification.
- EHR electronic health records
- the Recognized Patient Messaging System (RPMS) protocol utilizes webhooks that upon receipt of the identification, deliver data to initiate a query, or a request, to a server of the one or more EHR service providers.
- RPMS Patient Messaging System
- a database repository contains a plurality of EHR records.
- the database repository is affiliated with the one or more EHR service providers. Responsive to the one or more webhooks, the one or more servers of the EHR service providers initiate a query of the database repository to determine the existence the corresponding EHR.
- the one or more webhooks include a patient identifier corresponding to the identified casualty.
- An application program interface (API) on the server hosting the casualty identification and EHR matching service is configured to receive a POST request from the server of the one or more EHR service providers.
- the POST request provides an indication of the existence of the corresponding EHR.
- the POST request provides information to request the corresponding EHR from a custodian of the EHR.
- the POST request returns a null result.
- aspects of the invention include a computer program product stored on a non-transitory computer storage medium comprising machine-readable program code for causing, when executed, a computer to perform process steps.
- the process steps include receiving an identification of a casualty, at a first server hosting a casualty identification and electronic health record (EHR) matching service. Responsive to receiving the identification, the first server automatically queries a second server hosted by one or more electronic health record (EHR) service providers to determine the existence of a corresponding EHR matching the casualty.
- EHR electronic health record
- the automatic query may include generating one or more webhooks by the first server upon receipt of the identification.
- the one or more webhooks are distributed to the second server and include a user defined callback to communicate one or more of a push notification, a query, or a request, to the second server to determine the existence of the corresponding EHR.
- the webhook notifies a webhook listening service, set up by the EHR to query their respective databases to determine the existence the corresponding EHR.
- the process steps may also include, the EHR service sending a POST request corresponding to the first server's application program interface (API) endpoint.
- the POST request provides an indication of the existence of the corresponding EHR.
- the POST request includes relevant contact information to request the corresponding EHR from a custodian of the EHR.
- the POST request returns a null result.
- Yet other aspects of the invention include a method of automatically matching an electronic health record (EHR) to an identified casualty.
- the method includes receiving an identification of a casualty at a first server hosting a casualty identification and electronic health record (EHR) matching service.
- EHR electronic health record
- a second server hosted by one or more electronic health record (EHR) service providers are automatically queried to determine the existence of a corresponding EHR matching the casualty.
- the method automatically transmits a notification of the existence of the corresponding EHR to a mobile computing device of a medical provider treating the casualty.
- the step of automatically querying includes distributing one or more webhooks by the first server upon receipt of the identification. Via the webhook, the information is transmitted to the second server.
- the webhook broadcasts comprising a user defined callback to communicate one or more of a push notification, a query, or a request, to the second server to determine the existence of the corresponding EHR.
- Responsive to receipt of the one or more webhooks a database repository affiliated with the one or more EHR service providers is automatically queried to determine the existence the corresponding EHR.
- a POST request is received at an application program interface (API) of the first server from the second server.
- the POST request providing an indication of the existence of the corresponding EHR.
- the POST request provides contact information to request the corresponding EHR from a custodian of the EHR.
- the POST request returns a null result.
- FIG. 1 illustrates a representative system architecture for the ERInfo platform.
- FIG. 2 illustrates trust relationships of the ERInfo platform.
- FIG. 3 illustrates participating parties in the exchange of patient information within the ERInfo platform.
- FIG. 4 illustrates trust exchanges within the ERInfo platform via smart contracts.
- FIG. 5 illustrates a representation of a flow of trust within the ERInfo platform.
- FIG. 6 illustrates a recognized patient EHR query provided through the ERinfo platform.
- FIG. 7 illustrates delivery of an EHR to the requesting provider.
- FIG. 8 illustrates a diagram illustrating implementation of a Recognized Patient Messaging System (RPMS) protocol.
- RPMS Patient Messaging System
- FIG. 9 illustrates a timing and sequencing of the RPMS protocol.
- FIG. 10 illustrates a user interface for obtaining an identity of a casualty from a facial recognition module.
- FIG. 11 illustrates a schematic diagram for a representative use of the RPMS to obtain a casualty EHR information.
- ERinfo provides an improved platform with the ability to determine the existence of an EHR from one or more cooperating EHR service providers to determine the availability of an EHR for an identified patient. If relevant EHRs are found, the EHR provider can return a response indicating the location of the EHR.
- the ERinfo platform 10 may include three integral modules as part of the trust pathway, each addressing one of the needs in secure EHR access: (1) a patient identification module 20 , which may include a facial recognition module, (2) a recognized patient messaging system (RPMS) 40 , and (3) a blockchain trusted identification module 60 .
- the three modules acting in concert may allow near-instantaneous and secure access to the casualty's protected health information from the authorized medical provider's smart phone 13 , or other mobile computing device.
- the ERinfo's platform 10 may provide healthcare professionals 14 with an indication of the existence of EHRs 15 maintained by one or more EHR providers 16 , allowing access to vital records on site. First responders and emergency physicians 14 will be able to begin targeted treatment and contact relevant individuals and providers significantly faster, lessening unnecessary diagnostic tests and expenses while facilitating vital EHR 15 communication.
- the platform 10 addresses the challenge of matching an identified patient with an existing EHR 15 that may be kept by one or more EHR providers 16 .
- the ERinfo platform 10 provides a timely and secure system applicable to many contingencies, including but not limited to: a) patients who are disoriented or unresponsive due to trauma or medical emergency; b) Individuals non-compliant due to alcohol or drug overuse; c) “Silver Alerts” when patients with Alzheimer's or dementia become lost or disoriented; d) Natural disasters & mass casualties, in which high volumes of patients must be identified under high-stress, chaotic circumstances; and d) patients with low medical literacy regarding their healthcare background and risk factors.
- the recognized patient messaging system (RPMS) 40 will push queries to one or more cooperating EHR service providers 16 1 - 16 n to determine the availability of an EHR 15 for the identified patient 12 . If relevant EHRs 15 are found, the EHR provider 16 1 - 16 n will return a response indicating the location of the EHR records 15 . If relevant EHRs 15 are not found, the system 10 notifies the first responder 14 of the absence of an existing EHR so that time is not spent waiting on a result that will not be forthcoming.
- RPMS recognized patient messaging system
- the recognized patient messaging system 40 is responsible for the determination of the existence of and a location of a recognized patient's medical records 15 .
- the RPMS 40 will push a query to one or more EHR providers 16 in order to determine which EHR provider 16 1 - 16 n may have the identified patient's records in their system.
- the query may be based on relevant patient demographic information that may be captured during the matching of the presenting image to the source providing the matching identity for the patient, or patient demographic information obtained from the patient, and one or more other sources.
- the query may include: First Name, Last Name, Address, SSN, a Medical Health Insurance number, a Medical Health Record number, Date of birth, etc.
- EHR providers 16 1 - 16 n identifies the patient's information in their system, through one or more of their participating hospitals 18 , healthcare providers, clinics, and the like, they will return a response to the RPMS 40 indicating that one or more EHR records 15 are available for the identified patient 12 .
- the RPMS 40 connects ERinfo in real time to the various EHR providers 16 1 - 16 n .
- the one or more EHR providers 16 1 - 16 n may implement a listening module configured to autonomously receive the RPMS 40 push notifications.
- ERinfo 10 runs a service or services on its servers that broadcast the query containing the patient's identifying information matched to any and all EHR providers 16 1 - 16 n that are running a listening service that may be implemented using ERInfo's RPMS software development kit and proprietary APIs for the one or more EHR providers 16 .
- the third party listener can be used as well by the one or more EHR providers 16 1 - 16 n .
- the ERinfo listening service running on the one or more EHR provider 16 1 - 16 n servers may also configured to transmit a response from the one or more EHR providers 16 1 - 16 n that are responding to the query for the existence of a corresponding EHR 15 for the patient 12 within their system.
- the system may be configured to transmit the existence and location of the patient's EHR 15 to the medical provider 14 .
- RPMS ERinfo Recognized Patient Messaging System
- the RPMS protocol 42 takes advantage of one or more webhooks 44 —user defined HTTP callbacks that send out push notifications, queries, or requests via HTTP POST requests upon predetermined mutations and occurrences, such as receipt of the patient identification.
- webhooks 44 user defined HTTP callbacks that send out push notifications, queries, or requests via HTTP POST requests upon predetermined mutations and occurrences, such as receipt of the patient identification.
- the ERinfo RPMS 45 protocol is executed as follows:
- an ERinfo RPMS webhook trigger 45 is issued, announcing the request for the identified patient's information.
- the webhook 44 transmits a patient identifier 46 .
- the one or more participating EHR companies 16 1 - 16 n following the ERinfo RPMS protocol 42 will be notified of the new query.
- the one or more participating EHR companies 16 1 - 16 n will execute an internal query of their database 17 to determine if the identified patient 12 is present in their system.
- the internal query will check for the existence of patient records 15 in the one or more hospitals or providers 18 n utilizing their EHR system 16 n .
- the EHR company 16 n servers will execute an HTTP POST request 46 to an ERinfo API containing relevant information pertaining to the existence of thee record and contact information to obtain that record 15 . If an EHR 15 is not found, the HTTP Post request 46 return null result.
- the ERinfo RPMS webhook 44 may be distributed to the one or more participating EHR companies 16 1 - 16 n and integrated into their respective servers and systems accordingly.
- a webhook trigger 45 is issued by the ERInfo server 10 to the one or more EHR companies 16 1 - 16 n .
- the webhook trigger 45 includes one or more patient identifiers 46 .
- the one or more EHR companies 16 1 - 16 n execute a query of the database 17 of their participating healthcare providers 18 for one or more EHR records 15 corresponding to the one or more patient identifiers 46 .
- a return POST request 48 will contain a record locator 47 including the generic contact information, e.g. phone number to call in order, for a custodian of the EHR 15 , that will allow the first responder 14 to request access to the EHR 15 .
- the medical provider 14 has awareness of the existence and location of the patient's corresponding EHR 15 , a direct link to the patient's corresponding EHR is not provided, and the record 15 may be retrieved utilizing conventional means, in a protected manner.
- the RPMS protocol 42 doesn't convey protected health information, rather it provides the medical provider 14 awareness of the existence of the corresponding EHR for the patient 12 .
- the record locators 47 allow the medical provider 14 the ability to contact the record custodian and obtain the relevant EHR 15 .
- the ERinfo platform 10 provides for the EHR provider 16 to forward authentication and access credentials to the medical provider 14 so that the medical provider 14 can directly access the patient's protected health information 15 that is resident on one or more of the EHR provider's systems 16 via a blockchain trusted identification module (BTIM) 60 .
- BTIM blockchain trusted identification module
- the BTIM 60 establishes a consensus and a trustworthiness of the EHR provider 16 1 - 16 n and the first responder 14 , ensuring secure transfer of EHR documents 15 directly to the first responder 14 via the trust pathway 62 . Once complete, the three modules acting in concert will allow near-instantaneous and secure access of protected information from the authorized medical provider's phone.
- the Trust Pathway 62 addresses the two major hurdles to obtaining vital EHRs 15 in emergency situations by employing innovative models within the central ERinfo platform 10 : Messaging via the recognized patient messaging system 40 , and EHR 15 delivery through the BTIM 60 .
- the modules may be operated sequentially to authorize secure transmission of EHRs. 15 .
- the blockchain trusted identification module (BTIM) 60 is responsible for establishing the secure retrieval of HIPAA-protected information using a blockchain enabled trust pathway 62 .
- BTIM blockchain trusted identification module
- the patient 12 has signed a smart contract to establish a trust pathway with ERInfo 10 , and ERInfo 10 has created a smart contract with the one or more EHR providers 16 , the patient's EHR 15 can be released to the requesting provider 14 at the site of treatment.
- a trust pathway 62 with ERInfo 10 and the EHR provider 10 is executed, as illustrated in reference to FIG. 5 , enabling the release of the one or more EHRs to the requesting provider 14 .
- the trusted pathway 62 is configured so that the patients one or more EHRs 15 are delivered directly to the requesting provider 14 so that the ERInfo platform 10 need not be HIPAA compliant.
- the blockchain trusted Identification module 60 validates and automatically executes the one or more smart contracts, thereby permitting the EHR provider 16 to deliver the identified patient's EHRs 15 to the first responder or medical provider 14 .
- the one or more smart contracts may include a smart contract that a medical provider 14 enters into with ERinfo 10 when enrolling with ERinfo 10 .
- the one or more smart contracts may also include a smart contract between ERinfo 10 and the one or more EHR providers 16 .
- the EHR provider 16 may require an additional contract with each facility/organization 18 using its system, the additional contract may also be a smart contract.
- the one or more smart contracts may also include a smart contract between the patient 12 and ERinfo 10 .
- the ERinfo platform 10 uses a distributed application (DApp) to establish transitive trust through enrollment with the system 10 .
- the DApp manages separate enrollment for the patient 12 , the medical provider 14 , and the EHR service provider 16 through one or more smart contracts:
- the one or more smart contracts on a blockchain system when executed, will provide previously unauthorized first responders 14 to seamless access to the patient's EHR information 15 by the EHR service provider 16 .
- the ERinfo platform 10 creates transitive trust with the DApp managing enrollment, the Patient's smart contract for a record release can be automatically executed using ERInfo's established trust across all parties. Trust can be then be established between the EHR provider 16 and the medical provider 14 .
- the EHR provider 16 can then provide access to the patient's record 15 with trust and release the relevant information.
- ERInfo 10 When a patient 12 enrolls with ERInfo 10 , the patient 12 can provide ERinfo 10 with appropriate and legally acceptable permission, a smart contract, to retrieve their (HIPAA) protected medical information 15 . With the patient's smart contract on the blockchain, previously unauthorized first responders 14 are granted access to the patient's information 15 in the event of an emergency and execution of the patient's smart contract.
- the “trust” relationship is created by ERinfo 10 , where the patient 12 can rely on ERinfo 10 to ensure that only properly authorized medical professionals 14 and first responders 14 can access their information, and that institutions 16 , 18 that are part of ERInfo's blockchain can publish that information 15 to those digitally authenticated medical providers 14 .
- ERinfo 10 validates the enrollment using credentialing services to ensure the user holds an active professional license.
- User validation may be provided via knowledge-based authentication (KBA) or other authentication methodologies.
- KBA knowledge-based authentication
- ERinfo 10 provides a blockchain-enabled Trust Pathway 62 authorizing the exchange of HIPAA-protected records 15 . Because authorization will depend on the addition of new transactions to a distributed ledger, implementation of the system architecture is based on an established consensus between the parties involved in the transactions. This consensus can be established by a system of transitive trust conducted through members enrolled in the ERinfo service 10 .
- the system of the present invention may include at least one computer with a user interface.
- the computer may include any computer including, but not limited to, a desktop, laptop, and smart device, such as, a tablet and smart phone.
- the computer includes a program product including a machine-readable program code for causing, when executed, the computer to perform steps.
- the program product may include software which may either be loaded onto the computer or accessed by the computer.
- the loaded software may include an application on a smart device.
- the software may be accessed by the computer using a web browser.
- the computer may access the software via the web browser using the internet, extranet, intranet, host server, internet cloud and the like.
- the computer-based data processing system and method described above is for purposes of example only, and may be implemented in any type of computer system or programming or processing environment, or in a computer program, alone or in conjunction with hardware.
- the present invention may also be implemented in software stored on a non-transitory computer-readable medium and executed as a computer program on a general purpose or special purpose computer.
- a general purpose or special purpose computer For clarity, only those aspects of the system germane to the invention are described, and product details well known in the art are omitted. For the same reason, the computer hardware is not described in further detail. It should thus be understood that the invention is not limited to any specific computer language, program, or computer.
- the present invention may be run on a stand-alone computer system, or may be run from a server computer system that can be accessed by a plurality of client computer systems interconnected over an intranet network, or that is accessible to clients over the Internet.
- many embodiments of the present invention have application to a wide range of industries.
- the present application discloses a system, the method implemented by that system, as well as software stored on a computer-readable medium and executed as a computer program to perform the method on a general purpose or special purpose computer, are within the scope of the present invention.
- a system of apparatuses configured to implement the method are within the scope of the present invention.
Abstract
A system, method, and computer program product for automatically identifying a casualty and matching an electronic health record (EHR) to the casualty. A casualty identification is determined by matching a presenting image of the casualty with one of a master image or a social media profile image of the casualty. A recognized patient messaging system (RPMS) is configured to query one or more electronic health records (EHR) service providers for the existence of an EHR corresponding the identified casualty and automatically communicate the existence of the EHR to the EMS provider. A blockchain trusted identification module (BTIM) is configured to establish a trust relationship between the EMS provider and the one or more EHR service providers to establish a trusted pathway for delivery of the casualty's EHR to the EMS provider. With the casualty's EHR emergency responders can provide better care for the casualty in an emergency.
Description
- This application is a continuation of U.S. patent application Ser. No. 16/712,342, filed Dec. 12, 2019, which is a continuation-in-part application of U.S. Pat. No. 10,622,104 issued Apr. 14, 2020, which is a continuation in part application of U.S. Pat. No. 10,140,504, issued Nov. 27, 2019, each of which claim the benefit of priority to U.S. provisional application No. 62/241,232, filed Oct. 14, 2015, the contents of which are herein incorporated by reference.
- The present invention relates to electronic health records (EHR) and, more particularly, to the determining the existence of patient EHRs for use by emergency medical services (EMS) providers.
- Over one million unconscious or non-communicative patients arrive in ERs every year in the United States. Unresponsive patients pose a major hurdle for emergency first responders in need of vital information in high-stakes situations. Access to electronic health records (EHR) provides first responders with medical backgrounds, emergency contact information, and medication histories, all of which are crucial in emergency treatment. However, when the patient is unresponsive it becomes difficult or impossible to locate and obtain protected health information, or even positively identify the patient being treated.
- At present, a modern solution does not exist that allow first responders to determine the existence of a patient EHR, quickly and securely obtain protected information from EHR providers when patients are unresponsive, disoriented, or poorly versed in their medical background. Current means for obtaining this information involve slow investigation and communication with a disjoint medical record network, use of expensive and invasive biometrics, or analog tools like alert bracelets.
- As of 1996, the Health Insurance Portability and Accountability Act (HIPAA) established national standards for the transaction of EHRsi. Patients' HIPAA-protected data includes vital medical records first responders need access to at the site of emergency treatment, so a key healthcare demand entails quickly transmitting this data while maintaining patients' privacy. EHRs should be released only with the patient's permission or within the confines of law, and any information released in the context of a clinical interaction is considered confidential and must be protectedii. i Atchinson, Brian K.; Fox, Daniel M. (May-June 1997). “The Politics of The Health Insurance Portability and Accountability Act” (PDF). Health Affairs. 16 (3): 146-150. doi:10.1377/hlthaff.16.3.146.ii Rinehart-Thompson L A, Harman L B. Privacy and confidentiality. In: Harman L B, editor. Ethical Challenges in the Management of Health Information. 2nd ed Sudbury, Mass.: Jones and Bartlett: 2006. p. 53.
- Healthcare facilities require access to this data if EHRs are to function as intended, and the key to preserving their confidentiality is to allow only authorized individuals to access this data. This requires that any relevant parties be pre-authorized to access the information based on established role-based privileges. Any user given access will be held accountable for use and misuse of the information they view, so properly assigning and validating user privileges comprises a major aspect of medical record securityiiii. iii American Health Information Management Association. The 10 security domains (updated) J Am Health Inf Management Assoc. 2012; 83:50.
- Maintaining secure records has proven a rising challenge in multiple domains as increasing amounts of consumer data have become available. A 2014 report on medical identify theft in the United States suggests that incidences of data breaches are rising, with 2.32 million victims reported in 2014, a 21.7% increase from the previous yeariv. Cloud storage, encryption, and basic password protection are vital aspects of ensuring EHRs remain secure. However, a 2011 survey found 73% of physicians confessed to texting other physicians about their work, and many healthcare professionals regularly access or discuss these records from personal mobile devicesv. Modern devices are easily misplaced, stolen, or wrongly accessed, so modern EHR transmission and storage protocols must highlight the use of encryption and proper validation. iv Ponemon Institute LLC. Fifth annual study on medical identity theft. Sponsored by the Medical Identity Fraud Alliance with support from: Kaiser Permanente, ID Experts, Experian Data Breach Resolution and Identity Finder, LLC. Traverse City (MI): Ponemon Institute LLC; 2015 February. 38 pv HHS steps up HIPAA audits. Greene AHJ AHIMA. 2011 October; 82(10):58-9
- Likewise, because medical records play crucial roles in informing treatment, steps must be taken to ensure that EHRs are accurate and unchanged following transmission. Loss or destruction of data during transfer will raise concerns about the usability of data, making them unfit as a basis for making care decisionsvi. Alterations to a patient's medical records may cause them to be billed for services they did not receive, misinform their caretakers, or lead them to receive unnecessary or dangerous treatments. vi North Carolina Healthcare Information and Communications Alliance, Inc. The benefits and risks of electronic health records
- As can be seen, there is a need for a generalized and globally accessible system and method for (1) identifying a potentially unresponsive patient in an emergency setting, (2) locating that patient's EHRs in an unstandardized, byzantine record system, and (3) securely transmitting HIPAA-protected records from the EHR provider to the first responder at the site of treatment. improving the identification of a casualty at an injury or incident site, or on presenting at an Emergency services health care facility on an initial encounter with that facility.
- In some aspects of the invention, a system for automatically determining the existence of an electronic health record corresponding to an identified casualty across one or more electronic health records (EHR) providers is disclosed. The system includes a server hosting a casualty identification and EHR matching service. The server includes a patient identification module configured to identify a casualty based on an identification of the casualty received from a mobile computing device operated by an emergency medical services (EMS) provider. A recognized patient messaging system (RPMS) is configured to query one or more electronic health records (EHR) service providers for the existence of a corresponding EHR belonging to the identified casualty upon receipt of the identification.
- The Recognized Patient Messaging System (RPMS) protocol utilizes webhooks that upon receipt of the identification, deliver data to initiate a query, or a request, to a server of the one or more EHR service providers.
- A database repository contains a plurality of EHR records. The database repository is affiliated with the one or more EHR service providers. Responsive to the one or more webhooks, the one or more servers of the EHR service providers initiate a query of the database repository to determine the existence the corresponding EHR. The one or more webhooks include a patient identifier corresponding to the identified casualty.
- An application program interface (API) on the server hosting the casualty identification and EHR matching service is configured to receive a POST request from the server of the one or more EHR service providers. The POST request provides an indication of the existence of the corresponding EHR. When a corresponding EHR exists, the POST request provides information to request the corresponding EHR from a custodian of the EHR. When a corresponding EHR does not exist, the POST request returns a null result.
- Other aspects of the invention include a computer program product stored on a non-transitory computer storage medium comprising machine-readable program code for causing, when executed, a computer to perform process steps. The process steps include receiving an identification of a casualty, at a first server hosting a casualty identification and electronic health record (EHR) matching service. Responsive to receiving the identification, the first server automatically queries a second server hosted by one or more electronic health record (EHR) service providers to determine the existence of a corresponding EHR matching the casualty.
- The automatic query may include generating one or more webhooks by the first server upon receipt of the identification. The one or more webhooks are distributed to the second server and include a user defined callback to communicate one or more of a push notification, a query, or a request, to the second server to determine the existence of the corresponding EHR. The webhook notifies a webhook listening service, set up by the EHR to query their respective databases to determine the existence the corresponding EHR.
- The process steps may also include, the EHR service sending a POST request corresponding to the first server's application program interface (API) endpoint. The POST request provides an indication of the existence of the corresponding EHR. When a corresponding EHR exists, the POST request includes relevant contact information to request the corresponding EHR from a custodian of the EHR. When a corresponding EHR does not exist, the POST request returns a null result.
- Yet other aspects of the invention include a method of automatically matching an electronic health record (EHR) to an identified casualty. The method includes receiving an identification of a casualty at a first server hosting a casualty identification and electronic health record (EHR) matching service. Upon receipt of the identification, a second server hosted by one or more electronic health record (EHR) service providers are automatically queried to determine the existence of a corresponding EHR matching the casualty. When the corresponding EHR is located, the method automatically transmits a notification of the existence of the corresponding EHR to a mobile computing device of a medical provider treating the casualty.
- In some embodiments, the step of automatically querying includes distributing one or more webhooks by the first server upon receipt of the identification. Via the webhook, the information is transmitted to the second server. The webhook broadcasts comprising a user defined callback to communicate one or more of a push notification, a query, or a request, to the second server to determine the existence of the corresponding EHR. Responsive to receipt of the one or more webhooks, a database repository affiliated with the one or more EHR service providers is automatically queried to determine the existence the corresponding EHR.
- In some embodiments of the method, a POST request is received at an application program interface (API) of the first server from the second server. The POST request providing an indication of the existence of the corresponding EHR. When a corresponding EHR exists, the POST request provides contact information to request the corresponding EHR from a custodian of the EHR. When the corresponding EHR does not exist, the POST request returns a null result.
- These and other features, aspects and advantages of the present invention will become better understood with reference to the following drawings, description and claims.
-
FIG. 1 illustrates a representative system architecture for the ERInfo platform. -
FIG. 2 illustrates trust relationships of the ERInfo platform. -
FIG. 3 illustrates participating parties in the exchange of patient information within the ERInfo platform. -
FIG. 4 illustrates trust exchanges within the ERInfo platform via smart contracts. -
FIG. 5 illustrates a representation of a flow of trust within the ERInfo platform. -
FIG. 6 illustrates a recognized patient EHR query provided through the ERinfo platform. -
FIG. 7 illustrates delivery of an EHR to the requesting provider. -
FIG. 8 illustrates a diagram illustrating implementation of a Recognized Patient Messaging System (RPMS) protocol. -
FIG. 9 illustrates a timing and sequencing of the RPMS protocol. -
FIG. 10 illustrates a user interface for obtaining an identity of a casualty from a facial recognition module. -
FIG. 11 illustrates a schematic diagram for a representative use of the RPMS to obtain a casualty EHR information. - The following detailed description is of the best currently contemplated modes of carrying out exemplary embodiments of the invention. The description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of the invention, since the scope of the invention is best defined by the appended claims.
- Broadly, embodiments of the present invention, hereinafter ERinfo, provides an improved platform with the ability to determine the existence of an EHR from one or more cooperating EHR service providers to determine the availability of an EHR for an identified patient. If relevant EHRs are found, the EHR provider can return a response indicating the location of the EHR.
- As seen in reference to
FIG. 1 , theERinfo platform 10 may include three integral modules as part of the trust pathway, each addressing one of the needs in secure EHR access: (1) apatient identification module 20, which may include a facial recognition module, (2) a recognized patient messaging system (RPMS) 40, and (3) a blockchain trustedidentification module 60. The three modules acting in concert may allow near-instantaneous and secure access to the casualty's protected health information from the authorized medical provider'ssmart phone 13, or other mobile computing device. - Once a casualty's identity has been determined, the ERinfo's
platform 10 may providehealthcare professionals 14 with an indication of the existence ofEHRs 15 maintained by one ormore EHR providers 16, allowing access to vital records on site. First responders andemergency physicians 14 will be able to begin targeted treatment and contact relevant individuals and providers significantly faster, lessening unnecessary diagnostic tests and expenses while facilitatingvital EHR 15 communication. Theplatform 10 addresses the challenge of matching an identified patient with an existingEHR 15 that may be kept by one ormore EHR providers 16. - The
ERinfo platform 10 provides a timely and secure system applicable to many contingencies, including but not limited to: a) patients who are disoriented or unresponsive due to trauma or medical emergency; b) Individuals non-compliant due to alcohol or drug overuse; c) “Silver Alerts” when patients with Alzheimer's or dementia become lost or disoriented; d) Natural disasters & mass casualties, in which high volumes of patients must be identified under high-stress, chaotic circumstances; and d) patients with low medical literacy regarding their healthcare background and risk factors. - As seen in reference to
FIG. 1 , once a patient 12 has been identified, the recognized patient messaging system (RPMS) 40 will push queries to one or more cooperating EHR service providers 16 1-16 n to determine the availability of anEHR 15 for the identifiedpatient 12. Ifrelevant EHRs 15 are found, the EHR provider 16 1-16 n will return a response indicating the location of the EHR records 15. Ifrelevant EHRs 15 are not found, thesystem 10 notifies thefirst responder 14 of the absence of an existing EHR so that time is not spent waiting on a result that will not be forthcoming. - The recognized patient messaging system 40 (RPMS) is responsible for the determination of the existence of and a location of a recognized patient's
medical records 15. Once a patient has been identified by the presenting image or any other identification means, the RPMS 40 will push a query to one ormore EHR providers 16 in order to determine which EHR provider 16 1-16 n may have the identified patient's records in their system. The query may be based on relevant patient demographic information that may be captured during the matching of the presenting image to the source providing the matching identity for the patient, or patient demographic information obtained from the patient, and one or more other sources. By way of non-limiting example, the query may include: First Name, Last Name, Address, SSN, a Medical Health Insurance number, a Medical Health Record number, Date of birth, etc. - If one of the EHR providers 16 1-16 n identifies the patient's information in their system, through one or more of their participating
hospitals 18, healthcare providers, clinics, and the like, they will return a response to the RPMS 40 indicating that one ormore EHR records 15 are available for the identifiedpatient 12. - The RPMS 40 connects ERinfo in real time to the various EHR providers 16 1-16 n. In some embodiments, the one or more EHR providers 16 1-16 n may implement a listening module configured to autonomously receive the RPMS 40 push notifications.
-
ERinfo 10 runs a service or services on its servers that broadcast the query containing the patient's identifying information matched to any and all EHR providers 16 1-16 n that are running a listening service that may be implemented using ERInfo's RPMS software development kit and proprietary APIs for the one ormore EHR providers 16. In the alternative, should a third party listener be made available that can accept broadcast messages from ERinfo's RPMS 40, the third party listener can be used as well by the one or more EHR providers 16 1-16 n. - The ERinfo listening service running on the one or more EHR provider 16 1-16 n servers may also configured to transmit a response from the one or more EHR providers 16 1-16 n that are responding to the query for the existence of a corresponding
EHR 15 for thepatient 12 within their system. When theERinfo platform 10 receives a response, the system may be configured to transmit the existence and location of the patient'sEHR 15 to themedical provider 14. - In a preferred embodiment, communication between the RPMS 40 and EHR companies 16 1-16 n is executed utilizing an ERinfo Recognized Patient Messaging System (RPMS)
protocol 42. TheRPMS protocol 42 takes advantage of one or more webhooks 44—user defined HTTP callbacks that send out push notifications, queries, or requests via HTTP POST requests upon predetermined mutations and occurrences, such as receipt of the patient identification. As seen in reference toFIGS. 8 and 9 , utilizing these in combination with one or more API calls, theERinfo RPMS 45 protocol is executed as follows: - Upon recognition of a
patient 12, whether through the facial recognition query, or otherwise, an ERinfo RPMS webhook trigger 45 is issued, announcing the request for the identified patient's information. Thewebhook 44 transmits a patient identifier 46. The one or more participating EHR companies 16 1-16 n following theERinfo RPMS protocol 42 will be notified of the new query. The one or more participating EHR companies 16 1-16 n will execute an internal query of theirdatabase 17 to determine if the identifiedpatient 12 is present in their system. The internal query will check for the existence ofpatient records 15 in the one or more hospitals orproviders 18 n utilizing theirEHR system 16 n. If anEHR 15 corresponding to the identifiedpatient 12 is found, theEHR company 16 n servers will execute an HTTP POST request 46 to an ERinfo API containing relevant information pertaining to the existence of thee record and contact information to obtain thatrecord 15. If anEHR 15 is not found, the HTTP Post request 46 return null result. - As seen in reference to
FIG. 9 , a timeline of theERinfo RPMS protocol 42 and its location in the ERinfo identification protocol 40 is demonstrated inFIG. 3 . The ERinfo RPMS webhook 44 may be distributed to the one or more participating EHR companies 16 1-16 n and integrated into their respective servers and systems accordingly. - Upon determining a casualty identity, a
webhook trigger 45 is issued by theERInfo server 10 to the one or more EHR companies 16 1-16 n. Thewebhook trigger 45 includes one or more patient identifiers 46. Responsive to thetrigger 45, the one or more EHR companies 16 1-16 n execute a query of thedatabase 17 of their participatinghealthcare providers 18 for one ormore EHR records 15 corresponding to the one or more patient identifiers 46. - Upon completion of the query, the servers of the one or more EHR companies 16 1-16 n transmit a response to
ERInfo 10. A return POST request 48 will contain a record locator 47 including the generic contact information, e.g. phone number to call in order, for a custodian of theEHR 15, that will allow thefirst responder 14 to request access to theEHR 15. In this instance, while themedical provider 14 has awareness of the existence and location of the patient'scorresponding EHR 15, a direct link to the patient's corresponding EHR is not provided, and therecord 15 may be retrieved utilizing conventional means, in a protected manner. - As will be appreciated, the
RPMS protocol 42 doesn't convey protected health information, rather it provides themedical provider 14 awareness of the existence of the corresponding EHR for thepatient 12. The record locators 47 allow themedical provider 14 the ability to contact the record custodian and obtain therelevant EHR 15. - In the event the
medical provider 14,patient 12, andEHR provider 16 are all participants of the same private ledger blockchain trust, theERinfo platform 10 provides for theEHR provider 16 to forward authentication and access credentials to themedical provider 14 so that themedical provider 14 can directly access the patient's protectedhealth information 15 that is resident on one or more of the EHR provider'ssystems 16 via a blockchain trusted identification module (BTIM) 60. - The
BTIM 60 establishes a consensus and a trustworthiness of the EHR provider 16 1-16 n and thefirst responder 14, ensuring secure transfer ofEHR documents 15 directly to thefirst responder 14 via thetrust pathway 62. Once complete, the three modules acting in concert will allow near-instantaneous and secure access of protected information from the authorized medical provider's phone. - The
Trust Pathway 62 addresses the two major hurdles to obtainingvital EHRs 15 in emergency situations by employing innovative models within the central ERinfo platform 10: Messaging via the recognized patient messaging system 40, andEHR 15 delivery through theBTIM 60. The modules may be operated sequentially to authorize secure transmission of EHRs. 15. - When the RPMS 40 receives the notification, the blockchain trusted identification module (BTIM) 60 is responsible for establishing the secure retrieval of HIPAA-protected information using a blockchain enabled
trust pathway 62. As seen in reference toFIG. 3 , all parties involved, includingfirst responders 14,EHR service providers 16, andpatients 12 who have opted into ERInfo functionality, will execute a smart contract withERInfo 10 establishing a consensus on accessibility and sharing of theEHR 15 and other vital patient information. For an enrolledpatient 12, as seen in reference toFIG. 4 , because thepatient 12 has signed a smart contract to establish a trust pathway withERInfo 10, andERInfo 10 has created a smart contract with the one ormore EHR providers 16, the patient'sEHR 15 can be released to the requestingprovider 14 at the site of treatment. - In the case of a
non-enrolled patient 12, when theprovider 14 verifies an emergency condition exemption, atrust pathway 62 withERInfo 10 and theEHR provider 10 is executed, as illustrated in reference toFIG. 5 , enabling the release of the one or more EHRs to the requestingprovider 14. In either case, the trustedpathway 62 is configured so that the patients one ormore EHRs 15 are delivered directly to the requestingprovider 14 so that theERInfo platform 10 need not be HIPAA compliant. - Using the blockchain-protected system in which a plurality of participants are consensus providers ensures that no single party can serve as a vulnerable endpoint for accessing sensitive patient information; there must be consensus among all members of the decentralized ledger to verify a
valid EHR 15 request. This ensures that only actively licensed (and authorized through ERInfo platform 10)providers 14 can access the system, and that a security breach of theERInfo database 30 itself does not allow intruder access to HIPAA data ofpatients 12 who have opted in. - Once the patient has been recognized and their EHRs located, the blockchain trusted
Identification module 60 validates and automatically executes the one or more smart contracts, thereby permitting theEHR provider 16 to deliver the identified patient'sEHRs 15 to the first responder ormedical provider 14. The one or more smart contracts may include a smart contract that amedical provider 14 enters into withERinfo 10 when enrolling withERinfo 10. The one or more smart contracts may also include a smart contract betweenERinfo 10 and the one ormore EHR providers 16. In turn, theEHR provider 16 may require an additional contract with each facility/organization 18 using its system, the additional contract may also be a smart contract. The one or more smart contracts may also include a smart contract between the patient 12 andERinfo 10. - The
ERinfo platform 10 uses a distributed application (DApp) to establish transitive trust through enrollment with thesystem 10. The DApp manages separate enrollment for the patient 12, themedical provider 14, and theEHR service provider 16 through one or more smart contracts: When anEHR service provider 16 is enrolled, the one or more smart contracts on a blockchain system, when executed, will provide previously unauthorizedfirst responders 14 to seamless access to the patient'sEHR information 15 by theEHR service provider 16. TheERinfo platform 10 creates transitive trust with the DApp managing enrollment, the Patient's smart contract for a record release can be automatically executed using ERInfo's established trust across all parties. Trust can be then be established between theEHR provider 16 and themedical provider 14. TheEHR provider 16 can then provide access to the patient'srecord 15 with trust and release the relevant information. - Patient Enrollment. When a
patient 12 enrolls withERInfo 10, the patient 12 can provideERinfo 10 with appropriate and legally acceptable permission, a smart contract, to retrieve their (HIPAA) protectedmedical information 15. With the patient's smart contract on the blockchain, previously unauthorizedfirst responders 14 are granted access to the patient'sinformation 15 in the event of an emergency and execution of the patient's smart contract. - The “trust” relationship is created by
ERinfo 10, where the patient 12 can rely onERinfo 10 to ensure that only properly authorizedmedical professionals 14 andfirst responders 14 can access their information, and thatinstitutions information 15 to those digitally authenticatedmedical providers 14. - Medical Provider Enrollment. When a
medical provider 14 enrolls as an ERinfo provider,ERinfo 10 validates the enrollment using credentialing services to ensure the user holds an active professional license. User validation may be provided via knowledge-based authentication (KBA) or other authentication methodologies. - Thus,
ERinfo 10 provides a blockchain-enabledTrust Pathway 62 authorizing the exchange of HIPAA-protectedrecords 15. Because authorization will depend on the addition of new transactions to a distributed ledger, implementation of the system architecture is based on an established consensus between the parties involved in the transactions. This consensus can be established by a system of transitive trust conducted through members enrolled in theERinfo service 10. - The system of the present invention may include at least one computer with a user interface. The computer may include any computer including, but not limited to, a desktop, laptop, and smart device, such as, a tablet and smart phone. The computer includes a program product including a machine-readable program code for causing, when executed, the computer to perform steps. The program product may include software which may either be loaded onto the computer or accessed by the computer. The loaded software may include an application on a smart device. The software may be accessed by the computer using a web browser. The computer may access the software via the web browser using the internet, extranet, intranet, host server, internet cloud and the like.
- The computer-based data processing system and method described above is for purposes of example only, and may be implemented in any type of computer system or programming or processing environment, or in a computer program, alone or in conjunction with hardware. The present invention may also be implemented in software stored on a non-transitory computer-readable medium and executed as a computer program on a general purpose or special purpose computer. For clarity, only those aspects of the system germane to the invention are described, and product details well known in the art are omitted. For the same reason, the computer hardware is not described in further detail. It should thus be understood that the invention is not limited to any specific computer language, program, or computer. It is further contemplated that the present invention may be run on a stand-alone computer system, or may be run from a server computer system that can be accessed by a plurality of client computer systems interconnected over an intranet network, or that is accessible to clients over the Internet. In addition, many embodiments of the present invention have application to a wide range of industries. To the extent the present application discloses a system, the method implemented by that system, as well as software stored on a computer-readable medium and executed as a computer program to perform the method on a general purpose or special purpose computer, are within the scope of the present invention. Further, to the extent the present application discloses a method, a system of apparatuses configured to implement the method are within the scope of the present invention.
- It should be understood, of course, that the foregoing relates to exemplary embodiments of the invention and that modifications may be made without departing from the spirit and scope of the invention as set forth in the following claims.
Claims (19)
1. A system for automatically determining an existence of an electronic health record corresponding to an identified casualty across one or more electronic health records (EHR) providers, comprising:
a server hosting a casualty identification and EHR matching service, the server comprising:
a patient identification module configured to identify a casualty based on an identification of the casualty received from a mobile computing device operated by an emergency medical service (EMS) provider;
a recognized patient messaging system (RPMS) configured to query one or more electronic health records (EHR) service providers for the existence of a corresponding EHR belonging to the identified casualty upon receipt of the identification; and
a blockchain trusted identification module (BTIM) configured to establish a consensus between the identified casualty, the one or more EHR service providers, and the EMS provider.
2. The system of claim 1 , wherein the consensus comprises:
a first blockchain trust contract between the identified casualty and the casualty identification and EHR matching service; and
a second blockchain trust contract between the one or more EHR service providers and the casualty identification and EHR matching service.
3. The system of claim 2 , further comprising:
a blockchain enabled trust pathway established directly between the one or more EHR service providers and the mobile computing device of the EMS provider when the consensus of the identified casualty, the one or more EHR service providers, and the EMS provider are established.
4. The system of claim 3 , wherein the blockchain enabled trust pathway is configured to transmit the corresponding EHR from the one or more EHR service providers to the mobile computing device of the EMS provider.
5. The system of claim 1 , wherein the consensus comprises:
an emergency condition exemption received from the EMS provider.
6. The system of claim 5 , further comprising:
a blockchain enabled trust pathway established between the EHR service provider, the casualty identification and EHR matching service, and the mobile computing device of the EMS provider.
7. The system of claim 6 , wherein the blockchain enabled trust pathway is configured to transmit the corresponding EHR from the one or more EHR service providers to the mobile computing device of the EMS provider.
8. The system of claim 1 , wherein the RPMS is configured to utilize a webhook, that, upon receipt of the identification, pushes a notification to the one or more EHR service providers, broadcasting a user defined callback to communicate one or more of a push notification, a query, or a request, to a server of the one or more EHR service providers.
9. The system of claim 8 , further comprising:
a database repository containing a plurality of EHR records, the database repository affiliated with the one or more EHR service providers; and
responsive to the webhook, the one or more servers of the EHR service providers initiate a query of the database repository to determine the existence the corresponding EHR.
10. The system of claim 9 , wherein the webhook broadcasts a patient identifier corresponding to the identified casualty.
11. The system of claim 1 , further comprising:
an application program interface (API) on the server hosting the casualty identification and EHR matching service configured to receive a POST request from the server of the one or more EHR service providers, the POST request providing an indication of the existence of the corresponding EHR, wherein
when a corresponding EHR exists, the POST request provides information to request the corresponding EHR from a custodian of the EHR; and
when a corresponding EHR does not exist, the POST request returns a null result.
12. A computer program product stored on a non-transitory computer storage medium comprising machine-readable program code for causing, when executed, a computer to perform the following process steps:
receiving an identification of a casualty, at a first server hosting a casualty identification and electronic health record (EHR) matching service;
automatically querying a second server hosted by one or more electronic health record (EHR) service providers to determine an existence of a corresponding EHR matching the casualty; and
determining, via a blockchain trusted identification module (BTIM), a consensus between the casualty, an emergency medical services (EMS) provider, and the one or more EHR service providers.
13. The computer program product of claim 12 , the process steps further comprising:
establishing a blockchain enabled trust pathway between the one or more EHR service providers and the EMS provider when the consensus is established.
14. The computer program product of claim 13 , the process steps further comprising:
transmitting the corresponding EHR from the one or more EHR service providers to the EMS provider via the blockchain enabled trust pathway.
15. The computer program product of claim 14 , the process steps further comprising:
when the consensus comprises:
a first blockchain trust contract between the casualty and the casualty identification and EHR matching service; and
a second blockchain trust contract between the one or more EHR service providers and the casualty identification and EHR matching service;
establishing the blockchain enabled trust pathway directly between the EHR service provider and the EMS provider; and
when the consensus comprises:
an emergency condition exemption received from the EMS provider,
establishing the blockchain enabled trust pathway between the EHR service provider, the casualty identification and EHR matching service, and the EMS provider.
16. A method of automatically matching an electronic health record (EHR) to an identified casualty, comprising:
receiving an identification of a casualty, at a first server hosting a casualty identification and electronic health record (EHR) matching service;
automatically querying a second server hosted by one or more electronic health record (EHR) service providers to determine an existence of a corresponding EHR matching the casualty; and
determining, via a blockchain trusted identification module (BTIM), a consensus between the casualty, an emergency medical services (EMS) provider, and the one or more EHR service providers.
17. The method of claim 16 , the process steps further comprising:
establishing a blockchain enabled trust pathway between the one or more EHR service providers and a mobile computing device of the EMS provider when the consensus is established.
18. The method of claim 17 , further comprising:
transmitting the corresponding EHR from the one or more EHR service providers to the mobile computing device of the EMS provider via the blockchain enabled trust pathway.
19. The method of claim 17 , the process steps further comprising:
when the consensus comprises:
a first blockchain trust contract between the casualty and the casualty identification and EHR matching service; and
a second blockchain trust contract between the one or more EHR service providers and the casualty identification and EHR matching service;
establishing the blockchain enabled trust pathway directly between the EHR service provider and the EMS provider; and
when the consensus comprises:
an emergency condition exemption received from the EMS provider,
establishing the blockchain enabled trust pathway between the EHR service provider, the casualty identification and EHR matching service, and the mobile computing device of the EMS provider.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/051,044 US20230077823A1 (en) | 2015-10-14 | 2022-10-31 | System and method to access casualty health information in an emergency situation |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562241232P | 2015-10-14 | 2015-10-14 | |
US15/293,886 US10140504B2 (en) | 2015-10-14 | 2016-10-14 | System and method utilizing facial recognition with online (social) network to access casualty health information in an emergency situation |
US16/151,987 US10622104B2 (en) | 2015-10-14 | 2018-10-04 | System and method utilizing facial recognition with online (social) network to access casualty health information in an emergency situation |
US16/712,342 US11501861B2 (en) | 2015-10-14 | 2019-12-12 | System and method to access casualty health information in an emergency situation |
US18/051,044 US20230077823A1 (en) | 2015-10-14 | 2022-10-31 | System and method to access casualty health information in an emergency situation |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/712,342 Continuation US11501861B2 (en) | 2015-10-14 | 2019-12-12 | System and method to access casualty health information in an emergency situation |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230077823A1 true US20230077823A1 (en) | 2023-03-16 |
Family
ID=70161556
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/712,342 Active US11501861B2 (en) | 2015-10-14 | 2019-12-12 | System and method to access casualty health information in an emergency situation |
US18/051,044 Pending US20230077823A1 (en) | 2015-10-14 | 2022-10-31 | System and method to access casualty health information in an emergency situation |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/712,342 Active US11501861B2 (en) | 2015-10-14 | 2019-12-12 | System and method to access casualty health information in an emergency situation |
Country Status (1)
Country | Link |
---|---|
US (2) | US11501861B2 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11621076B2 (en) * | 2018-05-24 | 2023-04-04 | Snout, Inc. | Machine learning system and method for pet health records |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
BR9509357A (en) * | 1994-10-28 | 1997-12-30 | Advanced Health Med E Systems | Prescription management system implemented in a computer prescription combination formed by a central computer installation in a prescription management system packaging, dosage indication device and product specification system for professional use |
US20130035581A1 (en) * | 2011-08-05 | 2013-02-07 | General Electric Company | Augmented reality enhanced triage systems and methods for emergency medical services |
US20130060579A1 (en) * | 2007-10-30 | 2013-03-07 | Onemednet Corporation | Methods, systems, and devices for managing medical images and records |
US20160321636A1 (en) * | 2015-05-01 | 2016-11-03 | SwipeOut, Inc. | Receiving card-present payments for e-commerce orders on behalf of merchants |
-
2019
- 2019-12-12 US US16/712,342 patent/US11501861B2/en active Active
-
2022
- 2022-10-31 US US18/051,044 patent/US20230077823A1/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
BR9509357A (en) * | 1994-10-28 | 1997-12-30 | Advanced Health Med E Systems | Prescription management system implemented in a computer prescription combination formed by a central computer installation in a prescription management system packaging, dosage indication device and product specification system for professional use |
US20130060579A1 (en) * | 2007-10-30 | 2013-03-07 | Onemednet Corporation | Methods, systems, and devices for managing medical images and records |
US20130035581A1 (en) * | 2011-08-05 | 2013-02-07 | General Electric Company | Augmented reality enhanced triage systems and methods for emergency medical services |
US20160321636A1 (en) * | 2015-05-01 | 2016-11-03 | SwipeOut, Inc. | Receiving card-present payments for e-commerce orders on behalf of merchants |
Non-Patent Citations (2)
Title |
---|
Machine translation for BR 9509357 (Year: 1997) * |
Swanson, "Consensus-as-a-service: a brief report on the emergence of permissioned, distributed ledger systems" (Year: 2015) * |
Also Published As
Publication number | Publication date |
---|---|
US11501861B2 (en) | 2022-11-15 |
US20200118657A1 (en) | 2020-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11657176B2 (en) | Blockchain-based mechanisms for secure health information resource exchange | |
US11907397B2 (en) | Records access and management | |
US11025419B2 (en) | System for digital identity authentication and methods of use | |
US10789373B2 (en) | System and method for securely storing and sharing information | |
US9973484B2 (en) | System and method for securely storing and sharing information | |
US11818251B2 (en) | System and method for securely storing and sharing information | |
US10887098B2 (en) | System for digital identity authentication and methods of use | |
US20200168306A1 (en) | Method and system for sharing electronic medical and health records | |
US9390228B2 (en) | System and method for securely storing and sharing information | |
US10622104B2 (en) | System and method utilizing facial recognition with online (social) network to access casualty health information in an emergency situation | |
US20100063841A1 (en) | System and method of notifying designated entities of access to personal medical records | |
US11710132B2 (en) | User controlled event record system | |
US20170300629A1 (en) | Responder-aware auto-triggering of triaged contact events | |
US10586299B2 (en) | HIPAA-compliant third party access to electronic medical records | |
US11521720B2 (en) | User medical record transport using mobile identification credential | |
WO2017210563A1 (en) | System and method for securely storing and sharing information | |
KR20200111303A (en) | System and method for retrieval of medical information using blockchain and computer program for the same | |
US20230077823A1 (en) | System and method to access casualty health information in an emergency situation | |
AU2015346644A1 (en) | System and method for securely storing and sharing information | |
US11188676B2 (en) | Healthcare monitoring method and system for secure communication of patient data | |
KR20170032705A (en) | The secure automatic permission delegation system and method at emergency | |
Sanzi et al. | Integrating Trust Profiles, Trust Negotiation, and Attribute Based Access Control | |
Milutinovic et al. | Privacy-preserving data management in eHealth systems | |
Chen et al. | Managing secure personal mobile health information | |
KR20130031396A (en) | System for statistical information analysis of medicine |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |