HK1240423B - Access control for encrypted data in machine-readable identifiers - Google Patents

Description

Access control for encrypted data in machine-readable identifiers

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of and priority to co-pending U.S. Provisional Patent Application Serial No. 62/127,404, filed on March 3, 2015, and entitled “Generating Identifiers Using Encoded Health Information,” the contents of which are hereby incorporated by reference herein in their entirety.

Background Art

Machine-readable identifiers can be used to format data on a medium that can be read by a reader device (such as a barcode or matrix code scanner). However, anyone with a suitable reader can access the data embodied in the machine-readable identifier unless the underlying data is encrypted. Managing which devices can access the encrypted data in the machine-readable identifier remains a problem.

Technical Field

This disclosure relates to cryptography, machine-readable identifier technology, data security, and to some extent, computer vision.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of the present disclosure may be better understood with reference to the following drawings. The components in the drawings are not to scale, with emphasis placed on clearly illustrating the principles of the present disclosure. However, in the drawings, like reference numerals indicate corresponding parts throughout the various views.

FIG. 1 illustrates an example of a networked environment for providing access control to information collected by client applications, according to various embodiments.

FIG. 2 illustrates another example of a networked environment for augmenting and updating content data via encrypted machine-readable identifiers, according to various embodiments.

FIG3 illustrates a data structure for generating a machine-readable identifier, with portions of the data encrypted using multiple keys, according to various embodiments.

FIG4 includes a table showing the capacity of the 40-L version of the matrix code.

FIG5 includes a table showing mode indicator binary digits used for encoding data modes.

6 is a flow chart illustrating one example of a process for encrypting and encoding data in a machine-readable identifier, according to various embodiments.

7A-7N illustrate various examples of user interfaces generated by a client application according to various embodiments.

FIG8 is a pseudocode diagram illustrating one example of code for configuring a computing device or client device to generate a machine-readable identifier, according to various embodiments.

FIG9 illustrates one example of updating or augmenting data on a client device using a machine-readable identifier generated by another device, according to various embodiments.

10-12 are flow diagrams illustrating functionality of a client application executing in a client device according to various embodiments.

13 and 14 are flow diagrams illustrating the functionality of remote application programs executed in a computing environment according to various embodiments.

15-17 are schematic block diagrams providing illustrations of computing environments, client devices, and reader devices for use in the networked environments of FIGs. 1 and 2 according to various embodiments.

DETAILED DESCRIPTION

The present disclosure relates to access control for segmented data in machine-readable identifiers. Machine-readable identifiers, such as barcodes, matrix codes, or other similar identifiers, can be used to format data on a medium that is readable by a reader device, such as a barcode or matrix code scanner. Although machine-readable identifiers can be used to transfer data from one device to another without using a wired or wireless network, anyone with a suitable reader can access the data embodied in the machine-readable identifier unless the underlying data is encrypted. Because the underlying data can be sensitive, users may wish to control which portions of the underlying data can be read by various devices.

For example, in some instances, medical information may be encoded in a machine-readable identifier. People are sometimes asked to provide sensitive data that they wish to keep confidential, such as providing a medical history during a visit to a clinic. Chiropractors, holistic healthcare providers, veterinarians, urgent or emergency medical centers, dental offices, insurance companies, and the like often require medical records and other personally identifying information. If a person is unable to provide this information, family members may assume the responsibility of providing this information to healthcare providers on their relative's behalf.

While a person may wish to provide their complete medical history to their general practitioner, they may not wish to provide the complete history to another provider, such as a chiropractor or dentist. Instead, they may wish to limit the data to that relevant to the healthcare professional. Thus, in various embodiments, a single machine-readable identifier may be encoded with data, with different devices being able to read different portions of the data. For example, a person may authorize their general practitioner to obtain the complete history from a matrix code, while a chiropractor, using the same matrix code, may only be able to obtain a user-authorized subset of the history.

According to various embodiments, in contrast to the standard practice of filling out medical forms using paper and pencil, a user can use their electronic device (such as a smartphone or tablet) to provide medical intake information. Because the medical, personal, and other delicate information provided by a user via an electronic device can be sensitive, sending this information over a network can raise concerns. For example, the information can be intercepted by packet sniffing software or unauthorized access points. Furthermore, databases storing the information can be hacked. Because of this, machine-readable identifiers (such as barcodes or matrix codes) can be used to transmit information between nearby devices without using a network.

However, machine-readable identifiers often rely on open-source or transparent standards, which makes the interpretation of the data embodied in the machine-readable identifier vulnerable to unauthorized access. For example, if medical information is embedded in a matrix code, any commercially available matrix code reader can access the medical information. While the underlying data can be encrypted so that only devices with access to the appropriate key can decrypt it, sharing a single key across multiple devices prevents people from providing the full amount of information, as they may realize that any device with the key can access their information.

Thus, in embodiments described herein, access control for segmented data in a machine-readable identifier is provided. In one embodiment, a client application executable on a client device may be configured to receive, over a network, a first cryptographic key associated with a first device profile and a second cryptographic key associated with a second device profile. The client application may facilitate collecting input data from a user through an ingestion process that may include a series of user interfaces prompting the user to enter various data. Upon receiving the data, the client application may segment or otherwise format the input data into at least a first data portion and a second data portion. For example, the first data portion may be interpretable by a general practitioner's readout device, while the second data portion may be interpretable by a chiropractor's readout device.

The client application may encrypt the first data portion with a first cryptographic key and the second data portion with a second cryptographic key. A remote application, referred to herein as a key management application, may, with the authorization of a user, execute on a remote computing device, such as a server, and oversee the transmission and receipt of a key capable of decrypting the data. Alternatively, in other embodiments, the receiving device may be associated with a key in the remote computing environment. The remote application may provide the client application with the key for the receiving device, so that the information is encrypted for access by the receiving device. Ultimately, the client application may use the encrypted first data portion and the encrypted second data portion to generate a machine-readable identifier for presentation on a display accessible to the client device. The receiving device may capture one or more images of the machine-readable identifier to access the underlying data using automated image analysis and computer vision.

As a non-limiting example, a user of a client application may associate their general practitioner with a high level of access, where the general practitioner can access all input data provided by the user of the client application using their device. The key management application may send keys to the general practitioner's device as well as the user's device. Similarly, the key management application may send keys to the chiropractor's or other medical provider's device as well as the user's device. The client application may encode authorization data for the general practitioner to receive using a corresponding key, while encoding authorization data for the chiropractor to receive using a key different from the chiropractor's. Thus, access control is provided to the underlying data of a machine-readable identifier using a single machine-readable identifier.

It is understood that because there are many ways to intercept data transmitted over a network, there is a technical problem of transferring sensitive data between devices without using the network. In addition, there is a technical problem that there are many ways to obtain network-stored data (data stored on network devices) without authorization. Therefore, the embodiments described herein address this technical problem by proposing a method for transferring sensitive data between devices without using the network to transmit and receive sensitive data.

While this disclosure provides several examples in the context of healthcare data, the embodiments described herein can be applied to many industries. Furthermore, this disclosure provides examples in the context of matrix codes and other similar machine-readable identifiers. However, in some embodiments, visual image recognition can be used to identify data encoded in various image formats, such as in Clickable Paper ^™ applications for marketing.

In the following description, an overall description of the system and its components is provided, followed by a description of the operation of the system and its components.

Referring to FIG. 1 , a networked environment 100 is shown according to various embodiments. Networked environment 100 includes a computing environment 103, a client device 106, and a reader device 109, which are in data communication with each other via a network 112. In various embodiments, as will be described below, client device 106 and reader device 109 may not communicate any information with each other via network 112, except for cryptographic keys. Network 112 may include, for example, the Internet, an intranet, an extranet, wide area networks (WANs), local area networks (LANs), a wired network, a wireless network, or other suitable networks, or any combination of two or more such networks. For example, such networks may include satellite networks, cable networks, Ethernet networks, and other types of networks.

The computing environment 103 may include, for example, a server computer or any other system that provides computing power. Alternatively, the computing environment 103 may use multiple computing devices, which may be arranged, for example, as one or more server banks, computer banks, or other arrangements. Such computing devices may be placed in a single installation or may be distributed across multiple different geographical locations. For example, the computing environment 103 may include multiple computing devices, which together may include managed computing resources, grid computing resources, and/or any other distributed computing configuration. In some cases, the computing environment 103 may correspond to elastic computing resources, wherein the capacity allocated to processing, network, storage, or other computing-related resources may vary over time.

According to various embodiments, various applications and/or other functions may be executed in the computing environment 103. In addition, various data is stored in the data store 115, which is accessible to the computing environment 103. It will be appreciated that the data store 115 may represent a plurality of data stores 115. For example, the data stored in the data store 115 may be related to the operation of various applications and/or functional entities described below.

For example, components executing on the computing environment 103 may include a key management application 118, a translation service 120, a direct messaging service 122, and other applications, services, processes, systems, engines, or functions not described in detail herein. The key management application 118 may be executed to oversee the transmission and receipt of various cryptographic keys 121a...121c stored in the data store 115, as described below.

The translation service 120 may be executed to translate user input from a first language, such as Spanish, into a second language, such as English. In some embodiments, the translation service 120 may be used to translate questions stored in the computing environment 103 for the ingestion process from a first language into a second language.

The direct messaging service 122 can be used to send encrypted direct messages from one client device 106 to another over a network. In one embodiment, an application executable on a client device 106 encrypts a message generated by a user of the client device 106 and sends the encrypted message over the network 112 to the direct messaging service 122, which then transmits the encrypted message to the recipient client device 106. In one example, the direct messaging service 122 allows a patient to communicate directly with their health provider. In other embodiments, as will be described below, machine-readable identifiers can be used to transmit messages between client devices 106.

In other embodiments, the computing environment 103 may include an application or service that provides cloud-based storage of encrypted information, such as encrypted health information, although in other embodiments, the encrypted information may not be stored in the computing environment 103 .

