Authenticating access to an end-of-life documents registry

Abstract

A system includes a processor configured to receive, from a registrant device, an upload of at least one document such as incapacity or end-of-life documents. The system stores the at least one document and receives access selections designating each of (i) contact and demographic information of one or more designated individuals and (ii) one or more types of entities permitted to request access to the at least one document as permitted entity types. The system receives an access request identifying a registrant for whom the at least one document is sought and verifies that the requester is a designated individual or associated with one of the permitted entity types. The system provides, to the requester device, access to the at least one document.

Description

AUTHENTICATING ACCESS TO AN END-OF-LIFE DOCUMENTS REGISTRYCross-Reference to Related Application

[0001] This application claims the benefit of and priority to U.S. provisional patent application Ser. No. 63 / 724,618, filed November 25, 2024, the entire contents of which are hereby incorporated by reference in its entirety.Technical Field

[0002] The present disclosure relates generally to registries and / or databases and more particularly to a registry or database of end-of-life and other documents, including graphical user interfaces (GUIs) for and authentication of access to the same.Summary

[0003] In some aspects, the techniques described herein relate to a computing device for managing controlled access to a registry of documents for a registrant, the computing device comprising a memory and a processor coupled to the memory. The processor is configured to execute instructions stored in the memory to establish a profile within the registry associated with a registrant and receive, from a registrant device associated with the registrant, an upload of at least one of the documents. The processor is further configured to store the at least one of the documents in association with the profile. The processor is further configured to receive, from the registrant device, access selections designating each of (i) contact and demographic information of one or more designated individuals and (ii) one or more types of entities permitted to request access to at least a subset of the documents as permitted entity types. The processor is further configured to receive, from a requester device, an access request identifying the registrant for which documents are sought and determine, based on the access selections, that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types. The processor isfurther configured to provide, to the requester device based on the determination that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types, access to the at least one of the documents.

[0004] In some aspects, the techniques described herein relate to a device comprising a non-transitory computer readable medium having instructions stored thereon that, upon execution by a processor, cause the device to establish a profile within the registry associated with a registrant and receive, from a registrant device associated with the registrant, an upload of at least one document. The instructions further cause the device to store the at least one document in association with the profile. The instructions further cause the device to receive, from the registrant device, access selections designating each of (i) contact and demographic information of one or more specific individuals as designated individuals and (ii) one or more types of entities permitted to request access to the at least one document as permitted entity types. The instructions further cause the device to receive, from a requester device, an access request identifying the registrant for which documents are sought and determine, based on the access selections, that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types. The instructions further cause the device to provide, to the requester device based on the determination that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types, access to the at least one document.

[0005] In some aspects, the techniques described herein relate to a method comprising establishing, by a processor of a computing device, a profile within the registry associated with a registrant and receiving, by the processor from a registrant device associated with the registrant, an upload of at least one document. The method further comprises storing, by theprocessor, the at least one document in association with the profile and receiving, by the processor from the registrant device, access selections designating each of (i) contact and demographic information of one or more designated individuals and (ii) one or more types of entities permitted to request access to the at least one document as permitted entity types. The method further comprises receiving, by the processor from a requester device, an access request identifying the registrant for which documents are sought and determining, by the processor based on the access selections, that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types. The method further comprises providing, by the processor to the requester device based on the determination that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types, access to the at least one document.Brief Description of the Drawings

[0006] Fig. 1 illustrates a system for providing a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0007] Fig. 2 is a flowchart illustrating an example process for providing a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0008] Fig. 3 is a flowchart illustrating an example process for implementing documentlevel access rules in a registry of documents such as incapacity or end-of-life documents according to various embodiments

[0009] Fig. 4 is a flowchart illustrating an example process for applying different verification gates for different types of users according to various embodiments.

[0010] Fig. 5 is a flowchart illustrating an example process for encrypting and decrypting documents in a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0011] Fig. 6 is a flowchart illustrating an example process for logging into a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0012] Fig. 7 is a flowchart illustrating an example process for looking up documents in a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0013] Fig. 8 is a flowchart illustrating an example process for navigating between various graphical user interfaces for a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0014] Fig. 9 is a flowchart illustrating an example process for providing a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0015] Fig. 10 is a flowchart illustrating an example process for making changes to an account of a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0016] Fig. 11 is a flowchart illustrating an example process for accessing documents in a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0017] Figs. 12-39 illustrate example graphical user interfaces of a registry of documents such as incapacity or end-of-life documents according to various embodiments.

[0018] Fig. 40 illustrates an example computing device or environment that may be used in various embodiments.Detailed Description

[0019] The following description of example methods and apparatus is not intended to limit the scope of the description to the precise form or forms detailed herein. Instead the following description is intended to be illustrative so that others may follow its teachings.

[0020] Described herein are various embodiments for a database or registry for registrants / users to upload lists of emergency contacts; lists of medications and allergies; advanced healthcare directives; wills; trust documents; powers of attorney; and other documents. The documents are made available for designated individuals, relatives, hospitals (and other healthcare facilities), and courts (probate, guardianship, etc.) if a registrant is unable to provide information or is otherwise incapacitated, or has passed away. Each registrant chooses which registry documents are accessible by which designated individuals, hospitals, and courts. A registrant may choose various designated individuals at the time of creating a profile. However, a registrant may not choose specific organizations such as hospitals, healthcare systems, courts, etc. because the registrant may not know which organizations may seek the registrant’s information in the future. A lookup function to search for registrants in the system is open to all, but only designated individuals (i.e. individuals designated by the registrant) for a given registrant are provided access to the registrant’s documents (or a subset of the registrant’s documents that the registrant selects for that individual). Organizations such as hospitals, healthcare systems, and courts may only be provided access to a registrant’s documents if they pass a verification or authentication process. The verification or authentication process for hospitals (and other healthcare systems or medical facilities) and courts includes determining that a given organization matches such an organization in a database.

[0021] In particular, registrants / users of Registry AZ may upload (i) various legal documents (e.g., wills, trust documents, advanced healthcare directives, powers of attorney); (ii) documents containing the user’s personal details (e.g., list of medications and allergies); and (iii) documents containing information regarding persons who may be contacted should the person die, become incapacitated, etc. (e.g., emergency contact list). The user may also select persons or types of entities who will have access to certain documents, such asrelatives, spouses, guardians, individuals with power of attorney, hospitals, courts (probate, guardianship, etc.), or other entities / persons. Each user may be able to specify which documents are accessible by each type of entity or person who may access the database / registry.

[0022] For example, certain documents may be available for access by hospitals, while a different or partially overlapping set of documents may be available for access by courts. While the user may specify the designated individuals and / or types of entities who can have access to documents / information, they may not necessarily specify which hospitals and which courts because a user may not know what hospital or court may be applicable in a situation where the user is incapacitated, for example. Thus, all hospitals and courts may have access to the system since a user at the time of registration may not know which hospital or which court may eventually need access to the documents.

[0023] A registrant’ s / user’s documents (including a contact list) are uploaded into the database / registry. For individuals, only designated individuals have access to a registrant’s documents. For organizations, only hospitals, healthcare systems, other medical facilities, probate courts, and guardianship courts, etc. may have access to documents, provided they have passed the verification / authentication process. Hospitals, healthcare systems, other medical facilities, probate courts, and guardianship courts, etc. that can access the system may be limited to those that are on a database. The verification / authentication process confirms the organization and may also confirm that the organization has an active case involving the registrant / user. While the look up function may be open to all, only designated individuals and chosen types of organizations will have access to the documents.

