CROSS-REFERENCE TO RELATED APPLICATION
This application claims the benefit of and priority to U.S. Application 5
No. 16/936,158, filed July 22, 2020. The entire disclosure of the above application is
incorporated herein by reference.
BACKGROUND
This disclosure relates generally to the field of data security and, more
specifically, to the tokenization of personally identifiable information (PII) and
personal health information (PHI). 10
There exist many situations in which individuals need to provide
sensitive data, such as PII and/or PHI, to service providers, such as customer service
representatives, bankers, health care providers, insurance claim adjusters, and the like.
However, providing this sensitive data can be tedious and redundant. Moreover, many
individuals may be uncomfortable providing their sensitive data, depending on the 15
environment. For example, an individual in a public setting may not feel comfortable
providing a credit card number or Social Security number to a service provider over
the phone.
Therefore, there is a need for a system that minimizes redundancies in
sharing sensitive data with trusted service providers and that maintains the security of 20
the sensitive data.
BRIEF DESCRIPTION
In one aspect, a data security system for enabling tokenized access to
sensitive data is provided. The data security system includes a token provisioning
computing device including a processor communicatively coupled to a memory 25
device. The token provisioning computing device is configured to initiate a secure
connection with a remote client computing device of a first data subject, and receive,
from the remote client computing device of the first data subject, a request for an
access token to provide a service provider computing device with access to sensitive
data associated with the first data subject. The request includes a data definition of the 30
3
sensitive data to which access is to be provided and one or more authorization
parameters including one or more data source identifiers of a respective one or more
data sources at which the defined sensitive data is stored. The token provisioning
computing device is also configured to generate the access token that enables access
to the defined sensitive data from the one or more data sources according to the one or 5
more authorization parameters, store the access token in a token database with the
data definition and the one or more authorization parameters, and transmit, to the
remote client computing device of the first data subject, a response including the
access token and instructions that enable the remote computing device to at least one
of display the access token to the first data subject and transmit the access token to the 10
service provider computing device.
In another aspect, a computer-implemented method for enabling
tokenized access to sensitive data is provided. The method is implemented using a
data security system including a token provisioning computing device including a
processor communicatively coupled to a memory device. The method includes 15
initiating, by the token provisioning computing device, a secure connection with a
remote client computing device of a first data subject, and receiving, by the token
provisioning computing device from the remote client computing device of the first
data subject, a request for an access token to provide a service provider computing
device with access to sensitive data associated with the first data subject. The request 20
includes a data definition of the sensitive data to which access is to be provided and
one or more authorization parameters including one or more data source identifiers of
a respective one or more data sources at which the defined sensitive data is stored.
The method also includes generating, by the token provisioning computing device, the
access token that enables access to the defined sensitive data from the one or more 25
data sources according to the one or more authorization parameters, storing, by the
token provisioning computing device, the access token in a token database with the
data definition and the one or more authorization parameters, and transmitting, by the
token provisioning computing device to the remote client computing device of the
first data subject, a response including the access token and instructions that enable 30
the remote computing device to at least one of display the access token to the first
data subject and transmit the access token to the service provider computing device.
In a further aspect, a non-transitory computer-readable storage medium
having computer-executable instructions stored thereon is provided. When executed
4
by a processor of a token provisioning computing device of a data security computing
system, the computer-executable instructions cause the processor to initiate a secure
connection with a remote client computing device of a first data subject, and receive,
from the remote client computing device of the first data subject, a request for an
access token to provide a service provider computing device with access to sensitive 5
data associated with the first data subject. The request includes a data definition of the
sensitive data to which access is to be provided and one or more authorization
parameters including one or more data source identifiers of a respective one or more
data sources at which the defined sensitive data is stored. The computer-executable
instructions also cause the processor to generate the access token that enables access 10
to the defined sensitive data from the one or more data sources according to the one or
more authorization parameters, store the access token in a token database with the
data definition and the one or more authorization parameters, and transmit, to the
remote client computing device of the first data subject, a response including the
access token and instructions that enable the remote computing device to at least one 15
of display the access token to the first data subject and transmit the access token to the
service provider computing device.
BRIEF DESCRIPTION OF THE DRAWINGS
FIGS. 1-12 show example embodiments of the methods and systems
described herein. 20
FIG. 1 is a schematic diagram illustrating a first example data security
system for enabling tokenized access to sensitive data, in accordance with the present
disclosure.
FIG. 2 is a schematic diagram illustrating a second example data
security system for enabling tokenized access to sensitive data including personal 25
health data from one or more data sources, in accordance with the present disclosure.
FIG. 3 illustrates an example user interface displayed on a client
computing device of the data security computing system shown in FIG. 1, including
generation of a data definition.
FIGS. 4-9 are swim lane diagrams illustrating implementation of a 30
tokenized data access method using components of the data security computing
systems shown in FIGS. 1 and 2.
5
FIG. 10 illustrates an example client computing device that may be
used with the data security computing systems shown in FIGS. 1 and 2.
FIG. 11 illustrates an example server computing device that may be
used with the data security computing systems shown in FIGS. 1 and 2.
FIG. 12 illustrates an example tokenized data access method that may 5
be implemented using the data security computing systems shown in FIGS. 1 and 2.
Like numbers in the Figures indicate the same or functionally similar
components.
DETAILED DESCRIPTION
The present disclosure relates to a data security computing system that
enables tokenized access to sensitive data, such as personally identifiable information 10
(PII) and/or personal health information (PHI). In particular, rather than providing
data directly to a service provider, an individual (also referred to herein as a “data
subject” or “token requestor”), who is also a subject and/or an originating source of
the PII and/or PHI, may request a token, to be securely provided to the service
provider, that enables the service provider to securely access stored PII and/or PHI 15
data associated with that individual or data subject. This process eliminates
redundancies while enhancing data security as well as data accuracy. Specifically, the
individual need not repetitively provide the same data elements to many different
services, which is tedious and time-consuming but also vulnerable to user error (either
by the individual or the service provider). The service provider uses the token to 20
access data that is both securely stored and accurately transmitted (and, in some
embodiments, accurately locally entered at the service provider).
In the example embodiment, a data subject (e.g., an individual)
registers with the data security computing system and provides their PII for secure
storage. The data subject provides their PII as one or more data elements, for 25
example, using a client computing device. The client computing device is
communicatively coupled to a centralized server computing device referred to herein
as a “secure manager.” The secure manager is configured to store PII in one or more
centralized or decentralized databases. The secure manager stores the PII in encrypted
or otherwise secured format within the database(s). As described further herein, the 30
secure manager is configured to limit access to the data stored within the databases,
6
specifically, to access defined by an access token requested and provided by the data
subject to a service provider.
In one embodiment, the client computing device is communicatively
coupled to the secure manager via a secure communication channel that is initiated in
5 a web browser or software application (“app”) environment. For example, the client
computing device stores and executes an app that initiates a secure communication
channel with the secure manager. The app may cause display of one or more screens
on the client computing device, including data entry and/or data provision screens. To
provide their PII for storage, the data subject may manually enter data elements into
their client computing device, such as via a manually fillable form. Alternatively, the 10
client computing device may automatically populate certain fields or data elements
using stored information (e.g., name, date of birth, address, etc.). The data subject
controls which data elements to provide for storage to the secure manager, and may
choose to populate fewer than all available fields. The data subject transmits the PII as
one or more data elements to the secure manager for secure storage in one or more 15
database(s). In some embodiments, PII associated with the data subject is provided to
the secure manager by other data sources (e.g., insurance companies may provide
claim details/history, banks may provide loan information, etc.). The secure manager
may additionally or alternatively store a pointer to PII that is stored in other locations
(e.g., other than the database of the secure managers). 20
The secure manager indexes the stored PII according to one or more
variables, such as a subject identifier, or any other variable that uniquely identifies the
data subject. The subject identifier may be provided by the data subject (e.g., as a
phone number or SSN), or may be automatically generated by the secure manager
during the registration phase (e.g., as a pseudo-random alphanumeric code). In such 25
cases, the secure manager returns the subject identifier to the client computing device
for storage (e.g., within the secure app environment). The client computing device
may include the subject identifier in further communications with service providers
and/or the secure manager, such that the data subject’s PII is easily retrieved using the
subject identifier. The data subject may use their client computing device to add, 30
delete, and/or modify their stored PII at any time.
In some embodiments, the data subject wishes to store and retrieve –
via access token – PHI, in accordance with the present disclosure. In some cases, the
data subject provides PHI in the same manner described above with respect to PHI.
7
Additionally or alternatively, at least one data element of PHI is stored in specific
secure database(s) managed by health care providers (HCP) or HCP networks/systems
(collectively referred to herein as “HCP data managers”). For example, a data subject
typically does not have access to their full medical record for personal storage thereof.
Rather, the HCP data managers include medical systems, hospital systems, individual 5
HCPs, and the like, and are specifically configured for management, storage, and
provision of PHI. It is recognized that in some jurisdictions, such as the United States,
PHI, such as medical records, is stored in disparate formats among various HCP data
managers. Accordingly, in such jurisdictions, there exist one or more record
integrators (e.g., EPIC, CERNER, ALLSCRIPTS, etc., which are all registered 10
trademarks of their respective owners). These record integrators manage integration
and unification of PHI, such as medical records, between a plurality of HCP data
managers, such that all HCP service providers associated with a record integrator can
access a unified, centralized record for a data subject. The record integrator may store
PHI and/or may provide an interface to access PHI stored at disparate HCP data 15
mangers.
It is further realized that stored PHI, such as medical records, may be
currently stored in unified formats in other jurisdictions, and/or a true universal
medical record (UMR) applicable to all jurisdictions may eventually be created and
used. In such cases, the record integrator described herein may not be required, and 20
direct contact with HCP data managers may be implemented without departing from
the scope of the disclosure.
A data subject may provide their PHI as one or more data elements for
storage by the secure manager and/or may select which data elements of their PHI is
available for access (e.g., by one or more service providers such as HCPs) from one or 25
more HCP data managers via an access token. The data subject may use their client
computing device to communicate with the secure manager and/or one or more HCP
data managers using a web browser and/or app environment. The data subject may
need to communicate with a plurality of HCP data managers, for example, where the
data subject has HCPs in different medical/healthcare systems. Alternatively, the data 30
subject uses their client computing device to communicate with one or more record
integrators using the web browser and/or app environment, for example, to identify
HCP data managers at which their PHI is stored.
8
In any of the above cases, the client computing device is
communicatively coupled to the “PHI receiving device” (e.g., the secure manager, the
HCP data manager(s), and/or the record integrator(s)) via a secure communication
channel that is initiated in the web browser or app environment. For example, the
client computing device stores and executes an app that initiates a secure 5
communication channel with the PHI receiving device. The app may cause display of
one or more screens on the client computing device, including data entry and/or data
provision screens. To provide their PHI for storage, the data subject may manually
enter data elements into their client computing device, such as via a manually fillable
form. The data subject controls which data elements to provide for storage to the PHI 10
receiving device, and transmits the PHI as one or more data elements to the PHI
receiving device for secure storage in one or more database(s). Alternatively, the PHI
receiving device may cause display of any/all data elements of PHI that are already
stored at and/or accessible to the PHI receiving device, such as medical records,
surgical histories, medication/prescription records, and the like. The PHI receiving 15
device may store the PHI and/or may store a pointer to a location at which the PHI is
stored (e.g., a secure manager may store a pointer to a location at an HCP data
manager). The data subject controls which stored data element(s) of PHI to make
available for later access via an access token.
The PHI receiving device indexes the stored PHI according to one or 20
more variables, such as a subject identifier, or any other variable that uniquely
identifies the data subject. The subject identifier may be provided by the data subject
(e.g., as a phone number or SSN), may be pre-existing (e.g., a UMR identifier or
electronic medical record (EMR) identifier), or may be automatically generated by the
PHI receiving device during the registration phase (e.g., as a pseudo-random 25
alphanumeric code). In such cases, the PHI receiving device returns the subject
identifier to the client computing device for storage (e.g., within the secure app
environment). The client computing device may include the subject identifier in
further communications with service providers, HCP data manager(s), and/or record
integrator(s), such that the data subject’s PHI is easily retrieved using the subject 30
identifier. The data subject may use their client computing device to add, delete,
and/or modify their stored PHI at any time.
The data subject (e.g., an individual) may wish to provide access to
their stored PII and/or PHI at a later date, to a service provider. A service provider
9
may include, for example, an insurance claims manager, a customer service
representative, a health care provider, and the like. The service provider requests
various data elements of PII and/or PHI from the data subject. For example, the
service provider may ask the data subject to verbally provide PII and/or PHI, to
physically write down their PII and/or PHI on one or more forms, or to provide PII 5
and/or PHI in electronic format (e.g., in an electronic form). The data subject may not
wish to provide that PII and/or PHI for one or more reasons. For example, the data
subject may be in a public place where verbalizing their PII and/or PHI may make the
PII and/or PHI vulnerable to being overheard. Additionally or alternatively, the data
subject may merely not wish to provide their data in such a tedious and redundant 10
fashion.