Client device 106 represents a plurality of client devices that may be coupled to network 112. Client device 106 may comprise, for example, a processor-based system, such as a computer system. Such a computer system may take the form of a desktop computer, a laptop computer, a personal digital assistant, a mobile phone, a smartphone, a set-top box, a music player, a web-tablet, a tablet computer system, a game console, an electronic book reader, a smartwatch, or other devices with similar functionality. Client device 106 may comprise a client device display 124, and readout device 109 may comprise a reader device display 127. Client device display 124 and readout device 127 may comprise, for example, one or more devices such as a liquid crystal display (LCD) display, a gas plasma-based flat panel display, an organic light emitting diode (OLED) display, an electrophoretic ink (E-ink) display, an LCD projector, or other types of display devices.

The client device 106 can be configured to execute various applications, such as a client application 130 and/or other applications. The client application 130 can be executed on the client device 106, for example, to perform an acquisition process, thereby presenting a series of user interfaces 131a on the client device display 124 to prompt the user for user input. In one example, one or more questions are presented to the user to obtain personal information, medical information, or other appropriate information. The one or more questions can be obtained from the computing environment 103 or hard-coded in the client application 130.

The client application 130 can encrypt the user input and generate a machine-readable identifier 133 using the encrypted user input. It will be appreciated that the reader 109 uses a reader application 136 to interpret the machine-readable identifier 133 and access the encrypted user input. Using one or more cryptographic keys 121, the reader application 136 can decrypt the encrypted user input for local storage on the reader 109 or for remote storage.

In some embodiments, the client application 130 and the reader application 136 may include, for example, a browser, a dedicated application, etc., and the user interface 131 a generated by the client application 130 or the user interface 131 b generated by the reader application 136 may include a web page, an application screen, etc. The client device 106 may be configured to execute applications other than the client application 130, such as, for example, an email application, a social networking application, a word processor, a spreadsheet, and/or other applications.

The reader 109 may include a front-facing imaging device 139 or a rear-facing imaging device (not shown), such as a camera or other device capable of interpreting the machine-readable identifier 133. A reader application 136 may be executed in the reader 109 to capture one or more images of the machine-readable identifier 133 generated by the client application 130. Similarly, the client device 106 may include one or more imaging devices, such as a front-facing or rear-facing camera. In various embodiments, the reader application 136 is also executed to decrypt encrypted user input obtained from the machine-readable identifier 133 and present the health information on the reader display 127.

The readout application 136 can be configured to retain multiple versions of data provided by the user and generate an appropriate interface to facilitate navigating between specific types of data or different versions. Although the client application 130 can be configured to prohibit the transmission of medical or other types of information over the network 112, in some embodiments, the readout application 136 can communicate the data to a remote or cloud-based service (such as a HIPAA-compliant electronic health record system). Although the client application 130 may not send health or other types of information over the network 112, the computing environment 103 can back up or store the machine-readable identifier 133 of each version in the data store 115. When the user upgrades or replaces his or her client device 106, the machine-readable identifier 133 can be used to populate the data on the new client device 106.

As will be appreciated, the data stored in the data store 115 may include device data 142 and other data. The device data 142 may include information associated with one or more client devices 106 and reader devices 109. In one example, each reader device 109 may be associated with a unique cryptographic key 121, with the key management application 118 sending the cryptographic key 121 to the client application 130. The client application 130 may then generate a machine-readable identifier 133 for the reader device 109 that includes the user input data encrypted by the cryptographic key 121. Because the reader device 109 also retains its copy of the cryptographic key 121, it is able to decrypt and interpret the user input data.

In another example, each client device 106 can be associated with one or more cryptographic keys 121, where the key management application 118 sends the cryptographic keys 121 to the reader device 109 upon instruction by a user of the client application 130. The client application 130 can generate a machine-readable identifier 133 that includes user input data encrypted by the one or more cryptographic keys 121. For example, the key management application 118 can send the cryptographic keys 121 to the reader device 109 upon instruction by a user of the client application 130 so that the reader device 109 can decrypt and interpret the user input data.

The device data 142 may include a device identifier 145 that uniquely identifies the client device 106 or reader 109. The device data 142 may also include a device profile 148, which may include an access level 152. In some embodiments, a user of the client application 130 may associate a particular reader 109 with a particular access level 152. In one example, a person may associate a first reader 109 for their general practitioner with a first access level and a second reader 109 for their dentist with a second access level. To this end, the user of the client application 130 may specify which data is accessible to which reader 109 based on the access level. As will be described, user input may be segmented or divided by the information available to each reader 109. To this end, the reader application 136 may provide different access levels for information specified by the user or predetermined by the computing environment 103.

The cryptographic key 121 may include a numeric, binary, or alphanumeric string used to encrypt data. In various embodiments, the cryptographic key 121 may include a symmetric cryptographic key 121, an asymmetric cryptographic key 121, or a combination thereof.

Referring to FIG. 2 , another example of a networked environment 100 is shown according to various embodiments. In some cases, user-provided input data for a client application 130 may be manipulated on a readout device 109 or other device capable of accessing decrypted information. For example, a physician may modify the user-provided data to include updated blood pressure, weight, or other information. The user may wish to store this information on his or her client device 106 to maintain a more complete and accurate medical record.

To this end, in some embodiments, the reader application 136 may use its cryptographic key 121 (or other cryptographic keys 121 available to the client device 106) to provide updated, modified, supplemented, or otherwise manipulated data to the client device 106. The client application 130 may facilitate capturing one or more images of the machine-readable identifier 133 generated on the reader device 109 and presented in the reader device display 127.

In various embodiments, the underlying data of the machine-readable identifier 133 generated by the reader application 136 is encrypted using a cryptographic key 121, which is accessible only to the client device 106 and the reader device 109. The client application 130 can decrypt the underlying data and store the data locally on the client device 106. If the user performs a partial ingestion process, the updated data can be provided in an auto-fill field in the user interface 131. By scanning the machine-readable identifier 133 and accessing the underlying data using the appropriate cryptographic key 121, the reader application 136 can update the stored data locally and can interact with other applications (such as a scheduling application, an appointment management application, a medication refill application, or an EHR application) to update information associated therewith.

3 , an example of a data structure 300 is shown that includes data used to generate an image of a machine-readable identifier 133 a ... 133 c. It will be appreciated that the data structure 300 may include, for example, an error correction level 303, a character count indicator 306, a mode indicator 309, a payload 312, error correction 315, and/or other data.

Matrix codes, also known as Quick Response (QR) codes, typically use Reed-Solomon error correction, which is used to generate error-correcting codewords (bytes) based on the encoded data. Reading applications 136a...136b can use these error correction levels 303 to determine whether the data was read incorrectly and, if so, use the error correction codewords to correct the errors in the data. For matrix codes, there are four levels of error correction 303, designated L, M, Q, and H, with error correction capabilities of 7%, 15%, 25%, and 30%, respectively.

Matrix codes come in different sizes, with a matrix code of a particular size being referred to as a version. There are 40 available versions, but other versions are also possible and are within the scope of this disclosure. For example, version 1 is the smallest version of the matrix code, measuring 21 pixels by 21 pixels. Each version is 4 pixels larger than the previous version. Version 4 is the largest version, measuring 177 pixels by 177 pixels. The largest version has the largest character capacity, as shown in the table in Figure 4.

The payload 312 can be encoded according to different modes set by the mode indicator 309. The mode indicator 309 can include a four-bit string, as shown in Figure 5. The encoded data can begin with the appropriate mode indicator, which describes the pattern to be used for the subsequent bits. The largest version of the matrix code has the highest character capacity, as shown in the table of Figure 4. The character count indicator 306 includes the number of characters being encoded.

To generate the machine-readable identifier 133, the client application 130 (or reader application 136) may access the user input received during the ingestion process and encrypt the data using the cryptographic key 121. In embodiments where the cryptographic key 121 is asymmetric, RSA or other suitable encryption algorithms may be used. In embodiments where the cryptographic key 121 is symmetric, the Advanced Encryption Standard (AES) or other suitable encryption algorithms may be used. The encrypted user input may be encoded according to a pattern indicator 309. For example, assuming the encrypted user input is a string of alphanumeric characters, the pattern indicator 309 may be set to 0010. Alphanumeric encoding may include dividing the string into pairs and creating a binary number for each pair.

Data intended for the first reader 109a may be encrypted using a cryptographic key 121 accessible to the first reader 109a (as shown in FIG3 , cryptographic key _121A ) and encoded as payload _A. Similarly, data intended for the second reader 109b may be encrypted using a cryptographic key 121 accessible to the second reader 109b (as shown in FIG3 , cryptographic key _121B ) and encoded as payload _B. When scanned by reader 109, only a portion of payload Total may be interpreted by reader 109.

Referring next to FIG6 , a flow chart illustrating the conversion of input data into a matrix code or other machine-readable identifier 133 is shown. Beginning at step 603 , user input is accessed. The user input may include, for example, health information, emergency contact information, or other types of data obtained during the ingestion process or from the user interface 131 presented by the client application 130. In the example of FIG6 , for purposes of explanation, a string of user input includes "Hello world."

In step 606, a cryptographic key 121 is identified based on the reader 109 for which the data is to be used. For example, a user may designate a particular portion of their medical history for use by their general practitioner. The cryptographic keys 121 for one or more of the general practitioner's readers 109 may be identified. In step 609, the user input is encrypted using the cryptographic key 121 identified in step 606. Using AES encryption and the key "exampleencryptionkey," the encrypted data string includes "BBd2iHwO/gy+xnFUg6HeAA==".

Next, in step 612, the encrypted data is encoded using an alphanumeric pattern or other suitable pattern (such as numbers, bytes, Japanese kanji, or ECI). For the first two characters of the encrypted data, "BB," the alphanumeric encoding is used to generate the binary digits "111111010." This process can continue until all the encrypted data has been encoded using the appropriate pattern. Finally, in step 615, a matrix code image is generated using the encoded data as the payload according to the matrix code standard.