[0024] Once the system has verified that the person or entity is authorized to access a given registrant’ s / user’s documents per the settings the registrant / user originally set up the account with, the system can provide the documents to the entity or person seeking theinformation. In this way, for example, if a hospital has an incapacitated patient, the hospital may be able to seek and receive information from the registry about the person’s advanced healthcare directives, will, trust, emergency contact persons, power of attorney, etc. Such a system improves care for patients and may assist in numerous other situations where a patient is incapacitated or otherwise could not make medical or other decisions on their own, as the hospital can get information about the patient and be able to provide care for the patient based on the documents uploaded to the registry as well as connect with a person selected by the patient (e.g., listed in the contact list uploaded by the user / registrant) to help make care decisions. Such a system further solves a problem where a patient is incapacitated in a hospital, for example, but the hospital does not have access to and / or is not aware of any of the patient’s advanced healthcare directives, power of attorney, etc. In another example, user documents may greatly assist probate or guardianship court proceedings where knowing a user’s wishes would be useful.

[0025] As such, the various embodiments herein may include the following concepts or components:(1) Registrants / users may upload information / documents and may select designated individuals (e.g., contact persons for use in emergencies) as well as types of entities that may access the registrant’ s / user’s information / documents. This may include selecting which individuals or entity types may access particular information / documents.(2) The information / documents may include wills, trust documents, advanced healthcare directives, powers of attorney, contact list, list of medications and allergies, etc.(3) Person or entity representative may search for users in the registry and may access information / documents upon providing verification of their or their entity’s identity.(4) The persons or entities that may access the database may include designated individuals, hospitals, or courts (probate, guardianship, etc.).(5) A representative of an entity may search for a user and access the user’s information / documents even if that entity is not previously related to or associated with that user. This is useful where, for example, a healthcare facility that has never treated the user before is treating the user in an emergency situation.(6) A verification / authentication process whereby entities or organizations searching for documents of a user / registrant may be verified or authenticated before access to the documents is provided to the entity or organization (or representative thereof).(7) Various graphical user interfaces (GUIs) for implementing such systems as described herein on a computing device, such as a laptop computer, desktop computer, tablet, mobile computing device, etc. Such devices may, for example, access the GUIs through a web browser operating on the computing device, where the computing device is connected to the internet. In such examples, the GUIs may be provided on the computing device via a website navigated to by the web browser operating on the computing device. In various embodiments, the GUIs may also be provided as its own application on the computing device rather than being accessed as a web application through a web browser.

[0026] Fig. 1 illustrates a system 150 for providing a registry of documents such as incapacity or end-of-life documents (also referred to herein as registry documents) according to various embodiments. The system 150 may include a network 180 over which the various devices shown in Fig. 1 may communicate. The network 180 may be the internet or any other computing or wide area network over which computing devices may communicate. A registrant device 155 may be used by registrant to request and set up an account with a registry, upload documents to the registry, designate individuals or emergency contacts, edittheir profile with the registry, designate which types of entities may be permitted to access documents, and / or designate which documents may be accessed by particular designated individuals and / or particular entity types.

[0027] A registry server 160 may communicate with the registrant device 155 to permit users / registrants to set up a registry account, upload documents, etc. as described herein. An encryption key server 185 may be used by the registry server 160 to store encryption keys (e.g., along with the process for creating and managing encryption keys shown in and described with respect to Fig. 5). An encrypted documents server 190 may be used by the registry server 160 to store encrypted documents. The encrypted documents server 190 may be a separate server from the encryption key server 185, such that encryption keys and encrypted documents are not stored together on the same server. For example, the encrypted documents server 190 may be a commercially available cloud server (e.g., Amazon Web Services, Azure), while the encryption key server 185 may be a private server operated and maintained by the registry service. In various embodiments, the registry server 160 may also be a separate server from the encryption key server 185 and the encrypted documents server 190. However, in various embodiments, one or more of the registry server 160, the encryption key server 185, and / or the encrypted documents server 190 may be combined into a single server device.

[0028] The system 150 further includes a database or other entity verification server 180 that is accessible to the registry server 160 over the network 180. The database or other entity verification server 180 provides authoritative organizational data used to verify that a healthcare facility, court, or other entity purporting to access a registrant’s documents corresponds to a recognized provider. The registry server 160 may check the database or other entity verification server 180 to determine that a healthcare facility or court is listed as a legitimate or recognized healthcare provider or court, respectively. In various embodiments,when a request originates from an external entity (e.g., a representative of the entity using healthcare facility device 165), the registry server 160 may transmit a verification query including, for example, one or more of an entity name, address, telephone number, or other identifying attributes to the database or other entity verification server 180. The database or other entity verification server 180 may return a response indicating (or the registry server 160 may make a determination of) a match, a non-match, and / or confidence information that the supplied attributes correspond to a record in the database. The registry server 160 may use this response or determination, in combination with temporary-access records and configuration-driven gates, to permit or deny access. In various embodiments, the database or other entity verification server 180 is accessed via a secure API, the registry server 160 ingests periodic data files or feeds from the verification server 180 and performs local matching against a cached provider directory, and / or the registry server 160 may look up in the database or other entity verification server 180 data needed to verify a healthcare entity on demand in response to a request for access documents from the healthcare facility device 165.

[0029] A healthcare facility device 165 represents a computing device operated by authorized personnel at a hospital, healthcare system, or other medical facility seeking access to a registrant’s documents, for example in an emergency or incapacity scenario. The healthcare facility device 165 may present a lookup interface (e.g., a website hosted by the registry server 160) that allows personnel to identify a registrant by name and at least one additional identifier (e.g., date of birth, phone number, email address, social security number, address or partial address). As part of a submission of an access request, the healthcare facility device 165 may supply organization information and / or the identity of the authorized individual acting on behalf of the organization, and may also include in the submission an upload of an official request letter or other credential as required. The registry server 160 maythen initiate external-entity verification, which may include confirming that the healthcare facility device 165 is associated with an organization that matches a record returned by or located in the database or other entity verification server 180 and confirming that a corresponding record request is approved. If verification succeeds, the registry server 160 selectively provides access consistent with any of the registrant’s document-level access rules and, where applicable, retrieves encrypted documents from the encrypted documents server 190 and an encrypted key from the encryption key server 185 for delivery to the healthcare facility device 165. Decryption may, for example as described further herein with respect to Fig. 5, take place on the healthcare facility device 165, and the registry server 160 may refrain from performing decryption of any documents stored in or by the registry server 160.

[0030] An attorney device 170 represents a computing device operated by, for example, an attorney representing a party in a probate court, guardianship court, or other court or governmental authority proceeding. The attorney using the attorney device 170 (similar to the healthcare facility device 165) may use a lookup interface to identify a registrant and submit an access request, which may include court case identifiers, docket information, and / or a copy of a signed order or request letter from a judge, court, tribunal, or other governmental authority. After going through applicable verification steps, the registry server 160 may then provide document access according to any of the registrant’s entity -type rules for courts / govemment entities and / or document-level access rules, and may then for example deliver or cause to be delivered encrypted documents and an applicable encrypted key for client-side decryption on the attorney device 170.