We Claim:
1. A data security system for enabling tokenized access to
sensitive data, the data security system comprising a token provisioning computing
device including a processor communicatively coupled to a memory device, the token
provisioning computing device configured to: 5
initiate a secure connection with a remote client computing device of a
first data subject;
receive, from the remote client computing device of the first data
subject, a request for an access token to provide a service provider computing device
with access to sensitive data associated with the first data subject, wherein the request 10
includes a data definition of the sensitive data to which access is to be provided and
one or more authorization parameters including one or more data source identifiers of
a respective one or more data sources at which the defined sensitive data is stored;
generate the access token that enables access to the defined sensitive
data from the one or more data sources according to the one or more authorization 15
parameters;
store the access token in a token database with the data definition and
the one or more authorization parameters; and
transmit, to the remote client computing device of the first data subject,
a response including the access token and instructions that enable the remote 20
computing device to at least one of display the access token to the first data subject
and transmit the access token to the service provider computing device.
2. The data security system of Claim 1, wherein the token
provisioning computing device is further configured to authenticate the request for the 25
access token.
3. The data security system of Claim 2, wherein the request for
the access token further includes authentication credentials input by the first data
subject to the remote client computing device during a log-in process, and wherein to 30
authenticate the request for the access token, the token provisioning computing device
is further configured to process the authentication credentials received from the
remote client computing device.
35
4. The data security system of Claim 2, wherein to authenticate
the request for the access token, the token provisioning computing device is further
configured to:
transmit an authentication request message to the remote client
computing device, the authentication request message including instructions that 5
cause the remote client computing device to prompt the first data subject to input one
or more authentication credentials into the remote client computing device;
receive, from the remote client computing device, an authentication
response message including the one or more input authentication credentials; and
process the input authentication credentials. 10
5. The data security system of Claim 1, wherein the token
provisioning computing device is further configured to:
receive a token validation request message from the service provider
computing device, the token validation request message including the access token 15
and a subject identifier associated with the data subject;
perform a lookup operation using at least one of the access token or the
subject identifier;
when the lookup operation returns a valid and active stored access
token, validate the access token; and 20
transmit a token validation response message to the service provider
computing device, the token validation response message including an indication that
the access token was successfully validated.
6. The data security system of Claim 1, wherein the token 25
provisioning computing device is further configured to:
receive a token validation request message from a record integrator
associated with a healthcare provider (HCP) data manager that stores the sensitive
data to which access is to be provided and that is identified by the data source
authorization parameter, the token validation request message including the access 30
token and a subject identifier associated with the data subject;
perform a lookup operation using at least one of the access token or the
subject identifier;
36
when the lookup operation returns a valid and active stored access
token, validate the access token; and
transmit a token validation response message to the record integrator,
the token validation response message including an indication that the access token
was successfully validated. 5
7. The data security system of Claim 1, wherein the token
provisioning computing device is further configured to:
receive a token validation request message from a healthcare provider
(HCP) data manager that stores the sensitive data to which access is to be provided 10
and that is identified by the data source authorization parameter, the token validation
request message including the access token and a subject identifier associated with the
data subject;
perform a lookup operation using at least one of the access token or the
subject identifier; 15
when the lookup operation returns a valid and active stored access
token, validate the access token; and
transmit a token validation response message to the HCP data
manager, the token validation response message including an indication that the
access token was successfully validated. 20
8. The data security system of Claim 7, wherein the token
validation response message further includes instructions that cause the HCP data
manager to transmit the sensitive data to the service provider computing device.
25
9. The data security system of Claim 1, wherein the one or more
authorization parameters further include at least one of a validity time/date parameter
or an authorized service provider parameter.
10. The data security system of Claim 1, wherein the token 30
provisioning computing device is further configured to:
receive, from the remote client computing device, data subject input
indicating a revocation of the access token; and
37
in response to receiving the data subject input, at least one of delete the
stored access token or disable the stored access token to prevent further access to the
sensitive data by the service provider computing device.
11. The data security system of Claim 1, wherein the one or more 5
authorization parameters include a validity date after which access to the sensitive
data is revoked, and wherein the token provisioning computing device is further
configured to:
upon reaching the validity date, at least one of delete the stored access
token or disable the stored access token to prevent further access to the sensitive data 10
by the service provider computing device.
12. The data security system of Claim 1, wherein the access token
is one of alphanumeric code, a bar code, and a QR code.
15
13. A computer-implemented method for enabling tokenized access
to sensitive data, the method implemented using a data security system including a
token provisioning computing device including a processor communicatively coupled
to a memory device, the method comprising:
initiating, by the token provisioning computing device, a secure 20
connection with a remote client computing device of a first data subject;
receiving, by the token provisioning computing device from the remote
client computing device of the first data subject, a request for an access token to
provide a service provider computing device with access to sensitive data associated
with the first data subject, wherein the request includes a data definition of the 25
sensitive data to which access is to be provided and one or more authorization
parameters including one or more data source identifiers of a respective one or more
data sources at which the defined sensitive data is stored;
generating, by the token provisioning computing device, the access
token that enables access to the defined sensitive data from the one or more data 30
sources according to the one or more authorization parameters;
storing, by the token provisioning computing device, the access token
in a token database with the data definition and the one or more authorization
parameters; and
38
transmitting, by the token provisioning computing device to the remote
client computing device of the first data subject, a response including the access token
and instructions that enable the remote computing device to at least one of display the
access token to the first data subject and transmit the access token to the service
provider computing device. 5
14. The method of Claim 13, wherein the request for the access
token further includes authentication credentials input by the first data subject to the
remote client computing device during a log-in process, the method further
comprising authenticating the request for the access token by processing the 10
authentication credentials received from the remote client computing device
15. The method of Claim 13, further comprising authenticating the
request for the access token, the authenticating comprising:
transmitting an authentication request message to the remote client 15
computing device, the authentication request message including instructions that
cause the remote client computing device to prompt the first data subject to input one
or more authentication credentials into the remote client computing device;
receiving, from the remote client computing device, an authentication
response message including the one or more input authentication credentials; and 20
processing the input authentication credentials.
16. The method of Claim 13, further comprising:
receiving a token validation request message from the service provider
computing device, the token validation request message including the access token 25
and a subject identifier associated with the data subject;
performing a lookup operation using at least one of the access token or
the subject identifier;
when the lookup operation returns a valid and active stored access
token, validating the access token; and 30
transmitting a token validation response message to the service
provider computing device, the token validation response message including an
indication that the access token was successfully validated.
39
17. The method of Claim 13, further comprising:
receiving a token validation request message from a record integrator
associated with a healthcare provider (HCP) data manager that stores the sensitive
data to which access is to be provided and that is identified by the data source
authorization parameter, the token validation request message including the access 5
token and a subject identifier associated with the data subject;
performing a lookup operation using at least one of the access token or
the subject identifier;
when the lookup operation returns a valid and active stored access
token, validateingthe access token; and 10
transmitting a token validation response message to the record
integrator, the token validation response message including an indication that the
access token was successfully validated.
18. The method of Claim 13, further comprising: 15
receiving a token validation request message from a healthcare
provider (HCP) data manager that stores the sensitive data to which access is to be
provided and that is identified by the data source authorization parameter, the token
validation request message including the access token and a subject identifier
associated with the data subject; 20
performing a lookup operation using at least one of the access token or
the subject identifier;
when the lookup operation returns a valid and active stored access
token, validating the access token; and
transmitting a token validation response message to the HCP data 25
manager, the token validation response message including an indication that the
access token was successfully validated and instructions that cause the HCP data
manager to transmit the sensitive data to the service provider computing device
19. A non-transitory computer-readable storage medium having 30
computer-executable instructions stored thereon, wherein when executed by a
processor of a token provisioning computing device of a data security computing
system, the computer-executable instructions cause the processor to:
40
initiate a secure connection with a remote client computing device of a
first data subject;
receive, from the remote client computing device of the first data
subject, a request for an access token to provide a service provider computing device
with access to sensitive data associated with the first data subject, wherein the request 5
includes a data definition of the sensitive data to which access is to be provided and
one or more authorization parameters including one or more data source identifiers of
a respective one or more data sources at which the defined sensitive data is stored;
generate the access token that enables access to the defined sensitive
data from the one or more data sources according to the one or more authorization 10
parameters;
store the access token in a token database with the data definition and
the one or more authorization parameters; and
transmit, to the remote client computing device of the first data subject,
a response including the access token and instructions that enable the remote 15
computing device to at least one of display the access token to the first data subject
and transmit the access token to the service provider computing device.
20. The non-transitory computer-readable storage medium of
Claim 19, wherein the access token is one of alphanumeric code, a bar code, and a QR
code.