In various embodiments, the AES-256 encryption algorithm may be used to encrypt the underlying data. An initialization vector (IV) or starting variable (SV) may be used to randomize the encryption and produce different ciphertexts even when the same plaintext is encrypted multiple times (AES CBC Pkcs7). Some modes, such as Electronic Codebook (ECB) and Cipher Block Chaining (CBC), may require padding of the final block before encryption, so appropriate padding may be used.

In an embodiment employing AES-256, the cryptographic key 121 may comprise 256 bits (32 bytes), with the IV being 128 bits (16 bytes). For each encryption performed by the client application 130 or the reader application 136, a randomly generated IV may be generated to provide a different encryption result (different from the previous encryption), even if the data to be encrypted has not changed. The generated IV may be stored locally on the client device 106 or the reader device 109 along with the encrypted data for future decryption purposes, as described herein.

In some embodiments, the encrypted data is stored locally on the client device 106 or reader 109 in association with the password, biometric data, or PIN code. In addition, each user or entity for which data is provided (e.g., patient, relative, pet) may have his or her own cryptographic key 121 (i.e., encryption key). Thus, any data encrypted on a particular device can only be decrypted on that device when the appropriate password, biometric data, or PIN code is provided.

Because the AES encryption algorithm requires cryptographic key 121 and the IV to encrypt or decrypt data, the IV can be stored in conjunction with the encrypted data to facilitate successful decryption in the future. In some embodiments, key management service 115 manages the storage and transmission of the IV and cryptographic key 121 to client device 106 or reader 109. The IV key may comprise 16 bytes or another suitable length. In some embodiments, the IV key can be split and stored in predefined locations along cryptographic key 121. For example, a first number of bytes of the IV key may be placed at a first location in cryptographic key 121, while a second number of bytes of the IV key may be placed at a second location in cryptographic key 121, and so on. The IV key can be removed from cryptographic key 121 before use. This feature adds an additional level of security to the encrypted data. For example, even if cryptographic key 121 is intercepted, successfully guessed by brute force, or otherwise, without knowing how to recover the IV from the data, decrypting the encrypted data would be difficult, if not impossible.

7A through 7N illustrate various examples of a user interface 131 for a client application 130 for executing an ingestion process by prompting the user with various types of user input. It will be appreciated that prior to executing the ingestion process, the user may be required to provide a username, password, biometric information, or other information that appropriately identifies the user of the client device 106. In FIG7A , an exemplary home screen for the client application 130 is shown, where the user may enter basic information for an individual. This may not include medical information, but rather information for identification purposes. This may be used to identify the name of an individual (e.g., an owner, dependent, pet, or other individual).

Next, the client application 130 may prompt the user to enter basic information, such as date of birth, emergency contact information, primary care physician contact information, or other basic information. The user interface 131 may also allow the user to change the individual for whom information is being provided. For example, the user may change the individual from themselves to another individual, such as a child, dependent, pet, etc. These secondary profiles will also have data fields for information about primary care physicians, emergency contact information, medical records, etc.

FIG7B illustrates an embodiment of a Health Insurance Portability and Accountability Act (HIPAA) compliance and document user interface 131. According to this user interface 131, information related to various regulations (such as HIPAA) is presented, followed by appropriate explanations for obtaining necessary approvals. In various embodiments, a link or other user interface component may be generated that causes another application (such as a browser application) to display the information for those who require further explanation of the compliance details. After review, a prompt for an electronic signature and a date or time stamp may appear to verify that the user has reviewed the material and obtained the necessary approvals.

Turning now to FIG. 7C , a user interface 131 illustrates one embodiment of a screen dedicated to obtaining an individual's past medical information. The user interface 131 of FIG. 7C enables a user to provide medical diagnoses that medical professionals have given them in the past. In various embodiments, smart text, auto-fill, drop-down suggestions, and/or other similar components may be included to correct spellings for the most common conditions and/or diseases. The client application 130 may also obtain data related to the date the diagnosis was given. These may then be arranged in numerical order based on the date. In the event that a diagnosis is not listed, a free text option may be available. Additional text boxes may be created for additional, potentially important information.

FIG7D illustrates a user interface 131 in which past surgical information is available by prompting the user to provide all previous surgical records. As noted above, in various embodiments, smart text, auto-fill, drop-down suggestions, and/or other similar features may be included to facilitate correct spelling for most common surgical or medical procedures. The dates and institutions of these procedures, if known, may also be available. The procedures are then arranged in chronological order with associated data fields for the date and institution where the procedure was performed. In the event that a procedure is not listed, a free text option may be provided.

7E , which shows a user interface 131 , which shows an embodiment of a screen dedicated to obtaining current and past medications, enabling a user to provide current or previous medications. In various embodiments, smart text, auto-fill, drop-down suggestions, and/or other similar components may be included to facilitate correct spelling of most common medications. The date when the medication was started, the reason for taking the medication, and the dosage and frequency of taking the medication may be included. In the case of an old medication that the user is no longer taking, a field for the date the medication was stopped will be included with the reason why it was stopped. In the case where a medication is not listed, a free text option may be available.

FIG7F shows a user interface 131 where a user can provide current and past allergies, medications, environmental triggers, animals, and other related information. In various embodiments, smart text, auto-fill, drop-down suggestions, and/or other similar features can be included to facilitate correct spelling for most common medications and allergens. The type of reaction to the allergen will also be included. These will be arranged in numerical order with a corresponding field for the type of reaction to each allergen.

In the non-limiting example of Fig. 7G, user interface 131 is shown, which enables a user to provide information related to her or his family medical history. In some embodiments, detailed common clinical questions can be presented to the user to suggest whether they are applicable to family medical history. Suitable data fields can be used for uncommon diseases. In addition, smart text, automatic filling, drop-down suggestions and/or other similar components can be included to correct the spelling of common diseases and/or diseases. If applicable, the user can also describe which family member has the diagnosis by age and year of death.

FIG7H illustrates an embodiment of a user interface 131 specifically for obtaining a social history from a user. For example, a form may be presented to the user providing information related to an individual's social history. In some embodiments, the form includes fields for data covering smoking history, alcohol consumption, foreign travel, education, etc. Based on the age estimated from the previously provided date of birth, this may also include detailed pediatric information such as household members, household firearms, household pets, and exposure to lead and tuberculosis.

Referring now to FIG. 7I , user interface 131 illustrates an embodiment of obtaining immunizations from a user. Smart text may be employed to assist the user in correctly spelling immunizations. Open text fields may be provided for immunizations not typically administered that may be required for international travel. In some embodiments, the date the immunizations were provided may be a required field. The information may be arranged in chronological order based on the date of the immunization.

FIG7J illustrates one embodiment of a user interface 131 that enables a user to provide miscellaneous notes that may be saved locally only for user access, or may be included in the machine-readable identifier 133. For example, a note may include a reminder about a particular medical experience. In various embodiments, this may be limited to 100 characters or another suitable amount, and is not a list of symptoms, but merely a reminder of a particular visit. As with any other section, if the information does not need to be updated, the note page may be left empty. In some embodiments, the data provided in the note field may be excluded from the data in the machine-readable identifier 133.

FIG7K shows another diagram of a client device 106 generating a user interface 131 in the client device display 124. In the non-limiting example of FIG7K , the illustrated embodiment provides the user with information previously provided to the user. It will be appreciated that in embodiments where health information is obtained, information about one or more of eleven organ systems may be ideally obtained. The user interface 131 may facilitate printing or delivering an information package to a physician or other relevant personnel in a format predefined by the user, administrator, or specified by a healthcare provider. This allows information to be associated in a format that is more preferred by the physician and is easily readable by both the owner and the physician. In other examples, the user interface 131 may receive information related to the patient's pharmacy, insurance, or other relevant entities. This intake process may include a review of the body systems as well as health screenings.

Furthermore, the client application 130 can organize the information provided during the ingestion process in a predefined format. In one example, the information can be sorted by date and time and categorized by subject matter (such as allergies or medications). For embodiments in which the information is medical data, a chronological format common to healthcare providers provides an efficient way to present the data obtained by the client application 130. This will provide all the health information specified by the healthcare provider. Because the information provided can be complete and accurate, it helps limit medical errors by correctly identifying medications and allergies, as well as providing a complete medical record that is proven necessary for doctors and providers.

Prior to being encrypted by the client application 130, the data may be formatted and/or compressed, or the reader application 136 may format the data while being decrypted and/or decompressed. Thus, either the client application 130 or the reader application 136 may format the data into a predefined format, such as the Clinical Document Architecture (CDA) format, which includes a flexible tagging standard developed by HealthLevel 7 International. The CDA format includes predefined structures for certain medical records, such as discharge summaries and progress notes, to facilitate the exchange of information between patients and healthcare professionals. The CDA format allows for the inclusion of text, images, and other types of multimedia (such as audio and video). In another embodiment, the format may be specified by a healthcare provider via the reader application 136.

In various embodiments, the client application 130 can export the information summary to a Microsoft or other suitable format for the user to print at the healthcare provider's office or prior to a visit. In some embodiments, the machine-readable identifier 133 can be placed in a corner of the generated document or in another suitable location. Using the reader 109, the healthcare provider can scan the machine-readable identifier 133 from the client device display 124 or document, depending on the practices of the particular practice, to import the information into a chart or electronic health record (EHR). It will be appreciated that while the client application 130 can be configured to encrypt the health information before generating the machine-readable identifier 133, the healthcare provider's reader 109 can decrypt the information provided by the machine-readable identifier 133. Thus, for example, while sitting in an office, a user of the client application 130 can bypass the lengthy process of filling out a medical intake form. Because the information provided by the user can be updated by the healthcare professional, it helps limit medical errors by correctly identifying medications and allergies, and provides a complete medical record that is proven necessary for the physician.