[0031] A designated individual device 175 represents a computing device operated by a person explicitly designated by the registrant (e.g., spouse, guardian, or emergency contact). The designated individual device 175 may log in and / or authenticate using credentials associated with the designated individual and may be prompted for verification stepsconfigured for that user type, which may include human verification and / or two-factor authentication. The registry server 160 may match the identity presented by the designated individual device 175 against contact and demographic information stored in the registrant’s profile and may also enforce document-level access rules to ensure that only documents permitted for that designated individual are accessible. When the designated individual requests access to encrypted documents using the designated individual device 175, the registry server 160 may retrieve or cause to be sent the encrypted files from the encrypted documents server 190 and the registrant’s encrypted key from the encryption key server 185 and transmits both to the designated individual device 175, where decryption occurs client-side.

[0032] Fig. 2 is a flowchart illustrating an example process 200 for providing a registry of documents such as incapacity or end-of-life documents according to various embodiments. At an operation 210, a profile may be established within the registry, where the profile is associated with a particular registrant. The registrant may request that a profile be established, for example, using one or more graphical user interfaces in which a registrant may request a profile, enter information about the registrant, etc. For example, such information entered for a registrant profile may include any of full name, date of birth, landline number, mobile number, email, home address, or designated individuals (including, e.g., the full name, mobile number, email, landline number, home address, or any combination thereof of designated individuals). The system may allow a maximum number of designated individuals (e.g., 2, 3, 4, 5, 6, 7, 8, 9, 10) or may require a minimum number of designated individuals (e.g., 1, 2, 3, 4, 5).

[0033] At an operation 220, the server receives uploaded registry documents from a registrant device, including for example incapacity or end-of-life documents. As described further herein, the documents may be encrypted at the registrant device so that the registryserver does not store unencrypted documents. At an operation 230, the registry server may store the registry documents in association with the registrant’s created profile. The registry documents may include, for example, any of a list of emergency contacts, a list of medications and / or allergies, advanced healthcare directive(s), a will, trust documents, one or more powers of attorney, or any other documents.

[0034] At an operation 240, the registry server system may receive, from the registrant device, access selections designating each of (i) the designated individuals and (ii) one or more types of entities permitted to request access to at least a subset of the registry documents as permitted entity types. In other words, the registrant may specify via graphical user interface(s) on the registrant device, designated individuals and types of entities (e.g., hospital s / healthcare organizations, courts / legal entities) that are permitted to access documents in the registry with respect to the registrant. As described further herein, a registrant may also specify document-level access rules to specify which documents each designated individual can access and which documents each entity type can access, respectively.

[0035] At an operation 250, the system receives, from a requester device, an access request identifying the registrant for which documents are sought. The requester device may be a device of one of the designated individuals, may be a device of a representative of an entity (e.g., hospital s / healthcare organizations, courts / legal entities), etc.

[0036] At an operation 260, the system determines, based on the access selections, that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types. As described further herein, the system may perform a verification process to determine whether a representative of an organization is associated with one of the permitted entity types. For example, permitted persons or entities that may be able to access certain documents in the registry for a registrant mayinclude designated individuals, hospitals (and other healthcare facilities), or courts (e.g., probate courts, guardianship courts).

[0037] While a registrant may choose their designated individuals at the time of creating a profile, a registrant may not choose a specific hospital or court because they cannot know which organization may be seeking their information in the future. Each registrant may also choose which registry documents are accessible by which accessing entities (e.g., documentlevel access rules). A registrant may also later log in and change / edit / add to their designated individuals in their profile, selecting which type of entities may access records, and / or change document-level rules specifying which documents may be made available to particular individuals or to particular types of entities.

[0038] When an individual or a representative of an entity is attempting to access documents, the representative may be prompted for information regarding a lookup target, such as the target's name and one identifier. If the target exists on the registry, the system may prompt the entity to select whether it is a designated individual or an organization / entity. For a designated individual, the system may prompt the individual to provide their name and email address. After matching the name and email address on file, the system may send out a confirmation code to the email address. For an organization, the system may ask for the name of the organization, name of the authorized individual working on behalf of the organization, an email of the authorized individual, a phone number of the organization or authorized individual, a street address of the organization or authorized individual, an attachment of an official request letter signed by the authorized individual representing the entity, or any combination thereof. In other words, they system may prompt the user for different types of information depending on whether the user is a designated individual, a representative of an entity, etc.

[0039] The system may also further include a verification process whenever a user tries to log in or otherwise access the system and / or documents of a registrant. Such verification may include, for example, two-factor authentication, codes sent to email addresses or phone numbers, verification using a third-party authenticator application, etc. In various embodiments as described further herein, different verifications steps may be performed for different user types.

[0040] At an operation 270, they system provides, to the requester device based on the determination that the requester is one of (a) designated individuals or (b) associated with an organization corresponding to one of the permitted entity types, access to the at least one of the registry documents. In other words, once a user requesting access to documents is properly authenticated and verified, the system may provide access to those documents to the user.

[0041] Fig. 3 is a flowchart illustrating an example process 300 for implementing document-level access rules in a registry of documents such as incapacity or end-of-life documents according to various embodiments. At an operation 310, the system receives, from the registrant device, document-level access rules associating respective registry documents with at least one of the designated individuals or the permitted entity types. In other words, a registrant may specify, document by document, which documents should be accessible to a given designated individual and which documents should be accessible to a given type of entity (e.g., court, healthcare facility).

[0042] At an operation 320, if the requester is determined to be one of the designated individuals, the system may authenticate the requester via data received from the requester device and, upon successful authentication, authorize access to only those documents permitted for a given one of the designated individuals under the document-level access rules. In other words, if the requester is a designated individual, the system may provide access to asubset of a total number of documents based on the document-level access rules, providing that the designated individual properly authenticates themselves using the various applicable verification steps or gates.

[0043] At an operation 320, if the requester is determined to be associated with an organization corresponding to one of the permitted entity types, the system performs an organizational verification, for example including matching the organization to a record in a database. The system may also only permit access for the organization to those documents permitted for the organization type under the document-level access rules and based on a type of the permitted entity types associated with the organization. As such, the system may also make a determination of what type of entity is requesting access to the documents as part of a verification / authentication process but also for use in applying document-level access rules as described herein.

[0044] In various embodiments, a registry system as described herein may use different authentication or verification gates / steps for different types of users (e.g., registrants, designated individuals, court / govemment representatives, healthcare organization representatives, registry admin). Such differences may be implemented, for example, with a configuration-driven / runtime flow used instead of typical hardcoded onboarding and verification logic with data-driven gates that are evaluated at request time (e.g., at login or account creation by a given user). Rather than embedding specific steps (e.g., reCAPTCHA, email verification, two-factor authentication, approval workflows) directly into controllers or routes, the system maintains feature flags and flow definitions in a configuration data store and applies them through middleware that executes on each request based on a determined user type for a given request. In other words, the system may save configuration data in a database, including both feature flags and the flow definitions that control sets of verification steps for various types of users that might access the system in different ways (e.g., admins,registrants, designated individuals, healthcare or court entity requesters). As such, the system may store which features are enabled / disabled and the rules that define how each verification flow behaves, so that those settings persist across sessions and drive the runtime behavior without the use of code changes by a software engineer or administrator of the system.

[0045] For example, when a request from a user arrives, the system resolves or determines the user’s type or role (e.g., Admin, User / Regi strant, or a temporary external entity such as a court or hospital). Once a user’s type or role has been identified, middleware of the system may load feature flags and / or flow parameters from a settings store and determine a sequence of dynamic verification gates or authentication steps that each correspond to a potential step in a verification / authentication flow. The system determines which steps / gates to use for a given user type. For example, if a ReCAPTCHA flag is enabled for a given user type, the human-verification gate may be applied before other credential checks. In another example, if two-factor authentication (2FA) is enabled or required for a given user type, a two-factor verification gate is invoked. As such, an onboarding sequence is rendered or reordered according to a data-driven definition based on user type rather than on a hard coded, single process for all users.

[0046] In another example, external entities such as hospitals or courts may be handled through temporary-access records rather than permanent accounts with the registry. Requests from these entities may be fulfilled only if the requester is approved based on a predetermined set of verification gates for a given entity or entity type. This advantageously allows a same request pipeline of a website or registry to serve internal users who have already set up accounts with the registry, new users looking to sign up for an account with the registry, and / or external entities seeking temporary access to user documents, all while preserving least-privilege access for entities that may not have standing credentials or accounts in the system.

[0047] Every allow / deny outcome for a document request and / or entity or individual verification may also be recorded in an append-only audit log, capturing who acted, what gate(s) were applied, and the resulting decision taken. Because all flow composition occurs in data, operations personnel can enable, disable, or reorder verification and onboarding steps instantly (e.g., turning on reCAPTCHA and / or forcing 2FA for admins) without redeploying code. This approach provides flexibility to tailor compliance and onboarding requirements per user segment, may support rapid policy changes, and / or may yield a uniform, auditable enforcement mechanism across the registry system

[0048] Fig. 4 is a flowchart illustrating an example process 400 of applying different verification gates for different types of users according to various embodiments. At an operation 410, the system provides a lookup interface configured to allow a requester device to identify a registrant and submit an access request for at least one registry document stored in an example registry as described herein. In various embodiments, the lookup interface is rendered by a registry server as a web application or native application view accessible over a network. The interface may present input fields for a registrant’s name and at least one secondary identifier (e.g., date of birth, phone number, email address, partial address), along with selectable document categories that are sought for the registrant (e.g., advanced healthcare directives, powers of attorney, contact lists, lists of medications and allergies, wills, trust documents). The interface may further include role selection prompts or contextual hints guiding the requester device to indicate a requester’s association (e.g., designated individual, hospital, or court). In various embodiments, the lookup interface is publicly accessible for initial search but prevents any disclosure of document contents until subsequent authorization is completed.

[0049] At an operation 420, the system receives identifying information about a registrant and an access request from the requester device. The access request may include theregistrant identifiers supplied via the lookup interface, a description of the requested documents or categories, and / or data identifying the requester. For example, a designated individual may supply a name and email address; a healthcare facility representative may supply an organization name, facility address, and / or a request letter or credential; and / or a court authority may supply court case identifiers, docket information, and / or a signed order. The registry server may normalize and validate the submitted data, associate the request with an internal request record, and / or prepare the request for verification by storing it alongside timestamps and device attributes (e.g., IP address, user agent), which may also be recorded in an audit log. In various embodiments, minimal input validation may be performed at submission to detect obviously malformed or incomplete requests, while deeper verification steps may be deferred to subsequent operations.

[0050] At an operation 430, the system determines a requester type associated with the request. The determination may be based on one or more of explicit role selection in the lookup interface; attributes of the authenticated session; organizational indicators provided in the request (e.g., healthcare entity or court name, court docket number); and prior temporaryaccess records (e.g., approved hospital requests or court requests rows corresponding to the requester). The requester type may include, for example, a designated individual or a representative associated with an external entity such as a hospital or a court. In various embodiments, the system expands effective permissions for the requester type using a role-to- permission mapping and also infers which verification steps are applicable based on configuration stored in a settings data store. The requester type determination is recorded and may be used to drive both the verification flow and subsequent document-level access enforcement.

[0051] At an operation 440, the system may load and presents a set of verification gates specific to the requester type. In various embodiments, the verification gates areconfiguration-driven and may be enabled, disabled, and / or reordered without redeploying code. For a designated individual requester type, the gates may include one or more of human verification (e.g., reCAPTCHA), credential checks, email verification, and two-factor authentication, each enforced only if the corresponding feature flag is enabled. For an external entity representative requester type, the gates may include temporary-access validation by confirming an approved and unexpired request record (e.g., for a court request or a hospital request), organizational verification (e.g., matching a court or healthcare facility to a record in a database), and, where applicable, confirmation of case-related information (e.g., docket or matter identifiers). The registry server presents interactive steps to the requester device, evaluates automated gates server-side, and logs each gate’s outcome in an audit log / trail. Only upon successful completion of all applicable gates for that particular user type does the process proceed to subsequent operations that authorize and, where appropriate, facilitate client-side decryption by provision of encrypted documents and encrypted key material to the verified requester device.

[0052] While Fig. 4 describes how different verification gates may be used for different types of requesters while they are using the lookup function of a registry as described herein (e.g., designated individual, attorney relating to particular court proceedings, representative of a healthcare facility), various embodiments may also apply different verification gates for other users at different times when using an example registry. For example, when an administrator or registrant seeks to login to the website, the website may implement different verification gates for a registrant and / or administrator than those that were applied to an attorney requester or a healthcare provider requester. For example, for an administrator type login, the gates may include mandatory two-factor authentication when an administrative enforcement parameter is enabled, and additional approval workflows if configured. For a registrant type login, the gates may include one or more of human verification (e.g.,reCAPTCHA), credential checks, email verification, and two-factor authentication, each enforced only if the corresponding feature flag is enabled, for example.

[0053] As such, in various embodiments, when a user submits a request to access a document or tries to log into the system, the system may first resolve the user’s identity or entity type. The system may then loads feature flags from a settings store (e.g., by loading into short-lived caching). The system may then evaluate the applicable dynamic verification gates and then finally may issue an allow or deny decision for a log in or record access request based on whether the user completes the applicable verification gates. The system may also record the user type determined, the verification gates applied, and the outcome of each verification gate and the final allow or deny decision in an audit log. If allowed, the system may then hand off the request to an appropriate controller for fulfillment.

[0054] The system may apply various configurable verification and policy gates at request time, driven entirely by reconfigurable settings. For example, different verification and policy gates of a system may include whether the following are applied: human verification (e.g., reCAPTCHA), two-factor authentication (2FA), username and / or password used for login, etc. In various embodiments, similar steps may be used for different user types but in different orders.

[0055] Other configurable policies or features of a registry may include upload policies such as maximum file size or allowed file types; whether admins can view encrypted documents or not (e.g., if not, admins may only be able to see metadata related to encrypted documents and / or audit trails); who can upload, view, decrypt documents; what entities or entity types can gain temporary access to records (e.g., through receiving encrypted documents and an associated encryption key), etc.