The client application 130 may include a mobile application or a web-based application accessed through a browser application. An individual using the web-based application can convert the summary information into a format for the owner to print before the visit and delete the information when the visit is over. In the corner of the printout, the relevant machine-readable identifier 133 may be shown.

Based on the judgment and ability of the health care provider, another embodiment specifies that the client application 130 generates an email with an attachment of information and/or machine-readable identifier 133 to send an email to the health care provider, staff or health system and share it electronically. The owner can complete it at home or when in the waiting room of the health care provider before the visit. The format of the information will be the format that the health care provider prefers. From this point of view, it can be printed to be added to the patient's paper table, scanned or manually entered into the electronic medical record. Finally, it can be electrically linked to an EHR or proprietary electronic medical record (EMR) system. Before electronically sharing this information, the owner can be required to review HIPAA regulations and electronic signatures and date/time stamps again to review this information.

Turning now to FIG7L , a machine-readable identifier 133 is shown with user input provided during the capture process. By saving the encrypted image to the lens or camera of the reader 109, the encrypted health information can be transferred for interpretation by the reader 109. In some embodiments, a dependent can transfer his or her information to a parent's client device 106, or vice versa, by capturing an image of the machine-readable identifier 133. When the necessary permissions are obtained, the key management application 118 facilitates the transfer of the appropriate cryptographic key 121.

7M , a user of a client application 130 can specify a recipient of the cryptographic key 121 and the data (such as the owner of a reader device 109 or a different client device 106). In other embodiments, the cryptographic key 121 can be pseudo-randomly generated by the client application 130 or the key management application 118. If generated by the client application 130, the cryptographic key 121 is transmitted to the key management application 118, which in turn communicates the cryptographic key 121 to the reader device 109 or other client devices 106 according to the instructions of the user of the client application 130. For example, a user of a client device 106 can associate the cryptographic key 121 transmitted to one or more reader devices 109 with the "Atlanta Health" provider. In other embodiments, predefined cryptographic keys 121 are used based on the selection of a provider. For example, the key management application 118 can store one or more cryptographic keys 121 for the "Atlanta Health" provider. When “Atlanta Health” is selected, the client application 130 may encrypt information for use in the machine-readable identifier 133 using one or more cryptographic keys 121 stored in association with the “Atlanta Health” provider.

In other embodiments, the cryptographic key 121 may be set to a date of birth, a social security number, or other constant that is not widely or publicly available. Any healthcare provider with access to the software necessary to read and transmit the information represented by the encrypted QR image may then be allowed to instantly extract the user input electronically and wirelessly. In some embodiments, an additional layer of security may be employed in which the recipient of the information may be required to enter another identifier for the original user, such as a date of birth or a social security number, before the information will be decrypted.

The process of extracting information can be accomplished by saving the machine-readable identifier 133 to a reader device 109 or a camera lens of another client device 106 owned by a healthcare provider or other relevant personnel. It will be appreciated that this can be accomplished by personnel in the administrative department in a minute or less. The obtained information can then be used by a reader application 136 or other applications on the reader device 109 to be added to the patient's paper chart or electronic medical record system. Furthermore, the reader application 136 can be configured to automatically populate fields in a third-party EMR system.

Referring now to FIG7N , the client application 130 can facilitate sending encrypted messages from one client device 106 to another. In one example, the client application 130 allows a patient to communicate directly with his or her health provider. The client application 130 can encrypt a message generated by a user of the client device 106 and send the encrypted message to the direct messaging service 122 via the network 112. The direct messaging service 122 can then transmit the encrypted message to the recipient client device 106. In other embodiments, a machine-readable identifier 133 can be used to transmit messages between client devices 106. The client application 130 can also facilitate the transmission of the machine-readable identifier 133 via the direct messaging service 122.

Turning now to FIG. 8 , pseudocode 800 is shown that can be executed when configuring the client application 130, the reader application 136, or other suitable application to generate a matrix code or other type of machine-readable identifier 133. For example, the function in line 01 of the pseudocode can be called programmatically to generate a matrix code. Line 02 receives user input to be included in the machine-readable identifier 133, such as user input provided during the ingestion process performed by presenting the user interface 131 of FIG. 7A through FIG. 7K . Because the user input is stored locally on the client device 106, it can be appropriately queried.

In line 03, a cryptographic key 121 is obtained using an appropriate function call. In the embodiment of FIG8 , the cryptographic key 121 is obtained based on an identifier provided for a particular reader 109. For example, a user of the client application 130 may specify the intended recipient of the data. In other embodiments, the user may specify their own cryptographic key 121. In other embodiments, the cryptographic key 121 may be pseudo-randomly generated or determined using a date of birth, social security number, or other user-provided information.

In line 04, a mode indicator 309 is established. In the example of FIG8 , the mode indicator is set to "0010," which indicates alphanumeric mode. In line 05, the character count of the input data is determined. In line 06, a function call is made to implement an appropriate function that encrypts the user input using the cryptographic key 121 and returns an encrypted string or other appropriate variable type. In line 07, a Reed-Solomon error code is determined using an appropriate function call. In lines 08-09, the data is formatted. In line 10, the formatted data is provided as an argument to a programmable function call to generate a machine-readable identifier 133 in an image or other appropriate format.

Turning now to FIG. 9 , another example of a client application 130 importing data from an external source is shown. As described above, in some cases, the input data provided by the user of the client application 130 can be manipulated on a reader device 109 or other device capable of accessing decrypted information. For example, a physician may update or modify the data to include the latest blood pressure reading, weight measurement, blood sugar level measurement, or other information. The user may wish to store this updated information on his or her client device 106 to maintain a more complete and accurate medical record. In some embodiments, the reader application 136 may generate a document 900 that can be printed for insertion into a physical medical file.

The reader application 136 can use its cryptographic key 121 to generate a document 900 having machine-readable identifiers 133a...133b. The key management application 118 can provide the client device 106 with the appropriate cryptographic key 121 based on the reader device 109 or other device that generated the machine-readable identifier 133. The client application 130 can facilitate capturing one or more images of the machine-readable identifier 133 located on the document 900. Once the image of the machine-readable identifier 133 is obtained and decrypted on the client device 106, the client device 106 can update locally stored information and/or automatically populate fields in the user interface for user review.

In various embodiments, the underlying data of the machine-readable identifier 133 generated by the reader application 136 is encrypted using a cryptographic key 121, which is available only to the client device 106 and the reader device 109. The client application 130 can decrypt the underlying data and store the data locally on the client device 106. If the user completes a portion of the ingestion process, the updated data can be provided in an auto-fill field in the user interface 131.

Multiple security mechanisms are built into the code and execution of the client application 130. Because of the breadth of potentially critical information, in various embodiments, this information is stored locally on the client device 106. Thus, the potential loss of this information via the "cloud" can be reduced or eliminated. In various embodiments, the client application 130 can integrate with cloud-based systems for remote input and updating of information.

In addition to the default password protection provided on a smartphone or other type of client device 106, an additional password or personal identifier number (PIN) is required to access features of the client application 130. A predefined number of consecutive incorrect passwords (e.g., 5) will disable the use of the client application for a predefined period of time, such as 24 hours. Before the information can be shared electronically, an additional identifier is required indicating the owner's permission to share the information.

In various embodiments, a healthcare provider who is permitted to withdraw information from a machine-readable identifier 133 may also be permitted to update or augment the information and provide the updated or augmented information back to the owner in the form of another machine-readable identifier 133. Thus, the updated information may be reconciled with information already present on the client device 106. In this manner, the owner will not have to enter new information, as this will be accomplished by the client application 130. This may also include incorporating reminders from the mobile device calendar for future visits, medication refills, and the like. In another example, the client application 130 may electronically coordinate medication therapy with a pharmacy.

The client application 130 may be implemented in multiple versions, each in a different language, such as English, Spanish, French, or other languages. If necessary, the translation service 120 can translate user input from the user's language to the recipient's language. This can occur before encoding the data in the machine-readable identifier 133, or once the reader application 136 decodes the information. This information can be used to assist in medical or other types of assessments, for those situations where more advanced communication or English medical terminology is unknown.

In one embodiment, the machine-readable identifier 133 may be encoded in a "lock screen" of the client device 106 so that a person without access to the phone can obtain important identification, health, or contact information without having to unlock the client device 106. In other embodiments, the information provided during the capture process may be periodically erased on the client device 106 or on the reader 109 (e.g., at the end of the session).

Continuing with FIG10 , a flowchart is shown that provides an example of the operation of a portion of the client application 130 according to various embodiments. It will be appreciated that the flowchart of FIG10 provides only one example of a plurality of different types of functional arrangements that may be used to perform the operation of the portion of the client application 130 as described herein. Alternatively, the flowchart of FIG10 may be viewed as an example of elements of a method performed in the client device 106 according to one or more embodiments.

Beginning at step 1003, the client application 130 is executed to obtain information, such as health information, from the user for one or more individuals (such as dependents, pets, or other animals). This may be accomplished using the user interface 131, which is then presented during an ingestion process, during which the user cycles through the user interface 131 during one or more sessions. Then, in step 1006, the client application 130 inquires with the user whether or not the HIPAA notification has been acknowledged. If the HIPAA notification has not been acknowledged, the HIPAA notification may be presented to the user, and the steps may return to 1003 or continue to the end. If the user has acknowledged the HIPAA notification, the steps proceed to 1009, where the basic information, health information, or other information provided by the user is encrypted according to one or more predefined encryption standards and formats.

In various embodiments, data is encrypted using one or more cryptographic keys 121. In various embodiments, cryptographic keys 121 include user-provided information, such as date of birth, first name, last name, social security number, a combination thereof, or other potentially unique information. At 1012, the encrypted information is used to generate a machine-readable identifier 133, such as a QR code or matrix code. The steps for generating a machine-readable identifier are described with reference to Figures 6 and 8.