[0056] As just one example, pseudo-code for a process flow may be:onRequest(req): u = requireAuthenticatedUser(req) role = u.role perms = expandPermissions(role) # role_permissions — permissions cfg = loadSettingsCache() # settings flags (short-lived cache)# Composite gate example: view document if not has(perms, 'view documents self) and not has(perms, 'view documents any'): deny('insufficient_permission') if cfg.get('show recaptcha') == 'YES' and requiresHumanCheck(req): enforceRecaptcha(req) if cfg.get('enable_two_factor_authentication') == 'YES': enforce2FA(u) if isExternalEntityRequest(req): ensureApprovedTemporaryAccess(req) # court_requests / hospital_requests allow(); auditLog(u.id, 'allow', details=req.summary())

[0057] In various embodiments, a particular encryption and decryption scheme along with encryption key management policies may be used to make registrant’s data more secure. For example, a registry server may expose on-demand encryption key endpoints (e.g., application programming interface (API) endpoints) to facilitate client-side key generation and usewithout having persisting long-term secrets existing on a given user device. For example, a first endpoint (e.g., a POST API endpoint of an encryption-key resource) may generate and / or register a per-user symmetric key and store an encrypted representation of that key in association with the registrant’s profile. A second endpoint (e.g., a GET API endpoint of the encryption-key resource) may retrieve the encrypted key material for authorized use (e.g., by an approved entity). In operation, a front-end executing on a registrant device may request the key immediately prior to encrypting files, perform local encryption, and then discard any transient plaintext key material. This arrangement may provide a lightweight, application-scoped key exchange that does not rely on external key management services and avoids maintaining long-lived secrets on the client device.

[0058] Client-side encryption and key handling may proceed as follows, in various embodiments. A unique symmetric encryption key (e.g., an AES-GCM key) is generated at the registrant device, such as within the user’s browser. The same per-user key may be used to encrypt multiple documents associated with that user. Before any file is transmitted to the registry server or object storage, the registrant device encrypts the file locally using the per-user key, thereby transforming the file content (and, in some cases, stored filename or metadata) so that no plaintext document content is received or stored by the server.

[0059] Encrypted payloads and encrypted key material may be stored in separate systems. The encrypted file (e.g., ciphertext) may be uploaded to and stored in a cloud object storage service (e.g., an AWS S3-compatible service) that holds only encrypted blobs. Separately, the per-user key may be converted to a suitable representation (e.g., a JSON Web Key (JWK)), encrypted on the registrant device, and stored in a secure database table (e.g., an encryption keys table) associated with the user’s profile. This segregation may ensure that ciphertext and the corresponding key material are never co-located and that the server does not possess plaintext document contents.

[0060] When a requester device operated by a permitted party (e.g., designated individual, a representative of a court authority or a healthcare facility) is verified and authorized, the registry server may provide two components via controlled application programming interfaces (APIs): (i) the encrypted document retrieved from the cloud object storage service and (ii) the registrant’s encrypted key retrieved from the database. Decryption occurs on the requester device. In particular, the requester device first decrypts the per-user key under authorized context and then uses that key to decrypt the requested file(s) locally for viewing or processing. The registry server therefore refrains from server-side decryption and may never store plaintext versions of the documents.

[0061] Security and audit properties may be enforced throughout the flow. Encrypted files at rest may be unusable without the corresponding key, and keys at rest may themselves be encrypted and stored separately from the encrypted files. Middleware and policy checks may gate any release of encrypted key material or encrypted documents, and every access event is recorded in an append-only audit log capturing, for example, an identifier of the requester device, timestamps, and the authorization outcome. This design may yield end-to-end confidentiality and ensures that even privileged operators of the registry infrastructure cannot read file contents without the user’s key.

[0062] Fig. 5 is a flowchart illustrating an example process 500 for encrypting and decrypting documents in a registry of documents such as incapacity or end-of-life documents according to various embodiments. At an operation 510, an encryption key is generated within a browser executing on a registrant device. In various embodiments, the key is a symmetric key suitable for authenticated encryption and is created client-side so that no plaintext key material is required to be generated or stored by a server. At an operation 520, the registrant device encrypts the registry documents locally using the generated encryption key prior to sending or uploading any document content to a registry server. This ensures thatonly ciphertext is transmitted over the network and that no plaintext document content is received by the registry server.

[0063] At an operation 530, the registrant device transmits the encrypted documents to the registry server for storage, for example in an encrypted documents repository or cloud object storage associated with the registry server. At an operation 540, the registrant device transmits the encryption key, for example in an encrypted representation, to an encryption key server for storage, wherein the encryption key server is separate from the storage used for the encrypted documents to ensure that keys and ciphertext are not co-located. In some embodiments, the key is converted to a transportable representation prior to client-side encryption and transmission.

[0064] At an operation 550, after an access request from a requester device (e.g., a device being used by a user such as a designated individual, representative of approved entity, registrant) has been approved and validated according to applicable verification gates, the registry server causes both the encrypted documents and the registrant’s encrypted key to be sent to the requester device. In various embodiments, the encrypted documents are retrieved from the registry storage and the encrypted key is retrieved from the encryption key server via controlled interfaces. At an operation 560, the requester device decrypts the encryption key under authorized context and then uses the decrypted key to decrypt the encrypted documents locally on the requester device. In this way, decryption occurs client-side and the registry infrastructure refrains from server-side decryption while maintaining auditability of key and document releases.

[0065] Fig. 6 is a flowchart illustrating an example process 600 of logging into a registry of documents such as incapacity or end-of-life documents according to various embodiments. For example, the system may determine if an account exists for a registrant and either permit the user to login or have the registrant create a new account. A user may go throughverification gates such as 2FA, and after being authenticated, the user may be permitted to view and / or edit various data fields such as a personal profile, designated individuals, document names or types (and the user may be permitted to upload such documents), individual assignments (e.g., document-level access rules for designated individuals), entity assignments (e.g., document-level access rules for entities), billing information, and / or a printable card that may include information for requesters to access and look up a registrant in the registry. A registrant may print and carry the card so that if the registrant is unable to communicate or is otherwise incapacitated someone may look up the registrant in the registry using information on the printable card. The registry database may also be able to access a database regarding hospitals, courts, etc. so that the registry can validate, authenticate, verify, etc. various entity types that may request access to documents about a registrant.

[0066] Fig. 7 is a flowchart illustrating an example process 700 of looking up documents in a registry of documents such as incapacity or end-of-life documents according to various embodiments. For example, a designated individual (e.g., emergency contact designee) or an entity representative may access a registry lookup to search for a registrant. If the registrant exists, the system may determine if the requester is an individual or a representative of an organization. If the requester is an individual, the system may perform an individual verification, and then may email a confirmation code to the individuals email before permitting access to view / print / decrypt / etc. registry documents. If the requester is an entity, the system may verify the entity using a database. The system may also email a confirmation code to the representative of the entity prior to permitting access to view / print / decrypt / etc. registry documents.

[0067] Fig. 8 is a flowchart illustrating an example process 800 for navigating between various graphical user interfaces for a registry of documents such as incapacity or end-of-life documents according to various embodiments. For example, a home page of a registrywebsite may be accessed via the internet on a user device. From the home page, a user may be able to access various pages such as about us, how it works, pricing, contact us, frequently asked questions, login, and lookup pages. From the login page, a user may be able to create an account, select designated individuals, pay for the service, upload registry documents, and assign access permissions for various individuals and / or entities to access the uploaded registry documents. From the login page, the user may also be able to log in and access a registrant dashboard that includes various links to other webpages such as links to webpages or graphical user interfaces related to the registrant’s profile, identified designated individuals, uploaded documents or document properties, individual assignments (e.g., document-level access rules for designated individuals), entity assignments (e.g., documentlevel access rules for entities), billing information, and / or a printable card. From the lookup page, a user may be able to determine if a target is in the registry by looking up that individual and at least some further identifying information of the individual. If the user looking up a registrant is an individual (e.g., designated individual), the user may go through verification gates and be provided access based on being an individual. If the user looking up a registrant is a representative of an entity, the user may go through verification gates and be provided access based on verification of the entity, as described herein.

[0068] Fig. 9 is a flowchart illustrating an example process 900 for providing a registry of documents such as incapacity or end-of-life documents according to various embodiments. The process 900 may be a process a registrant user or registrant’s representative user follows when setting up an account. For example, the user may declare their name and role and provide a signature and date. The user may also input a username, password, and registrant profile information such as contact information, ID type and number, and date of birth. The registry system may review the profile information for completeness and verify an email address of the user. The user may also add designated individuals, select a number and / ortype of documents they will upload, input payment information to purchase the product, upload the documents (e.g., will, trust, advance health directive(s)), and select which registry documents are accessible by which types of accessing entities and / or designated individuals.

[0069] Fig. 10 is a flowchart illustrating an example process 1000 for making changes to an account of a registry of documents such as incapacity or end-of-life documents according to various embodiments. A registrant may login using a username and password and select an area to view / edit on the registrant dashboard, such as the registrant dashboard shown in Fig. 8. By selecting one of those areas, a user may update profile information, add / edit / delete designated individuals, view billing transaction history, add / replace / delete registry documents, view / download / print the printable card, and / or modify accessibility of the registry documents by designated individual(s) and / or organizations / entities (e.g., modify document-level rules and / or access selections).

[0070] Fig. 11 is a flowchart illustrating an example process 1100 for accessing documents in a registry of documents such as incapacity or end-of-life documents according to various embodiments. For example, a requester may initiate a registry lookup, input a target name and at least one identifier (e.g., date of birth), and the registry may verify the information of the target. The requester may also input a type of accessing entity (e.g., court, healthcare organization). If the requester is an individual, the individual may input name and email for example. The system may then verify the identity of the requesting individual based on designated individuals listed in a particular registrant’s list of authorized designated individuals and then grant the designated individual access to the specified registry documents (e.g., as selected in advance by the registrant). If the requester is an organization, the user or representative may input authentication information associated with the entity seeking access, which may include information such as organization name, authorized representative, email address, phone number, address, etc. If the organization is a healthcareentity such as a hospital, the system may verify the identity of the organization authorized representative and also verify the identity in a database. If the entity is a governmental entity such as a court, the representative may upload an official court order and then the system may verify the identity of the court / organization and its authorized representative, which may also include a database match. If the entity is verified / authenticated, the system grants the authorized representative access to any registry documents specified or selected in advance by the registrant as being able to be viewed by a given entity type.

[0071] Figs. 12-36 illustrate example graphical user interfaces (GUIs) of a registry of documents such as incapacity or end-of-life documents according to various embodiments. Fig. 12 shows an example homepage as referenced in Fig. 8, and Figs. 13-36 show example GUIs that may be accessible or navigated to from the base homepage of Fig. 12. Fig. 13 shows an about us page and Figs. 14-15 shows GUIs for creating a new login or registrant account. Fig. 16 shows an example GUI for naming a designated individual as described herein. Fig. 17 shows an example GUI for uploading documents by a registry. In the example of Fig. 17, there are six default document types to upload and additional slots for user-defined documents for upload. An upload button may be functional if a type of document is populated but no document has been uploaded yet. Upload to replace buttons may also be used in Fig. 17 to replace a previously uploaded document, and may be functional if there is a previously uploaded document for that document type.

[0072] Fig. 18 shows an example GUI for designating which documents will be accessible to which designated individuals (e.g., document-level access rules). The GUI may also list the document types and the names of the designated individuals themselves, in various embodiments. Fig. 19 shows a GUI for designating which documents will be accessible to which types of entities (e.g., document-level access rules). The GUI may also list the document types, in various embodiments.

[0073] Fig. 20 shows an example GUI for logging in or creating a new account with a registry. Figs. 21-31 show example GUIs for aspects of a registrant dashboard such as that shown in Fig. 8. Figs. 21 and 22 relate to the viewing or editing a registrant profile. In Fig.21, the GUI provides for a registrant to select a registrant profile tab (or the registrant profile tab is automatically displayed, e.g., after a registrant logs in). The page may be pre-populated with the actual information of the registrant if the registrant already has completed their profile. Fig. 22 shows a GUI where a registrant may add or edit their registrant information.

[0074] Figs. 23-26 show example GUIs where a registrant may add or edit information about designated individuals. Fig. 23 shows a GUI where a registrant may input and view information about designated individuals. The information about a selected / highlighted designated individual may be pre-populated into a portion of the GUI if information about that designated individual had previously been entered. The user may also select or delete other designated individuals. Fig. 24 shows a GUI where a registrant may enter information about a designated individual after an update button is selected from Fig. 23, for example. Fig. 25 shows a GUI where a registrant may delete a designated individual after selecting one of the delete buttons from Fig. 23. Fig. 26 shows a GUI where a registrant may add a designated individual after selecting one of the add buttons from Fig. 23.

[0075] Fig. 27 shows a GUI where a registry documents tab is selected and a list of already-uploaded documents may be pre-populated. From the GUI in Fig. 27, already- uploaded documents may be deleted by pressing a delete button or documents may be added / replaced by selecting an add / replace button that leads to the GUI of Fig. 28. In Fig. 29, an example GUI is shown where a registrant may edit which designated individuals can view specific documents or document types (e.g., document-level rules). Fig. 30 shows an example GUI where document-level rules for certain entity types (e.g., hospital s / healthcare orgs, courts / legal entities) may be entered or changed. The document types may be pre-populatedbased on types of documents that have already been uploaded by the registrant. Fig. 31 shows an example GUI for a security tab where a password of a registrant may be changed.

[0076] Figs. 32-36 show example GUIs related to a registrant lookup that may be used, for example, by a designated individual or accessing entity (e.g., healthcare or court entity) to look up potential registrants and access documents upon proper authorization. Fig. 32 shows an example GUI where details of a registrant may be entered by a requester. Fig. 33 shows an example GUI where a requester type may be entered by the requester. As described herein, this selection may cause the system to determine a requester type and implement different authentication steps or verification gates based on the requester type. Fig. 34 shows an example GUI where a designated individual (if selected in the GUI of Fig. 33) may enter information about themselves to ensure that the requester is an authorized designated individual associated with a registrant’s account. Fig. 35 shows an example GUI where a representative of an entity (e.g., hospital, court) may enter name about themselves and the entity with which they are associated. The GUI in Fig. 35 may be displayed if the “Hospital and other healthcare facility” or “Court” options are selected in the GUI of Fig. 33. Fig. 36 displays results of a registry look up as long as the designated individual (e.g., as entered in the GUI of Fig. 34) or accessing entity (as entered in the GUI of Fig. 35) information has been authenticated / verified.