10 , in step 1015, the user may be prompted with an additional notification asking if the user wishes to display the generated machine-readable identifier 133 on the client device display 124. Finally, in step 1018, the machine-readable identifier may be encoded in the user interface 131 for presentation on the client device display 124. At this point, the user can provide the machine-readable identifier 133 for scanning by the reader 109, or the user can print a document containing the information and having the machine-readable identifier 133 thereon.

11 , a flowchart is shown that provides another example of the operation of a portion of the client application 130 according to various embodiments. It will be appreciated that the flowchart of FIG11 provides only one example of a plurality of different types of functional arrangements that may be used to perform the operation of the portion of the client application 130 as described herein. Alternatively, the flowchart of FIG11 may be viewed as an example of elements of a method performed in the client device 106 according to one or more embodiments.

Beginning at step 1103, a client application 130 executable on a client device 106 may be configured to access a first cryptographic key 121a associated with a first device profile 148a. Similarly, at step 1106, the client application 130 may access a second cryptographic key 121b associated with a second device profile 148b, received via the network 112. It will be appreciated that the first and second cryptographic keys 121a, 121b may be sent to the client device 106 via the network 112 by a key management application 118 or other similar service. The first and second cryptographic keys 121a, 121b may be provided to the client application 130 in response to a selection by an entity or organization, such as a medical institution or medical professional. In one example, the first cryptographic key 121a is associated with a first medical provider. The first medical provider may own or operate a first reader device 109a associated with the first device profile 148a and having the first cryptographic key 121a stored thereon. Similarly, the second cryptographic key 121b is associated with a second medical provider, whereby the second medical provider may own or operate a second reader device 109b that is associated with a second device profile 148b and has the second cryptographic key 121b stored thereon.

Because the client application 130 facilitates collecting input data from the user through an ingestion process, the input data can be accessed for inclusion in the machine-readable identifier 133 in step 1109. The ingestion process can include a series of user interfaces 131 that prompt the user to enter various data, such as those shown in Figures 7A through 7K. In step 1112, the client application 130 can segment, partition, or otherwise format the input data into at least a first data portion and a second data portion. For example, the first data portion can be interpreted by a general practitioner's device, while the second data portion can be interpreted by a chiropractor's device.

Next, in step 1115, the client application 130 may encrypt the first data portion using the first cryptographic key 121a, while in step 1118, the client application 130 may encrypt the second data portion using the second cryptographic key 121b. A key management application 118 operating in the computing environment 103 may oversee the transmission and receipt of cryptographic keys 121 capable of decrypting data with the user's authorization. Alternatively, in other embodiments, the reader 109 may be associated with a predefined cryptographic key 121 stored in the data store 115 of the computing environment 103. The key management application 118 may provide the client application 130 with the cryptographic key 121 for a particular reader 109, thereby encrypting the information for access by the reader 109 or other client devices 106.

In step 1121, client application 130 may use the decrypted first data portion and the decrypted second data portion to generate a machine-readable identifier 133 for presentation on client device display 124. Reading device 109 may capture one or more images of machine-readable identifier 133 to access the underlying data.

In other embodiments, a user of the client application may associate a device profile 148 (such as one associated with a general practitioner) with a high level of access, enabling the general practitioner to use his or her device 109 to access all or a substantial amount of input data provided by the user of the client application 130. The key management application 118 may send a cryptographic key 121 to the general practitioner's reading device 109 and the user's client device 106. Similarly, the key management application 118 may send a different cryptographic key 121 to the reading device 109 of a chiropractor or other medical provider. The client application 130 may encode authorization data for receipt by the general practitioner using the cryptographic key 121 corresponding to the general practitioner's reading device 109, while simultaneously encoding authorization data for receipt by the chiropractor using a different cryptographic key 121 for the chiropractor's reading device 109. To this end, a single machine-readable identifier 133 is used to provide access control to the data underlying the machine-readable identifier 133. The program then terminates.

In some embodiments, a first access level 152a associated with the first data portion can be defined. For example, a user can associate a desired low access level 152 with their personal information and a desired high access level 152 with their medical records. Reading devices 109 associated with the high access level 152 can access both the medical records and the personal information, while reading devices 109 associated with the low access level 152 can only access the personal information. In one example, based on authorization by the athlete or parent, a child's coach can grant a low access level 152 to a client device 106 for accessing the athlete's emergency contact information.

In other words, the access level 152 can be used to determine which portion of the data the reader 109 can access. The user can also define, through the client application 130, which entity (such as a medical institution) has access to the data associated with each access level 152. To this end, a first access level 152a associated with a first portion of data and a second access level 152b associated with a second portion of data can be identified, where the first portion of data will be decrypted using the first cryptographic key 121a based at least in part on the first access level 152a, and the second portion of data will be decrypted using the second cryptographic key 121b based at least in part on the second access level 152b. It will be appreciated that the first access level 152a can be different from the second access level 152b.

Continuing with FIG12 , a flowchart is shown that provides another example of the operation of a portion of the client application 130 according to various embodiments. It will be appreciated that the flowchart of FIG12 provides only one example of a plurality of different types of functional arrangements that may be used to perform the operation of the portion of the client application 130 as described herein. Alternatively, the flowchart of FIG12 may be viewed as an example of elements of a method performed in the client device 106 according to one or more embodiments.

Beginning at step 1203, the client application 130 may identify a machine-readable identifier 133 in an image captured by a camera or other imaging device in communication with the client device 106. For example, the machine-readable identifier 133 may be one generated by the reader 109 to provide updated, supplemental, or other operational data that was initially provided by a user of the client application 130 using an initial machine-readable identifier 133 generated after the capture process was complete. It will be appreciated that data modified by the reader 109 may be obtained from the initial machine-readable identifier 133 generated on the client device 106. An image of the machine-readable identifier 133 may be obtained by the client device 106 to update its locally stored data. The image may be captured from the reader display 127, as shown in FIG. 2 , from the display of another client device 106, or from a document 900, as shown in FIG. 9 .

Next, in step 1206, the machine-readable identifier 133 is decoded to identify the volume of encrypted data. In step 1209, the client application 130 may decrypt the volume of encrypted data using the cryptographic key 121 associated with the device configuration file 148 from the original device from which the machine-readable identifier 133 was obtained. In some embodiments, the volume of data read from the machine-readable identifier 133 may be public (unencrypted) and identify the reading device 109 from which the machine-readable identifier 133 was obtained, wherein any device may decode the volume of data. The volume of data may include the device identifier 145 and/or a unique identifier that identifies a person or client device 106 authorized to access the encrypted data. If the client device 106 is so authorized, the client application 130 may communicate the device identifier 145 to the computing environment 103 to obtain the cryptographic key 121.

In step 1212, the decrypted data obtained from the machine-readable identifier 133 can be used to update or supplement the data stored locally on the client device 106. In some cases, the decrypted data may conflict with the user-provided data. For example, some of the data provided by the user to the readout device 109 via the first machine-readable identifier 133 may have been altered. Alternatively, the user-provided data can be augmented with a reading taken by a physician that was previously unknown to the user.

Thus, in step 1215, client application 130 determines, for example, through an ingestion process, whether there is a conflict between the decrypted data and the user-provided data. For example, if the data provided by the user using his or her client device 106 differs in any way from the data returned by reader 106, the data may conflict. For example, using reader 109, a doctor or nurse can update the user-provided data to reflect the most recent reading or measurement. Alternatively, using reader 109, a doctor or nurse can augment the user-provided data. In either case, when the two sets of data differ, a conflict between the data is identified. A DIFF function or similar function can be employed to identify the specific portion of the data where the conflict exists.

If a conflict exists between the data, the process proceeds to step 1218 to reconcile or otherwise resolve the data conflict. In some embodiments, information regarding the conflict may be presented to the user, where the user may choose to retain the original data provided by the user or update the data with the data provided by the reader 109. In other embodiments, the data provided by the reader 109 may automatically replace the data provided by the user or be automatically added to the memory of the client device 106 to augment the data provided by the user during the ingestion process.

In some examples, portions of the data may be associated with different access levels 152, with different access levels being associated with specific types of data. For example, if a medical provider updates medical data stored on a client device 106, the user may be more compliant with the medical provider because the medical provider may have been assigned a high access level 152 by the user (or by default). In another example, if the medical provider updates personal information (such as a phone number or address) for a user of the client device 106, the user may be more compliant because the user may be more familiar with their own phone number and address. In other words, the medical provider may have a high access level 152 for medical information and a low access level 152 for personal information.

Alternatively, if no data conflicts exist, the process proceeds to step 1221, where, during future ingestion processes, the fields in the user interface 131 may be automatically populated with data obtained from the machine-readable identifier 133. Thereafter, the process terminates.

Referring to FIG13 , a flowchart illustrating an example of the operation of a portion of the key management application 118 according to various embodiments is shown. It will be appreciated that the flowchart of FIG13 provides only one example of a plurality of different types of functional arrangements that may be used to perform the operation of the portion of the key management application 118, as described herein. Alternatively, the flowchart of FIG13 may be viewed as an example of describing elements of a method performed in the computing environment 103 according to one or more embodiments.

Beginning at step 1303, a selection of an entity (such as a healthcare provider) is received from the client device 106, where the selection is made in the client application 130. For example, a user may specify an entity with which he or she wishes to share input data provided during an intake process. In one example, the user may select the "Atlanta Health" provider in the user interface 131 generated by the client application 130. "Atlanta Health" may own or operate one or more readout devices 109 associated with one or more device profiles 148 stored in the data store 115.

In some examples, the device profile 148 corresponding to the entity or the reader 109 operated by the entity may have a predefined cryptographic key 121 stored in the data store 115. However, in step 1306, a cryptographic key 121 may be generated for the device profile 148, for example, to create a cryptographic key 121 unique to the user-entity relationship. It will be appreciated that step 1306 is optional. In some examples, the cryptographic key 121 is pseudo-randomly generated using information provided by the user or a combination thereof.