[0077] Fig. 37 shows an example GUI for a dashboard accessible by a registrant of the registry system described herein. The GUI of Fig. 37 may be used, for example, in lieu of the registrant dashboard of Fig. 21. In Fig. 37, a registrant may be able to log in to see the dashboard and various information related to their account. For example, a registrant may see a total number of designated individuals they have designated, how many have been verified, how many are unverified, and specifics or status of each designated individual (e.g., verified, unverified). A registrant may also be able to see documents status, such as how many havebeen uploaded, how many have been paid for, how many more they can upload without paying more, and a maximum number of documents permitted to upload. Another “Individual Assignments” portion of the GUI of Fig. 37 may display a number of designated individuals to whom no documents have been assigned (e.g., no document-level access rule has given access to a designated individual to at least one document) and a number of documents that have not been assigned to a designated individual (e.g., no document-level access rule has assigned a given document to any designated individual).

[0078] The GUI in Fig. 37 further includes an “Entity Assignments” section that shows how many documents have been assigned to be viewed by a court-type entity and how many documents have been assigned to be viewed by a healthcare-type entity (e.g., what the document-level access rules are for the different entity types). The dashboard may further have a section for review of all uploaded documents titled “Your Documents.”

[0079] The GUI of Fig. 37 further includes “Latest Access Logs” which may include information about who has accessed the registrant’s uploaded documents and when. For example, the “Latest Access Logs” may include information about a specific document name or type that has been accessed, who it has been accessed by (e.g., designated individual name, entity representative name, and / or entity name), and when that document was accessed. A “Recent Activities” portion of the GUI may also show successful or failed login attempts for a given registrant’s account to help give peace of mind to a registrant that their account has not been fraudulently accessed and alert the registrant to any attempted or successful unauthorized access to their account.

[0080] Fig. 38 shows a GUI that may be an alternative to the GUI of Fig. 35. In Fig. 38, the GUI is a form for completion by a representative of a healthcare organization. Data fields for completion may include a name of the registrant for whom documents are sought, a name of an attending physician for the registrant and an associated email address and phonenumber, name of the hospital or healthcare facility and address, and a place for the requester to sign and date the request.

[0081] Fig. 39 shows a GUI that may be an alternative to the GUI of Fig. 35. In Fig. 39, the GUI is a form for completion by a representative of a court or other legal organization. Data fields for completion may include a name of the registrant for whom documents are sought, a name of an attorney and law firm seeking the records, along with that attorney’s phone number and email, a court name and / or department, a judge name, the court or legal organization’s address, a title of the case, a case number, a dialog for inputting the reason for seeking documents (this could include a user input of a legal basis, such as a statute or regulation number, for seeking the documents), a GUI element for uploading a signed court order that permits a party to access or seek the documents, and a place for the request to sign and date the request.

[0082] As such, various embodiments herein relate to a database or registry for registrants / users to upload lists of emergency contacts; lists of medications and allergies; advanced healthcare directives; wills; trust documents; powers of attorney; and other documents. The documents may be made available for designated individuals (e.g., including relatives), hospitals (and other healthcare facilities), and courts (probate, guardianship, etc.) if a registrant is unable to provide information or is otherwise incapacitated or has passed away.

[0083] Fig. 40 is a diagrammatic view of an example embodiment of a user computing environment that includes a general-purpose computing system environment 100, such as a desktop computer, laptop, smartphone, tablet, or any other such device having the ability to execute instructions, such as those stored within a non-transient, computer-readable medium. The aspects of Fig. 40 and its associated description may be used in accordance with the embodiments herein to implement a database / registry and its associated GUIs and verification / authentication methods. For example, a computing device hosting a website orapplication as described herein may be or may have various components of the computing device below. A computing device accessing a website having the GUIs described herein may also be or may also have various components of the computing device shown below. In addition, the aspects of Fig. 40 and its associated description may have instructions stored thereon for implementing any of the methods or functions described herein, including for implementing the various flow charts and GUIs shown in Figs. 2-39. Each of the devices or servers depicted in Fig. 1 may also be the computing system in Fig. 40 or may have some or all of the components of the computing system of Fig. 40.

[0084] Furthermore, while described and illustrated in the context of a single computing system 100, those skilled in the art will also appreciate that the various tasks described hereinafter may be practiced in a distributed environment having multiple computing systems 100 linked via a local or wide-area network in which the executable instructions may be associated with and / or executed by one or more of multiple computing systems 100.

[0085] In its most basic configuration, computing system environment 100 typically includes at least one processing unit 102 and at least one memory 104, which may be linked via a bus. Depending on the exact configuration and type of computing system environment, memory 104 may be volatile (such as RAM 110), non-volatile (such as ROM 108, flash memory, etc.) or some combination of the two. Computing system environment 100 may have additional features and / or functionality. For example, computing system environment 100 may also include additional storage (removable and / or non-removable) including, but not limited to, magnetic or optical disks, tape drives and / or flash drives. Such additional memory devices may be made accessible to the computing system environment 100 by means of, for example, a hard disk drive interface 112, a magnetic disk drive interface 114, and / or an optical disk drive interface 116. As will be understood, these devices, which would be linked to the system bus, respectively, allow for reading from and writing to a hard disk 118, readingfrom or writing to a removable magnetic disk 120, and / or for reading from or writing to a removable optical disk 122, such as a CD / DVD ROM or other optical media. The drive interfaces and their associated computer-readable media allow for the nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computing system environment 100. Those skilled in the art will further appreciate that other types of computer readable media that can store data may be used for this same purpose. Examples of such media devices include, but are not limited to, magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memories, nanodrives, memory sticks, other read / write and / or read-only memories and / or any other method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Any such computer storage media may be part of computing system environment 100.

[0086] A number of program modules may be stored in one or more of the memory / media devices. For example, a basic input / output system (BIOS) 124, containing the basic routines that help to transfer information between elements within the computing system environment 100, such as during start-up, may be stored in ROM 108. Similarly, RAM 110, hard drive 118, and / or peripheral memory devices may be used to store computer executable instructions comprising an operating system 126, one or more applications programs 128 (which may include the functionality disclosed herein, for example), other program modules 130, and / or program data 122. Still further, computer-executable instructions may be downloaded to the computing environment 100 as needed, for example, via a network connection.

[0087] An end-user may enter commands and information into the computing system environment 100 through input devices such as a keyboard 134 and / or a pointing device 136. While not illustrated, other input devices may include a microphone, a joystick, a game pad, ascanner, etc. These and other input devices would typically be connected to the processing unit 102 by means of a peripheral interface 138 which, in turn, would be coupled to the bus. Input devices may be directly or indirectly connected to processor 102 via interfaces such as, for example, a parallel port, game port, firewire, or a universal serial bus (USB). To view information from the computing system environment 100, a monitor 140 or other type of display device may also be connected to the bus via an interface, such as via video adapter 132. In addition to the monitor 140, the computing system environment 100 may also include other peripheral output devices, not shown, such as speakers and printers.