Next, in step 1309, the cryptographic key 121 is sent to the client device 106, thereby enabling the client application 130 to encode the input data for receipt by the reader device 109 associated with the device profile 148. If the reader device 109 does not have the cryptographic key 121 stored thereon, then in step 1312, the cryptographic key 121 may be sent to the reader device 109 (if necessary).

Referring to FIG14 , a flowchart illustrating another example of the operation of a key management application 118 according to various embodiments is shown. It will be appreciated that the flowchart of FIG14 provides only one example of a variety of different types of functional arrangements that may be used to perform the operation of portions of the key management application 118, as described herein. Alternatively, the flowchart of FIG14 may be viewed as an example of elements of a method performed in the computing environment 103 according to one or more embodiments.

In some embodiments, the machine-readable identifier 133 may include unencrypted data or data that can be decrypted using a global or shared cryptographic key 121. The data may include a first device identifier 145a for the originating device and a second device identifier 145b for the intended recipient. For example, the client application 130 may generate a machine-readable identifier 133 that includes a first device identifier 145a for the client device 106 that generated the machine-readable identifier 133a and a second device identifier 145b for the intended recipient's reader device 109 that is associated with a particular entity, such as a selected medical provider.

When the reader device 109 scans the machine-readable identifier 133, it can determine whether it can access the underlying data by analyzing the first device identifier 145a or the second device identifier 145b of the intended recipient. In other examples, the reader device 109 can communicate the device identifier 145 to the key management application 118 for remote authorization. To this end, in step 1403, the key management application 118 can receive the first device identifier 145a of the device that generated the machine-readable identifier 133. Similarly, in step 1406, the key management application 118 can receive the second device identifier 145b of the device that is intended to access the underlying data of the machine-readable identifier 133.

Using the first device identifier 145a and the second device identifier 145b, the key management application 118 may determine in step 1409 whether the initial user (e.g., the user of the client application 130 or a medical provider) has authorized the device requesting the cryptographic key 121 to decrypt the underlying data of the machine-readable identifier 133 to access the underlying data. If the requesting device is authorized to access the underlying data, then in step 1412, the key management application 118 may send the cryptographic key 121 to the device, where the cryptographic key 121 is capable of decrypting the data encoded in the machine-readable identifier 133. Thereafter, the process terminates. Referring back to step 1409, if the requesting device is not authorized to access the underlying data of the machine-readable identifier 133, the process terminates.

The applications described herein, such as the client application 130, the readout application 136, and the key management application 118, provide the ability to efficiently obtain, store, and copy important information, such as information needed during an initial or subsequent visit to a healthcare provider. In particular, the present disclosure describes a client application 130 for obtaining medical records in an easy-to-use manner and generating a machine-readable identifier 133 that includes the resulting medical record as encoded and encrypted data. In various embodiments, information provided by a user through the client application 130 can be stored locally on the client device 106. Information stored on the client device 106 can be encrypted for local storage. In addition, any changes to the health history can be easily identified and provided to the provider during follow-up visits.

Today, existing health-related applications focus on helping individuals improve their ability to take responsibility for their own care, promote healthy living, and link to electronic medical record systems for providers or institutions to obtain test and laboratory results. These applications include varying degrees of daily, or preferably weekly, data points that need to be updated to demonstrate the usefulness of the client application 130.

The client application 130 and the reader application 136 can be executed on the Microsoft Windows® and/or other suitable operating systems. The information obtained by the client application 130 only needs to be provided once by the user and is only updated for major and relevant changes (e.g., medication changes, surgical procedures), which are only necessary infrequently for most patients. In addition, the client application 130 allows the user to provide important information to dependents or others for whom the user is responsible. As can be appreciated, the value of basic information provided easily and correctly is enormous.

According to various embodiments, a focused, easily maintained, proprietary account of basic medical information is obtained that is needed by healthcare providers and other entities to provide necessary routine care. This information is generated by the physician with the physician in mind, but is created for easy navigation of the system. The workflow is created in a way that any individual with only a basic literacy level can complete the navigation. In various embodiments, the breadth of information required by the user can be centered around a predetermined number of questions (e.g., 7 questions or other number) that are important for all initial visits to any healthcare provider. In various embodiments, these questions can be specific and not infinite.

The client application 130 generates a series of one or more user interfaces 131 to obtain information from the user. In addition, the client application 130 associates the information in a form that is easy and readable for both doctors and patients. This also allows for efficient transmission of basic medical information between various providers (such as general practitioners and specialists). The client application 130 facilitates the association of medical records or other information for relatives or other individuals (such as parents, children, pets, etc.). For example, in cases where a patient is unable to provide their own medical records due to pain, stress, confusion, loss of consciousness, etc., and when a parent is distracted by an emergency, information provided by another person may be beneficial. In these cases, this important information can be effectively communicated quickly, easily and accurately, thereby preventing medical errors caused by a lack of accurate and complete information. In addition, the client application 130 is configured to improve health care for individuals with communication disorders (such as hearing-impaired people or mute people).

In various embodiments, a doctor's office or other healthcare provider may specify information as required or optional during the client intake process. The client application 130 is executed to collect the data points specified as required by the healthcare provider. This information may be encrypted in accordance with HIPAA and the Health Information Technology for Economic and Clinical Health Act ("HITECH") regulations and may be accessed by the user or a specific healthcare provider using a key or password.

According to various embodiments, the information collected may be limited to: past medical history, past surgical history, allergies, medications, family history, social history, and immunizations, although in other embodiments, additional information may be collected. The client application 130 may assist the user in providing the correct spelling of basic medical terms and medications to prevent confusion and incorrect documentation that may lead to medical errors.

The information collected by the client application 130 can be organized in a summary screen, which is displayed in the user interface 131 and is used for reference when filling out a new patient information packet. In various embodiments, this information can be converted into Microsoft or PDF format for printing before visiting a healthcare provider. Finally, this information can be encrypted, and the encrypted information can be converted into a matrix code or other machine-readable identifier 133 for paperless and wireless delivery directly to the healthcare provider. In various embodiments, scanning the machine-readable identifier 133 causes the underlying information to be automatically populated into the database of various electronic medical record systems.

In addition to collecting personal information, client application 130 can be configured to obtain health information for dependents, family members, pets, and the like. This can help provide complete and accurate information to healthcare professionals when dependents and family members are unable to provide this information themselves due to age, disability, or the like. This can help healthcare providers accurately assess patients, optimize care, and avoid medical errors caused by incomplete medical records. As mentioned above, because pets' medical records are also valuable to owners and veterinarians, client application 130 can be configured to obtain information about them. By being able to easily reference this information in the same platform as the user of client application 130, this information can be used in schools, universities, international travel, emergencies, or other situations.

While this disclosure provides several examples in the context of healthcare data, the embodiments described herein can be applied to many industries. For example, health information may include information about a car. A mechanic can access service records by scanning a machine-readable identifier 133 displayed on a client device 106 (which may include a person's smartphone or a car's computing device).

Referring to FIG. 15 , a schematic block diagram of a computing environment 103 according to an embodiment of the present disclosure is shown. The computing environment 103 includes one or more computing devices 1500. Each computing device 1500 includes at least one processor circuit, for example, having a processor 1503 and a memory 1506, both of which are coupled to a local interface 1509. To this end, each computing device 1500 may include, for example, at least one server computer or similar device. It will be appreciated that the local interface 1509 may include, for example, a data bus or other bus structure with an accompanying address/control bus.

Data and several components executable by processor 1503 are stored in memory 1506. In particular, key management application 118, translation service 120, direct messaging service 122, and other computing environment applications are stored in memory 1506 and can be executed by processor 1503. Data storage 115 and other data may also be stored in memory 1506. Furthermore, operating system 1512 may be stored in memory 1506 and can be executed by processor 1503. It will be appreciated that other applications may also be stored in memory 1506 and can be executed by processor 1503.

Referring to FIG16 , a schematic block diagram of a client device 106 according to an embodiment of the present disclosure is shown. Each client device 106 includes at least one processor circuit, for example, a processor 1603 and a memory 1606, both of which are coupled to a local interface 1609. To this end, each client device 106 may include, for example, a smartphone, a tablet computer, a personal computer, or other similar device. It will be appreciated that the local interface 1609 may include, for example, a data bus with an accompanying address/control bus or other bus structure.

Data and several components executable by processor 1603 are stored in memory 1606. In particular, client application 130 and other applications are stored in memory 1606 and can be executed by processor 1603. Client data storage 1612 (also referred to herein as local data storage) and other data can also be stored in memory 1606. In addition, client operating system 1615 can be stored in memory 1606 and can be executed by processor 1603. It will be appreciated that other applications can also be stored in memory 1606 and can be executed by processor 1603.

Referring to FIG. 17 , a schematic block diagram of a reader device 109 according to an embodiment of the present disclosure is shown. Each reader device 109 includes at least one processor circuit, for example, having a processor 1703 and a memory 1706, both of which are coupled to a local interface 1709. To this end, each reader device 109 may include, for example, a smartphone, tablet computer, personal computer, or other similar device. It will be appreciated that the local interface 1709 may include, for example, a data bus with an accompanying address/control bus or other bus structure.

Data and several components executable by the processor 1703 are stored in the memory 1706. In particular, the reader application 136 and other applications are stored in the memory 1706 and can be executed by the processor 1703. The reader device data storage 1712 and other data can also be stored in the memory 1706. In addition, the client operating system 1715 can be stored in the memory 1706 and can be executed by the processor 1703. It will be appreciated that other applications can also be stored in the memory 1706 and can be executed by the processor 1703.

When any component described herein is implemented in software, it may be implemented in any of a variety of programming languages, such as C, C++, C#, Objective C, Perl, PHP, Visual Ruby, or other programming languages.

A plurality of software components are stored in a memory executable by a processor. In this regard, the term "executable" refers to a program file that is in a form that can ultimately be run by a processor. Examples of executable programs may be, for example, a compiler that can be converted into machine code that can be loaded into a random access portion of a memory and run by a processor; a source code that can be expressed in a suitable form (such as an object code that can be loaded into a random access portion of a memory and executed by a processor); a source code that can be interpreted by another executable program to generate instructions to be executed by a processor in a random access portion of a memory, and the like. An executable program may be stored in any part or component of a memory, such as a random access memory (RAM), a read-only memory (ROM), a hard drive, a solid-state drive, a USB flash drive, a memory card, an optical disk such as a compact disk (CD) or a digital versatile disk (DVD), a floppy disk, a magnetic tape, or other storage component.

Here, memory is defined as including volatile and non-volatile memory and data storage components. When the power is off, the volatile component does not retain the data value. When the power is off, the non-volatile component can retain the data value. Therefore, the memory may include, for example, random access memory (RAM), read-only memory (ROM), hard disk drive, solid-state drive, USB flash drive, memory card accessed by a memory card reader, floppy disk accessed by an associated floppy disk drive, optical disk accessed by an optical disk drive, magnetic tape accessed by an appropriate tape drive and/or other storage components, or any two or more combinations of these storage components. In addition, RAM may include, for example, static random access memory (SRAM), dynamic random access memory (DRAM) or magnetic random access memory (MRAM) and other such devices. ROM may include, for example, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or other similar storage devices.

In addition, the processor may represent multiple processors and/or multiple processor cores, and the memory may represent multiple memories operating separately in parallel processing circuits. In this case, the local interface may be a suitable network that facilitates communication between any two of the multiple processors, between any processor and any memory, or between any two memories. The local interface may include additional systems designed to coordinate communications (e.g., perform load balancing). The processor may be electronic or some other available structure.

Although the client application 130, the reader application 136, the key management application 118, and the various other systems described herein may be embodied as software or code executable by general-purpose hardware as described above, alternatively, the above may also be embodied as dedicated hardware or a combination of software/general-purpose hardware and dedicated hardware. If embodied as dedicated hardware, each may be implemented as a circuit or state machine using any one or a combination of a variety of technologies. These technologies may include, but are not limited to, discrete logic circuits having logic gates for performing various logic functions when one or more data signals are applied, application-specific integrated circuits (ASICs) having suitable logic gates, field-programmable gate arrays (FPGAs), or other components. Such technologies are generally well known to those skilled in the art and are not described in detail here.

The flowcharts of Figures 6 and 10-14 illustrate the functions and operations of the execution of portions of the client application 130, the reader application 136, and the key management application 118. If embodied as software, each block may represent a module, a fragment, or a portion of code that includes program instructions that perform a specific logical function. The program instructions may be embodied in the form of source code, which includes human-readable statements written in a programming language or machine code, wherein the programming language or machine code includes digital instructions that can be recognized by a suitable execution system (such as a processor in a computer system or other system). Machine code can be converted from source code, etc. If embodied as hardware, each block may represent a circuit or multiple interconnected circuits that perform a specific logical function.

Although the flowcharts of Figures 6 and 10-14 show a specific execution order, it is understandable that the execution order may be different from that shown. For example, the execution order of two or more blocks may be disrupted relative to the order shown. In addition, two or more blocks shown continuously in Figures 6 and 10-14 may be executed simultaneously or partially simultaneously. In addition, in some embodiments, one or more blocks shown in Figures 6 and 10-14 may be skipped or omitted. In addition, any number of counters, state variables, warning signals or messages may be added to the logic flow described herein to improve utility, explanation, performance measurement or improve troubleshooting help, etc. It is understandable that all such variations fall within the scope of this disclosure.

Furthermore, any logic or application described herein, including client application 130, reader application 136, and key management application 118, comprises software or code that may be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system, such as, for example, a processor in a computer system or other system. In this sense, logic may include, for example, statements comprising instructions and statements that may be retrieved from a computer-readable medium and executed by an instruction execution system. In the context of this disclosure, a "computer-readable medium" may be any medium for use in or in connection with an instruction execution system that may contain, store, or retain the logic or application described herein.

The computer-readable medium may include any one of a plurality of physical media, such as, for example, magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media may include, but are not limited to, magnetic tape, magnetic floppy disk, magnetic hard drive, memory card, solid-state drive, USB flash drive, or optical disk. The computer-readable medium may also be a random access memory (RAM), including, for example, static random access memory (SRAM) and dynamic random access memory (DRAM) or magnetic random access memory (MRAM). In addition, the computer-readable medium may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other similar storage devices.

Further, any logic or application described herein, the client application 130, the reader application 136, and the key management application 118 can be implemented and structured in a variety of ways. For example, one or more of the applications described can be implemented as modules or components of a single application. Further, one or more of the applications described herein can be executed in shared or separate computing devices, or in a combination thereof. For example, multiple applications described herein can be executed in the same computing device 1500 or in multiple computing devices in the same computing environment 103. Furthermore, it will be understood that terms such as "application," "service," "system," "engine," "module," etc., are interchangeable and are not intended to be limiting.

Disjunctive language, such as the phrase "at least one of X, Y, or Z," unless otherwise specified, should be understood as generally used to indicate that an item, a term, etc., can be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z), depending on the context. Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires that each of at least one of X, at least one of Y, or at least one of Z be present.

It should be emphasized that the above embodiments of the present disclosure are merely possible examples of implementation described for a clear understanding of the principles of the present disclosure. Various variations and modifications may be made to the above embodiments without departing from the spirit and principles of the present disclosure.

Clause 1. A system comprising: a client device comprising at least one hardware processor; a client application executable in the client device comprising program instructions that, when executed, cause the client device to: receive, over a network, a first cryptographic key associated with a first device profile and a second cryptographic key associated with a second device profile; access input data from a data store of the client device and provide the input data through at least one user interface generated by the client application; format the input data into a first data portion and a second data portion; encrypt the first data portion using the first cryptographic key and encrypt the second data portion using the second cryptographic key; and generate a machine-readable identifier using the encrypted first data portion and the encrypted second data portion for presentation on a display accessible to the client device.

Clause 2. The system of clause 1, wherein the machine-readable identifier is a first machine-readable identifier and the client application further comprises program instructions that, when executed, cause the client device to: identify a second machine-readable identifier in an image captured by a camera in communication with the client device, the second machine-readable identifier being generated by a device different from the client device; identify a volume of encrypted data based on the second machine-readable identifier; decrypt the volume of encrypted data using the first cryptographic key or the second cryptographic key to identify the decrypted data; and store the decrypted data in the data store for access by the client application.

Clause 3. The system of clause 2, wherein storing the decrypted data in the data store further comprises: identifying whether there is a conflict between the input data stored in the data store and the decrypted data; and storing the decrypted data in place of the input data stored in the data store.

Clause 4. The system of Clause 1 further includes: a first reader associated with the first device profile and having a first cryptographic key stored thereon; a second reader associated with the second device profile and having a second cryptographic key stored thereon; and wherein the first reader is configured to access the first data portion based on the machine-readable identifier using the first cryptographic key, and the second reader is configured to access the second data portion based on the machine-readable identifier using the second cryptographic key.

Clause 5. The system of clause 4, wherein the first reader comprises a first imaging device, the second reader comprises a second imaging device, and the machine-readable identifier is captured by either the first imaging device or the second imaging device.

Clause 6. The system of clause 1, wherein the client application further comprises program instructions that, when executed, cause the client device to send a machine-readable identifier to another client device that is different from the client device.

Clause 7. The system of clause 1, wherein the machine-readable identifier is generated using a plurality of decrypted data based on the input data.

Clause 8. The system of clause 1, wherein in response to selection of the first device profile made on the client device, the first cryptographic key associated with the first device profile is received by the client device from at least one remote computing device over the network; and wherein in response to selection of the second device profile made on the client device, the second cryptographic key associated with the second device profile is received by the client device from at least one remote computing device over the network.

Clause 9. The system of clause 1, wherein encrypting the first data portion using the first cryptographic key and encrypting the second data portion using the second cryptographic key further comprises: identifying a first access level associated with the first data portion; identifying a second access level associated with the second data portion; encrypting the first data portion using the first cryptographic key at least in part based on the first access level; and encrypting the second data portion using the second cryptographic key at least in part based on the second access level, wherein the first access level is different from the second access level.

Clause 10. The system of clause 1, wherein the machine-readable identifier is a Quick Response (QR) code or a Two-Dimensional code.

Clause 11. A computer-implemented method comprising: receiving, by a client device comprising at least one hardware processor, a first cryptographic key associated with a first device profile and a second cryptographic key associated with a second device profile over a network; accessing, by the client device, input data from a data store of the client device, the input data provided by at least one user interface generated by a client application executable on the client device; formatting, by the client device, the input data into at least a first data portion and a second data portion; encrypting, by the client device, the first data portion using the first cryptographic key and encrypting the second data portion using the second cryptographic key; and generating, by the client device, a machine-readable identifier using the encrypted first data portion and the encrypted second data portion for presentation on a display accessible to the client device.

Clause 12. A computer-implemented method of clause 11, wherein the machine-readable identifier is a first machine-readable identifier, the method further comprising: identifying, by the client device, a second machine-readable identifier in an image captured by a camera communicating with the client device, the second machine-readable identifier being generated by a device different from the client device; identifying, by the client device, a large amount of encrypted data from the second machine-readable identifier; decrypting, by the client device, the large amount of encrypted data using the first cryptographic key or the second cryptographic key to identify the decrypted data; and storing, by the client device, the decrypted data in the data store for access by a client application.

Clause 13. A computer-implemented method of clause 12, wherein storing the decrypted data in the data storage further comprises: identifying, by the client device, whether there is a conflict between the input data stored in the data storage and the decrypted data; and storing, by the client device, the decrypted data in place of the input data stored in the data storage.

Clause 14. The computer-implemented method of Clause 11 further includes: accessing the first data portion from the machine-readable identifier using the first cryptographic key via a first reader, the first reader being associated with the first device profile and having the first cryptographic key stored thereon; and accessing the second data portion from the machine-readable identifier using the second cryptographic key via a second reader, the second reader being associated with the second device profile and having the second cryptographic key stored thereon.