[0088] The computing system environment 100 may also utilize logical connections to one or more computing system environments. Communications between the computing system environment 100 and the remote computing system environment may be exchanged via a further processing device, such a network router 152, that is responsible for network routing. Communications with the network router 152 may be performed via a network interface component 154. Thus, within such a networked environment, e.g., the Internet, World Wide Web, LAN, or other like type of wired or wireless network, it will be appreciated that program modules depicted relative to the computing system environment 100, or portions thereof, may be stored in the memory storage device(s) of the computing system environment 100.

[0089] The computing system environment 100 may also include localization hardware 186 for determining a location of the computing system environment 100. In embodiments, the localization hardware 156 may include, for example only, a GPS antenna, an RFID chip or reader, a WiFi antenna, or other computing hardware that may be used to capture or transmit signals that may be used to determine the location of the computing system environment 100.

[0090] While this disclosure has described certain embodiments, it will be understood that the claims are not intended to be limited to these embodiments except as explicitly recited in the claims. On the contrary, the instant disclosure is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the disclosure. Furthermore, in the detailed description of the present disclosure, numerous specific details are set forth in order to provide a thorough understanding of the disclosed embodiments. However, it will be obvious to one of ordinary skill in the art that systems and methods consistent with this disclosure may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure various aspects of the present disclosure.

[0091] Some portions of the detailed descriptions of this disclosure have been presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer or digital system memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, logic block, process, etc., is herein, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these physical manipulations take the form of electrical or magnetic data capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system or similar electronic computing device. For reasons of convenience, and with reference to common usage, such data is referred to as bits, values, elements, symbols, characters, terms, numbers, or the like, with reference to various presently disclosed embodiments.

[0092] It should be borne in mind, however, that these terms are to be interpreted as referencing physical manipulations and quantities and are merely convenient labels thatshould be interpreted further in view of terms commonly used in the art. Unless specifically stated otherwise, as apparent from the discussion herein, it is understood that throughout discussions of the present embodiment, discussions utilizing terms such as “determining” or “outputting” or “transmitting” or “recording” or “locating” or “storing” or “displaying” or “receiving” or “recognizing” or “utilizing” or “generating” or “providing” or “accessing” or “checking” or “notifying” or “delivering” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data. The data is represented as physical (electronic) quantities within the computer system’s registers and memories and is transformed into other data similarly represented as physical quantities within the computer system memories or registers, or other such information storage, transmission, or display devices as described herein or otherwise understood to one of ordinary skill in the art.

Claims

ClaimsWhat is claimed is:

1. A computing device for managing controlled access to a registry of documents for a registrant, the computing device comprising: a memory; and a processor coupled to the memory, the processor configured to execute instructions stored in the memory to: establish a profile within the registry associated with a registrant; receive, from a registrant device associated with the registrant, an upload of at least one of the documents; store the at least one of the documents in association with the profile; receive, from the registrant device, access selections designating each of (i) contact and demographic information of one or more designated individuals and (ii) one or more types of entities permitted to request access to at least a subset of the documents as permitted entity types; receive, from a requester device, an access request identifying the registrant for which documents are sought; determine, based on the access selections, that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types; and provide, to the requester device based on the determination that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types, access to the at least one of the documents.

2. The computing device of claim 1, wherein the documents comprise at least one of an advanced healthcare directive, a will, a trust document, a power of attorney, a contact list, or list of medications and allergies.

3. The computing device of claim 1, wherein the processor is further configured to receive, from the registrant device, document-level access rules associating respective documents with at least one of the designated individuals or the permitted entity types.

4. The computing device of claim 3, wherein when the requester is determined to be one of the designated individuals, the processor is further configured to authenticate the requester via data received from the requester device and, upon successful authentication, authorize access to only those documents permitted for a given one of the designated individuals under the document-level access rules.

5. The computing device of claim 3, wherein the determining that the requester is associated with one of the permitted entity types comprises the processor being further configured to perform an organizational verification comprising matching the organization to a database.

6. The computing device of claim 5, wherein the processor is further configured to authorize access to only those documents permitted for the organization under the document-level access rules and based on a type of the permitted entity types associated with the organization.

7. The computing device of claim 1, provide a lookup interface configured to allow the requester device to identify the registrant and submit the access request for at least one of the documents.

8. The computing device of claim 7, wherein the access request is granted only upon a determination that the requester device is properly authorized to access the at least one of the documents associated with the requester.

9. The computing device of claim 1, wherein the processor is configured to determine, at request time, a requester type associated with a requester device, the requester type indicative of at least one of a designated individual or an external entity.

10. The computing device of claim 9, wherein the processor is further configured to, based on the requester type, load a set of verification gates specific to the requester type from a plurality of possible sets of verification gates stored in the memory.

11. The computing device of claim 10, wherein the verification gates differ based on the requester type, wherein the verification gates comprise: for a designated individual requester type, enforcing a first set of verification gates; and for an external entity representative type, enforcing a second set of verification gates different from the first set.

12. The computing device of claim 11, wherein the second set of verification gates provides temporary-access validation to the external entity representative without a user account by matching the external entity to a database.

13. The computing device of claim 10, wherein the processor is further configured to render or reorder onboarding steps presented on a caller device based on the loaded set of verification gates, thereby selectively hiding or presenting steps per requester type based on the loaded set of verification gates.

14. The computing device of claim 1, wherein the processor is further configured to cause the registrant device to generate, at the registrant device, an encryption key.

15. The computing device of claim 14, wherein the processor is further configured to cause the registrant device to encrypt, on the registrant device using the encryption key, the at least one of the documents prior to sending or uploading the at least one of the documents to a registry server, thereby converting the at least one of the documents into at least one encrypted document.

16. The computing device of claim 15, wherein the processor is further configured to cause the encryption key to be stored on an encryption key server that is separate from the registry server.

17. The computing device of claim 16, wherein the providing, to the requester device, access to the at least one of the documents further comprises causing to be sent, to the requester device: the at least one encrypted document from the registry server; and the encryption key from the encryption key server, wherein the requester device is configured to decrypt the at least one encrypted document using the encryption key, wherein the encryption key server and the registry server never have unencrypted documents stored thereon.

18. A device comprising a non-transitory computer readable medium having instructions stored thereon that, upon execution by a processor, cause the device to: establish a profile within the registry associated with a registrant; receive, from a registrant device associated with the registrant, an upload of at least one document;store the at least one document in association with the profile; receive, from the registrant device, access selections designating each of (i) contact and demographic information of one or more designated individuals and (ii) one or more types of entities permitted to request access to the at least one document as permitted entity types; receive, from a requester device, an access request identifying the registrant for which documents are sought; determine, based on the access selections, that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types; and provide, to the requester device based on the determination that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types, access to the at least one document.

19. A method compri sing : establishing, by a processor of a computing device, a profile within the registry associated with a registrant; receiving, by the processor from a registrant device associated with the registrant, an upload of at least one document; storing, by the processor, the at least one document in association with the profile; receiving, by the processor from the registrant device, access selections designating each of (i) contact and demographic information of one or more designated individuals and (ii) one or more types of entities permitted to request access to the at least one document as permitted entity types; receiving, by the processor from a requester device, an access request identifying the registrant for which documents are sought;determining, by the processor based on the access selections, that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types; and providing, by the processor to the requester device based on the determination that the requester is one of (a) the designated individuals or (b) associated with an organization corresponding to one of the permitted entity types, access to the at least one document.

Images