Clause 15. The computer-implemented method of clause 14, wherein the first reading device comprises a first imaging device, the second reading device comprises a second imaging device, and the machine-readable identifier is captured by the first imaging device or the second imaging device.

Clause 16. The computer-implemented method of Clause 11, further comprising sending, by the client device, the machine-readable identifier to another client device different from the client device over the network.

Clause 17. The computer-implemented method of clause 11, wherein the machine-readable identifier is generated using a plurality of decrypted data based on the input data.

Clause 18. The computer-implemented method of clause 11, wherein in response to selection of the first device profile made on the client device, the first cryptographic key associated with the first device profile is received by the client device from at least one remote computing device over the network; and wherein in response to selection of the second device profile made on the client device, the second cryptographic key associated with the second device profile is received by the client device from at least one remote computing device over the network.

Clause 19. A computer-implemented method of clause 11, wherein encrypting the first data portion using the first cryptographic key and encrypting the second data portion using the second cryptographic key further comprises: identifying, by the client device, a first access level associated with the first data portion; identifying, by the client device, a second access level associated with the second data portion; encrypting, by the client device, the first data portion based at least in part on the first access level using the first cryptographic key; and encrypting, by the client device, the second data portion based at least in part on the second access level using the second cryptographic key, wherein the first access level is different from the second access level.

Clause 20. The computer-implemented method of clause 11, wherein the machine-readable identifier is a Quick Response (QR) code or a Two-Dimensional code.

Clause 21. A system comprising: a client device comprising at least one hardware processor; a client application executable in the client device comprising program instructions that, when executed, cause the client device to: generate a first machine-readable identifier using first quantity data encrypted by at least one cryptographic key for presentation on a display of the client device, wherein a reader having the at least one cryptographic key stored thereon is configured to decrypt the data; identify a second machine-readable identifier in at least one image captured by the client device; decode the second machine-readable identifier to identify second quantity data encrypted by the reader using the at least one cryptographic key; decrypt the second quantity data using the at least one cryptographic key; and identify whether there is a conflict between the first quantity data and the second quantity data.

Clause 22. The system of clause 21, wherein the client application further comprises program instructions that, when executed, cause the client device to perform a task in response to a conflict between the first quantity data and the second quantity data to resolve the conflict.

Clause 23. The system of clause 21, wherein the conflict is identified in response to the reading device changing the first quantity data to produce the second quantity data.

Clause 24. The system of clause 22, wherein the task further comprises: displaying information associated with the conflict in a user interface of the client application; receiving a selection of the first quantity data or the second quantity data in the user interface; and in response to the selection, updating the data storage of the client device with the selected first quantity data or the selected second quantity data.

Clause 25. The system of clause 22, wherein the task comprises updating a data store of the client device with the second quantity data.

Clause 26. The system of clause 21, wherein the client application further comprises program instructions that, when executed, cause the client device to populate at least one field of a user interface in the client application with at least a portion of the second quantity data.

Clause 27. The system of Clause 21, wherein the first quantity data encrypted by at least one cryptographic key also includes a first user input part and a second user input part obtained during the acquisition process, the first user input part is encrypted by a first cryptographic key accessible to the reading device, and the second user input part is encrypted by a second cryptographic key inaccessible to the reading device.

Clause 28. The system of clause 21, wherein the machine-readable identifier is a Quick Response (QR) code or a Two-Dimensional code.

Clause 29. The system of clause 21, wherein the client application further comprises program instructions that, when executed, cause the client device to receive at least one cryptographic key from a remote application executing in a remote computing environment over a network.

Clause 30. The system of clause 29, wherein the remote application executing in the remote computing environment is configured to send at least one cryptographic key to the reader device over a network.

Clause 31. A computer-implemented method comprising: generating, by a client device comprising at least one hardware processor, a first machine-readable identifier using first quantity data encrypted by at least one cryptographic key for presentation on a display of the client device, wherein a readout device having the at least one encryption key stored thereon is configured to decrypt the data; identifying, by the client device, a second machine-readable identifier in at least one image captured by the client device; decoding, by the client device, the second machine-readable identifier to identify second quantity data encrypted by the readout device using the at least one cryptographic key; decrypting, by the client device, the second quantity data using the at least one cryptographic key; and identifying, by the client device, whether there is a conflict between the first quantity data and the second quantity data.

Clause 32. The computer-implemented method of clause 31, further comprising, in response to a conflict between the first quantity data and the second quantity data, the client device performing a task to resolve the conflict.

Clause 33. The computer-implemented method of clause 31, wherein the conflict is identified in response to the reading device changing the first quantity data to produce the second quantity data.

Clause 34. A computer-implemented method of clause 32, wherein the task comprises: displaying, via the client device, information associated with the conflict in a user interface of the client application; identifying, via the client device, a selection of the first quantity data or the second quantity data made in the user interface; and updating, via the client device, a data storage of the client device using the selected first quantity data or the selected second quantity data in response to the selection being identified.

Clause 35. The computer-implemented method of clause 32, wherein the task comprises, by a client device, updating a data store of the client device with the second quantity data.

Clause 36. The computer-implemented method of clause 31, further comprising, by the client device, populating at least one field of a user interface in a client application using at least a portion of the second quantity data.

Clause 37. A computer-implemented method of clause 31, wherein the first quantity data encrypted by at least one cryptographic key also includes a first user input part and a second user input part obtained during the ingestion process, the first user input part is encrypted by a first cryptographic key accessible to the reading device, and the second user input part is encrypted by a second cryptographic key inaccessible to the reading device.

Clause 38. The computer-implemented method of clause 31, wherein the machine-readable identifier is a Quick Response (QR) code or a Two-Dimensional code.

Clause 39. The computer-implemented method of clause 31, further comprising receiving, by the client device, at least one cryptographic key from a remote application executing in a remote computing environment over a network.

Clause 40. The computer-implemented method of clause 39, wherein the remote application executing in the remote computing environment is configured to send at least one cryptographic key to the reader over a network.

Claims (15)

1. A system comprising: A client device, including at least one hardware processor; A client application executable in the client device includes program instructions that, when executed, cause the client device to: A first machine-readable identifier is generated using a first quantity of data encrypted with at least one cryptographic key to be displayed on the display of the client device, wherein a readout device having the at least one cryptographic key stored thereon is configured to decrypt the first quantity of data, the first quantity of data including a first user input portion and a second user input portion, the first user input portion being encrypted using a first cryptographic key accessible to the readout device, and the second user input portion being encrypted using a second cryptographic key inaccessible to the readout device. A second machine-readable identifier is identified in at least one image captured by the client device, the second machine-readable identifier being generated by the readout device; Based at least on the first quantity of data encrypted by the reading device using the at least one cryptographic key, after decrypting the first quantity of data using the at least one cryptographic key, the second machine-readable identifier is decoded to identify the second quantity of data created by the reading device; Decrypt the second quantity data using the at least one cryptographic key; and Identify whether there is a conflict between the first quantity data and the second quantity data. 2. The system of claim 1, wherein the client application further includes program instructions that, when executed, cause the client device to perform a task to resolve a conflict between the first quantity data and the second quantity data. 3. The system of claim 2, wherein the task includes at least one of the following: Information related to the conflict is presented in the user interface of the client application; The user interface receives a selection of the first quantity data or the second quantity data; and In response to the selection, the data storage of the client device is updated using either the selected first quantity of data or the selected second quantity of data. 4. The system of claim 3, wherein the task further includes updating the data storage of the client device using the second quantity data. 5. The system of claim 1, wherein the client application further comprises program instructions that, when executed, cause the client device to populate at least one field of the user interface in the client application with at least a portion of the second quantity data. 6. The system of claim 1, wherein the first user input portion and the second user input portion are obtained during the ingestion process. 7. The system of claim 1, wherein the client application further comprises program instructions that, when executed, cause the client device to receive at least one cryptographic key from a remote application executing in a remote computing environment via a network. 8. A computer-executed method, comprising: A first machine-readable identifier is generated using a first quantity of data encrypted with at least one cryptographic key through a client device including at least one hardware processor, and is presented on the display of the client device, wherein a readout device storing the at least one cryptographic key thereon is configured to decrypt the first quantity of data, the first quantity of data including a first user input portion and a second user input portion, the first user input portion being encrypted using a first cryptographic key accessible to the readout device, and the second user input portion being encrypted using a second cryptographic key inaccessible to the readout device; The client device identifies a second machine-readable identifier in at least one image captured by the client device, the second machine-readable identifier being generated by the readout device; Based at least on the first quantity of data encrypted by the reading device using the at least one cryptographic key, after decrypting the first quantity of data using the at least one cryptographic key, the client device decodes the second machine-readable identifier to identify the second quantity of data created by the reading device; The second quantity of data is decrypted using the at least one cryptographic key via the client device; and The client device identifies whether there is a conflict between the first quantity data and the second quantity data. 9. The computer execution method of claim 8 further includes, in response to a conflict between the first quantity data and the second quantity data, the client device performing a task to resolve the conflict. 10. The computer execution method of claim 9, wherein the task comprises at least one of the following: Information related to the conflict is presented in the user interface of the client application; The user interface receives a selection of the first quantity data or the second quantity data; and In response to the selection, the data storage of the client device is updated using either the selected first quantity of data or the selected second quantity of data. 11. The computer-executed method of claim 10, wherein the task further includes updating the data storage of the client device using the second quantity data. 12. The computer execution method of claim 8, further comprising, via the client device, populating at least one field of a user interface in the client application with at least a portion of the second quantity data. 13. The computer execution method of claim 8, wherein the first user input portion and the second user input portion are obtained during the ingestion process. 14. The computer execution method of claim 8, further comprising receiving at least one cryptographic key via a network from a remote application executing in a remote computing environment through the client device. 15. The computer-executed method of claim 8, wherein the machine-readable identifier is a quick-response QR code or a two-dimensional code.