Data sharing with third-party health systems

Abstract

Certain aspects of the present disclosure provide systems and techniques for seamless and secure health data sharing. An example technique includes receiving a request from a user account of a third-party health system (TPHS) to access a first-party health system (FPHS). The request includes a token indicating that the user account is authenticated with the TPHS. A second token is obtained from the TPHS and indicates a user account type. Upon determining that the user account type is a caregiver account type authenticated with the FPHS, (z) a first screen including at least one dependent account is displayed on a display device, (zz) a second screen including a consent agreement for sharing health data of a selected dependent account from the first screen is displayed on the display device, and (z'z'z) a communication link is established between the FPHS and the TPHS for sharing the health data.

Description

DATA SHARING WITH THIRD-PARTY HEALTH SYSTEMS CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 738,453, filed December 23, 2024, which is assigned to the assignee of the present application and is hereby expressly incorporated by reference in its entirety for all applicable purposes, as if fully set forth herein.BACKGROUND

[0002] Health management (e.g., diabetes management) may involve accessing and sharing health data between multiple different health systems. Health data may include, as an example, analyte data produced by an analyte monitoring system utilized by a patient (i.e., host) for monitoring their analyte levels. For example, a healthcare provider (HCP) for a patient may access the patient’s analyte data (e.g., glucose data) in order to perform analyte monitoring, disease diagnosis, and treatment planning. In another example, an individual may be responsible for managing the patient’s health on behalf of the patient (e.g., a caregiverdependent relationship) and may have to access and share the patient’s health records with one or more health systems as part of managing the patient’s health.

[0003] While health data sharing may be beneficial to a patient’ s health management, there are also various risks associated with health data sharing. Such risks can include leaks to patient privacy and confidentiality and unauthorized access to the patient’s health data, as illustrative examples. For instance, health data sharing may involve the exchange of the patient’s personally identifiable information (PII), which can be used by malicious actors to compromise the patient’s health management. Additionally, in some instances, health data sharing may require logging into another user’s account (e.g., child’s account) to share the user’s health data with an HCP.

[0004] This background is provided to introduce a brief context for the summary and detailed description that follow. This background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.SUMMARY

[0005] Certain embodiments provide a first-party health system. The first-party health system includes a memory and a processor communicatively coupled to the memory. Theprocessor is configured to receive, at the first-party health system, a request from a user account associated with a third-party health system to receive health data from the first-party health system. The request includes a first token indicating that the user account of the third-party health system is authenticated with the third-party health system. The processor is also configured to obtain, from the third-party health system, a second token associated with the user account of the third-party health system. The processor is also configured to determine whether a user account of the first-party health system is authenticated with the first-party health system. A session associated with the user account of the first-party health system receives the request from the user account associated with the third-party health system. The processor is also configured to determine a type of the user account associated with the first-party health system. The processor is further configured to, in response to determining (z) the type of the user account associated with the first-party health system is a caregiver account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the caregiver account type: determine at least one dependent account associated with the user account of the first-party health system; cause a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receive an indication of a selected dependent account from the first screen; and establish a link between the selected dependent account of the first-party health system and the user account of the third-party health system for sharing health data of the selected dependent account with the third-party health system.

[0006] Certain embodiments provide a method for sharing data to a third-party health system. The method includes receiving a request, at a first-party health system, from a user account associated with the third-party health system to receive health data from the first-party health system. The request includes a first token indicating that the user account of the third-party health system is authenticated with the third-party health system. The method also includes obtaining, from the third-party health system, a second token associated with the user account of the third-party health system. The method further includes determining whether a user account of the first-party health system is authenticated with the first-party health system. A session associated with the user account of the first-party health system receives the request from the user account associated with the third-party health system. The method also includes determining a type of the user account associated with the first-party health system. The method also includes, in response to determining (z) the type of the user account associated with the first-party health system is a caregiver account type and (zz) the user account associated withthe first-party health system is authenticated with the first-party health system as the caregiver account type: determining at least one dependent account associated with the user account of the first-party health system; causing a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receiving an indication of a selected dependent account from the first screen; and establishing a link between the selected dependent account of the first-party health system and the user account of the third-party health system for sharing health data of the selected dependent account with the third-party health system.

[0007] Other aspects provide: an apparatus operable, configured, or otherwise adapted to perform the aforementioned methods as well as those described elsewhere herein; a non-transitory, computer-readable media comprising instructions that, when executed by one or more processors of an apparatus, cause the apparatus to perform the aforementioned methods as well as those described elsewhere herein; a computer program product embodied on a computer-readable storage medium comprising code for performing the aforementioned methods as well as those described elsewhere herein; and an apparatus comprising means for performing the aforementioned methods as well as those described elsewhere herein. By way of example, an apparatus may comprise a processing system, a device with a processing system, or processing systems cooperating over one or more networks.

[0008] The following description and the appended figures set forth certain features for purposes of illustration.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] So that the manner in which the above-recited features of the present disclosure can be understood in detail, a more particular description, briefly summarized above, may be had by reference to aspects, some of which are illustrated in the drawings. It is to be noted, however, that the appended drawings illustrate only certain typical aspects of this disclosure and are therefore not to be considered limiting of its scope, for the description may admit to other equally effective aspects.

[0010] FIG. 1 illustrates aspects of an example health management system used in connection with implementing certain embodiments of the present disclosure.

[0011] FIG. 2 is a diagram conceptually illustrating an example analyte monitoring system including example analyte sensor(s) with sensor electronics, according to certain embodiments of the present disclosure.

[0012] FIG. 3 illustrates example inputs and example metrics that are determined based on the inputs for use by the health management system of FIG. 1, according to certain embodiments of the present disclosure.

[0013] FIG. 4 illustrates an example workflow for seamless and secure health data sharing, according to certain embodiments of the present disclosure.

[0014] FIG. 5 illustrates another example workflow for seamless and secure health data sharing, according to certain embodiments of the present disclosure.

[0015] FIG. 6 illustrates an example call flow diagram for seamless and secure health data sharing, according to certain embodiments of the present disclosure.

[0016] FIG. 7 depicts a table illustrating various consent view flows for seamless and secure health data sharing, according to certain embodiments of the present disclosure.

[0017] FIGs. 8A-8E illustrate an example sequence of screens presented on display device for seamless and secure health data sharing, according to certain embodiments of the present disclosure.

[0018] FIGs. 9A-9D illustrate another example sequence of screens presented on display device for seamless and secure health data sharing, according to certain embodiments of the present disclosure.

[0019] FIGs. 10A-10E illustrate another example sequence of screens presented on display device for seamless and secure health data sharing, according to certain embodiments of the present disclosure.

[0020] FIG. 11 is a flowchart for seamless and secure health data sharing between health systems, in accordance with certain embodiments of the present disclosure.

[0021] FIG. 12 illustrates an example workflow for seamless and secure healthcare provider access to a health system, according to certain embodiments of the present disclosure.

[0022] FIG. 13 illustrates an example call flow diagram for seamless and secure healthcare provider access to a health system, according to certain embodiments of the present disclosure.

[0023] FIG. 14 is a flowchart for seamless and secure healthcare provider access to a health system, in accordance with certain embodiments of the present disclosure.

[0024] FIG. 15 is a block diagram depicting an example computing device, according to certain embodiments of the present disclosure.

[0025] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one aspect may be beneficially utilized on other aspects without specific recitation.DETAILED DESCRIPTION

[0026] Certain existing systems allow hosts to share their health information from one health system to another to facilitate the hosts’ health management, for example, by a caregiver. In such existing systems, a host may have to link their user account within a first-party health system in a safe and secure manner to ensure that the host’s health data is sent to a correct linked account in a third-party health system (e.g., electronic health record (EHR) system) associated with the user account.

[0027] However, a major security issue with health data sharing over multiple different health systems is that the health data sharing may involve the transferring or sharing of a host’s PII (e.g., full name, address, phones number, email address, Social Security number, driver’s license number, passport number, date of birth, credit card number, fingerprints, detailed geolocation data, among other information), which can compromise the host’s privacy and confidentiality and lead to unauthorized access to the host’s health data, as illustrative examples. The host’s PII, for example, may be used to identify which account in the first-party health system is associated with the host and to connect the identified account within the third-party health system.

[0028] Additionally, existing applications associated with first-party health systems may rely on the user to manually identify and connect associated user accounts (e.g., associated with a dependent or person receiving care by a caregiver) within the first-party health system to the third-party health system. For example, such existing applications may rely on (z) the user to manually login to identify the first-party health system account to which to connect to the third-party health system, (zz) the user already being logged into the proper account on a device to enable the connection to the third-party health system, (zzz) performing a demographics based matching of patient information from records in the third-party health system against records in the first-party health system, or (zv) a combination thereof. However, relying on user input to transfer or share health information over multiple health systems introduces resource inefficiencies in terms of additional processing, memory, user interface (UI) resources to prompt the user to input information, as well as additional time to process the user’s inputs. Inaddition, if a user inputs incorrect information, there is a risk that improper protected health information (PHI) (e.g., health data or medical data associated with the host, such as medical records, diagnoses, treatment information, lab results, among others), PII, or a combination thereof, is transferred to the third-party health system.

[0029] Accordingly, the present disclosure describes techniques, apparatuses, methods, processing systems, and computer-readable mediums for seamless and secure access to third-party health systems (e.g., EHR systems, electronic medical record (EMR) systems, etc.) for transferring or sharing health data, including the transferring or sharing of dependent information (e.g., by a caregiver or a parent) from first-party health systems to third-party health systems.

[0030] In certain embodiments described herein, a first-party health system (e.g., a health system associated with a continuous glucose monitor (CGM) application) allows a third-party health system (e.g., EHR system) to seamlessly access the first-party health system to set up an exchange of health data (e.g., analyte data) associated with a host (e.g., a dependent) without requiring an exchange of the host’s PII. The first-party health system may interact with the third-party health system to verify (e.g., by verifying validity of an access token or code received from the third-party health system) the user account of the third-party health system that is attempting to access the first-party health system and to determine whether the user account of the third-party health system is acting on behalf of a dependent (e.g., which may be indicated by a flag) within the first-party health system.

[0031] For example, in some cases, the user account of the third-party health system that is attempting to access the first-party health system may belong to a caregiver of a host (e.g., the host may be a dependent, such as a minor, child, or adult person receiving care from the caregiver) within the first-party health system. In other cases, the user account of the third-party health system that is attempting to access the first-party health system may belong to a host (e.g., the host is a patient or a dependent, which may be a minor or adult person) within the first-party health system.

[0032] In certain embodiments, upon determining that the user account of the third-party health system belongs to a caregiver acting on behalf of a dependent (e.g., minor or adult person receiving care from the caregiver), the first-party health system may identify (e.g., automatically without user input) one or more dependent accounts associated with the user account (e.g., caregiver account) with minimal to no action within the user account. The first-party health system may acquire permission from the user account of the first-party health system (e.g., caregiver account) to share a selected dependent account’s health data (e.g., or a portion thereof) to the third-party health system (e.g., EHR system) and create a connection between the first-party health system and the third-party health system for exchanging or providing the dependent account’s health data. The first-party health system may then exchange or provide the dependent account’s health data with the third-party health system.

[0033] Additionally, in certain embodiments, the health data sharing system described herein enables a user account of a first-party health system to control which different types of the host’s health data is shared with the third-party health system. For example, the user account of the first-party health system may grant permission for a dependent user’s glucose data to be shared with the third-party health system but may not grant permission for the dependent user’s lactate or other analyte data to be shared with the third-party health system (e.g., EHR system).

[0034] Additionally or alternatively, in certain embodiments, the connection and authorization to share the dependent user’s health data between the first-party health system and third-party health system may be valid for a period of time. The period of time may be set to a default period of time, set by the host, or based on an age of the host (e.g., assuming the host is a dependent child or minor). After the period of time elapses, the authorization to provide or share the dependent user’s health data between the first-party health system and third-party health system may be revoked, and the third-party health system may have to reacquire permission from the parent or caregiver’s user account to receive the dependent user’s health data from the first-party health system. If the dependent is no longer a minor, the third-party health system may have to acquire permission from the patient’s (formerly minor) user account to receive the health data from the first-party health system.

[0035] The techniques, apparatuses, methods, processing systems, and computer-readable mediums described herein for seamless and secure access to third-party health systems (e.g., EHR systems) for sharing health data may provide various technical advantages. For example, certain techniques described herein can improve security health data sharing between health systems by minimizing (or removing) the need to share a host’s PII (e.g., a dependent’s PII) between health systems. Additionally, certain techniques described herein can significantly improve the speed and performance of health data sharing between health systems by reducing communication exchanges and consumption of compute resources (e.g., processors, memory, bandwidth, etc.) associated with relying on user input to share health information over multiple health systems.

[0036] Additionally, in certain existing health data sharing systems, access for healthcare providers (e.g., doctors, nurses, and other individuals that provide care to hosts) to certain applications (e.g., CGM application) or platforms (e.g., medication platform) hosted in a first-party health system (e.g., a health system associated with the CGM application) often requires multiple manual interactions by the healthcare provider. For example, when a healthcare provider wants to access a CGM application (for a particular host) hosted in the first-party health system, the healthcare provider may have to (z) separately request that the host or caregiver of the host provide the host’s analyte data to the healthcare provider (e.g., by generating and providing a report that includes the host’ s analyte data over the requested period of time), (zz) manually request permission from the host or caregiver of the host to access the host’s analyte data within the first-party health system, or (zzz) any combination thereof. These manual exchanges to facilitate the healthcare provider’s access to the host’s account in the first-party health system introduce resource inefficiencies in terms of additional processing, memory, and UI resources, as illustrative examples.

[0037] Moreover, existing health data sharing systems may involve the exchange of PII between the healthcare provider and the first-party health system to facilitate the healthcare provider’s access to the host’s account in the first-party health system. For example, the healthcare provider may have to provide the host’s name, medical record number, or other demographic data in order to connect (e.g., open a communication session) with an application hosted by the first-party health system. As noted, such exchanges of the host’s PII can compromise the host’s privacy and confidentiality and lead to unauthorized access to the host’s health data, as illustrative examples.

[0038] Additionally, existing health data sharing systems often lack seamless integration between the first-party health system and the healthcare provider’s system environment. For example, a healthcare provider using a third-party health system (e.g., an EHR system) (e.g., to view the host’s health data) may have to launch a separate browser window, (re)authenticate with the first-party health system, and manually search or lookup the host’s health records in the first-party health system (e.g., by entering the host’s PII, such as name, date of birth, or medical record number, etc.). This fragmented experience disrupts the clinical workflow and can discourage healthcare providers from accessing continuous analyte data for the host. Moreover, performing redundant lookups for the host increases the risk of error, creates unnecessary delays in accessing the host’s health data, introduces additional privacy risks byrequiring the transfer or manual entry of PHI or PII, and introduces resource inefficiencies in terms of additional processing, memory, UI resources to prompt the healthcare provider to input information, as well as additional time to process the healthcare provider’s inputs.

[0039] Accordingly, the present disclosure describes techniques, apparatuses, methods, processing systems, and computer-readable mediums for enabling seamless and secure healthcare provider access to a host’s health data in a first-party health system. In certain embodiments described herein, a healthcare provider account associated with a third-party health system (e.g., EHR system) can use association information (between the host’s account in a first-party health system and the host’s account in a third-party health system) previously established during the health sharing onboarding described herein to seamlessly access a host’s health data (e.g., CGM data) in the first-party health system. As used herein, the term “onboarding” generally refers to a process in which a host (e.g., a patient or dependent, such as a minor or adult person receiving care from a caregiver) or a caregiver of the host authenticates with a first-party health system and authorizes sharing or transferring of the host’s health data between the first-party health system and a third-party health system. During “onboarding,” an authentication token or code received from the third-party health system is verified and an association between the host’s account in the third-party health system and the host’s account in the first-party health system is established. This association may enable subsequent access by a healthcare provider account to the host’ s account in the first-party health system, by allowing the first-party health system to identify the correct host account in the first-party health system without requiring manual entry of host identifiers or exchange of PII.

[0040] The techniques, apparatuses, methods, processing systems, and computer-readable mediums described herein for enabling seamless and secure healthcare provider access to first-party health systems may provide various technical advantages. For example, certain techniques described herein can improve the speed and performance of a healthcare provider’ s computing system, within a third-party health system, accessing a host’s health data in a first-party health system by reducing communication exchanges and consumption of compute resources (e.g., processors, memory, bandwidth, etc.) associated with relying on manual input to access health information in the first-party health system. Additionally, certain techniques described herein can minimize (or at least reduce) the need for the healthcare provider to provide (or transmit) a host’s PII (e.g., between health systems) in order to access the host’s health information in the first-party health system.

[0041] Although the terms “first,” “second,” “third,” etc., may be used herein to describe various elements, components, regions, layers and / or sections, these elements, components, regions, layers and / or sections should not be limited by these terms. These terms may be only used to distinguish one element, component, region, layer or section from another region, layer, or section. Terms such as “first,” “second,” and other numerical terms, when used herein, do not imply a sequence or order unless clearly indicated by the context. Thus, a first element, component, region, layer, or section discussed herein could be termed a second element, component, region, layer, or section without departing from the teachings of the example embodiments.Example Health Management System

[0042] FIG. 1 illustrates an example health management system 100, such as a diabetes management system, that may be used in connection with certain embodiments of the present disclosure that involve gathering, monitoring, and / or providing information regarding analyte values present in a host’s body, including for example the host’s blood glucose values (e.g., estimate glucose values (eGVs)). In certain embodiments, the health management system 100 is utilized for sharing health data between multiple different health systems, including health data sharing between a first-party health system (e.g., health system associated with a CGM application for a host) and a third-party health system (e.g., EHR system).

[0043] In certain embodiments, the health management system 100 includes analyte monitoring system 104, a display device 107 that executes application 106, a first-party health system (FPHS) 114, a host database 110, a third-party health system (TPHS) 150, and a display device 152 that executes application 154, each of which is described in more detail below. Display device 107 may be generally representative of a display device associated with a host 102 (e.g., patient or dependent). Display device 152 may be generally representative of a display device associated with a caregiver (e.g., parent or care provider) of the host 102, a healthcare provider (HCP) (e.g., primary care provider (PCP), such as a doctor, nurse, or any other individual providing care) for the host 102, or any other individual that has an interest in the wellbeing of the host 102. Although depicted as discrete components for conceptual clarity, in certain embodiments, the host database 110 and FPHS 114 may be combined or distributed across any number of components. For example, in certain embodiments, the host database 110 may be included as part of the FPHS 114.

[0044] The term “analyte” as used herein is a broad term used in its ordinary sense, including, without limitation, to refer to a substance or chemical constituent in a biological fluid (for example, blood, interstitial fluid, cerebral spinal fluid, lymph fluid or urine) that can be analyzed. Analytes can include naturally occurring substances, artificial substances, metabolites, and / or reaction products. Analytes for measurement by the devices and methods may include, but may not be limited to, potassium, glucose, endogenous insulin, acarboxyprothrombin; acylcarnitine; endogenous insulin; adenine phosphoribosyl transferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profiles (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); androstenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; camosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-P hydroxy-cholic acid; cortisol; creatine kinase; creatine kinase MM isoenzyme; cyclosporin A; d-penicillamine; de-ethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylator polymorphism, alcohol dehydrogenase, alpha 1 -antitrypsin, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, hepatitis B virus, HCMV, HIV-1, HTLV-1, MCAD, RNA, PKU, Plasmodium vivax, 21-deoxycortisol); desbutylhalofantrine; dihydropteridine reductase; diptheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acids / acylglycines; free P-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free triiodothyronine (FT3); fumarylacetoacetase; galactose / gal-1 -phosphate; galactose- 1 -phosphate uridyltransferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione perioxidase; glycocholic acid; glycosylated hemoglobin; halofantrine; hemoglobin variants; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyl transferase; immunoreactive trypsin; lactate; lead; lipoproteins ((a), B / A-l, P); lysozyme; mefloquine; netilmicin; phenobarbitone; phenytoin; phytanic / pristanic acid; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinine; reverse tri-iodothyronine (rT3); selenium; serum pancreatic lipase; sisomicin; somatomedin C; specific antibodies recognizing any one or more of the following that may include (adenovirus, anti-nuclear antibody, anti-zeta antibody, arbovirus, Aujeszky's disease virus, dengue virus, Dracunculus medinensis, Echinococcus granulosus, Entamoeba histolytica, enterovirus, Giardia duodenalisa, Helicobacter pylori, hepatitis B virus, herpes virus, HIV-1, IgE (atopic disease), influenza virus, Leishmania donovani, leptospira, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, Myoglobin,Onchocerca volvulus, parainfluenza virus, Plasmodium falciparum, poliovirus, Pseudomonas aeruginosa, respiratory syncytial virus, rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Trepenoma pallidium, Trypanosoma cruzi / rangeli, vesicular stomatis virus, Wuchereria bancrofti, yellow fever virus); specific antigens (hepatitis B virus, HIV-1); succinylacetone; sulfadoxine; theophylline; thyrotropin (TSH); thyroxine (T4); thyroxine-binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthase; vitamin A; white blood cells; and zinc protoporphyrin.

[0045] Salts, sugar, protein, fat, vitamins, and hormones (e.g., insulin) naturally occurring in blood or interstitial fluids can also constitute analytes in certain implementations. The analyte can be naturally present in the biological fluid, for example, a metabolic product, a hormone, an antigen, an antibody, and the like. Alternatively, the analyte can be introduced into the body or exogenous, for example, a contrast agent for imaging, a radioisotope, a chemical agent, a fluorocarbon-based synthetic blood, or a drug or pharmaceutical composition, including but not limited to insulin; glucagon, ethanol; cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorohydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamines, methamphetamines, Ritalin, Cylert, Preludin, Didrex, PreState, Voranil, Sandrex, Plegine); depressants (barbiturates, methaqualone, tranquilizers such as Valium, Librium, Miltown, Serax, Equanil, Tranxene); hallucinogens (phencyclidine, lysergic acid, mescaline, peyote, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, Percocet, Percodan, Tussionex, Fentanyl, Darvon, Talwin, Lomotil); designer drugs (analogs of fentanyl, meperidine, amphetamines, methamphetamines, and phencyclidine, for example, Ecstasy); anabolic steroids; and nicotine. The metabolic products of drugs and pharmaceutical compositions are also contemplated analytes. Analytes such as neurochemicals and other chemicals generated within the body can also be analyzed, such as, for example, ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxytyramine (3MT), 3,4-Dihydroxyphenylacetic acid (DOPAC), Homovanillic acid (HVA), 5-Hydroxy tryptamine (5HT), and 5-Hydroxyindoleacetic acid (FHIAA), and intermediaries in the Citric Acid Cycle.

[0046] In certain embodiments, analyte monitoring system 104 is configured to measure one or more analytes and transmit the analyte measurements to display device 107 for use by application 106. In certain embodiments, analyte monitoring system 104 is a continuous analyte monitoring system, which is configured to continuously measure one or more analytes and transmit the analyte measurements to display device 107 for use by application 106. Incertain embodiments, analyte monitoring system 104 transmits the analyte measurements to display device 107 through a wireless connection (e.g., Bluetooth connection). In certain embodiments, display device 107 is a smart phone. However, in certain other embodiments, display device 107 may instead be any other type of computing device such as a laptop computer, a smart watch, a fitness tracker, a cycling computer, a tablet, or any other computing device capable of executing application 106. Analyte monitoring system 104 may be described in more detail with respect to FIG. 2.

[0047] FPHS 114 may include software components, hardware components, or combinations thereof, that are configured to perform certain techniques described herein for facilitating seamless and secure health data transfer or sharing between the FPHS 114 and the TPHS 150. For example, the FPHS 114 may host (or otherwise include) applications, servers, storage systems (e.g., databases), etc. In certain embodiments, FPHS 114 executes on or includes one or more computing devices in a private cloud, a public cloud, or a hybrid cloud. As illustrated, FPHS 114 includes, without limitation, an application server 112, which executes an application 108. As described in more detail herein, the FPHS 114 may use the application 108 as well as other components to seamlessly share the host’s analyte data (e.g., within FPHS 114) with another health system, such as TPHS 150, in a safe and secure manner to facilitate the host’s health management.

[0048] Application 106 is a health application (e.g., CGM application) that is configured to receive and analyze analyte measurements from analyte monitoring system 104. For example, application 106 stores information about a host 102, including the host’s analyte measurements, in a host profile 118 associated with the host 102 for processing and analysis as well as for use by the FPHS 114 to share with another health system, such as TPHS 150. The application 106 may be installed and run locally on a display device (e.g., display device 107), and may be used to access application 108 on application server 112. In certain embodiments, the application 106 is representative of a client-side component of a client-server application (or other distributed application) which can interact with a server- side component, such as application 108 on application server 112. For example, application 106 may be a “thin” client where the processing is largely directed by the application 106, but performed by application server 112 within FPHS 114.

[0049] Host profile 118 may include information collected about the host 102 from application 106. For example, application 106 provides a set of inputs 128, including the analyte measurements associated with one or more analytes received from analyte monitoringsystem 104 that are stored in host profile 118. In certain embodiments, inputs 128 provided by application 106 include other data in addition to analyte measurements. For example, application 106 may obtain additional inputs 128 through manual host input (e.g., a finger-stick blood glucose reading), one or more other non-analyte sensors or devices, other applications executing on display device 107, etc. Non-analyte sensors and devices may include one or more of, but are not limited to, an insulin pump, smart insulin pen, respiratory sensor, temperature sensor, humidity sensor, accelerometer, sensors or devices provided by display device 107 (e.g., accelerometer, camera, global positioning system (GPS), heart rate monitor, electrocardiogram (ECG), etc.) or other host accessories (e.g., a smart watch, heart rate monitor, hormone monitoring kit, wearable patch that monitors hormone levels, a continuous positive airway pressure (CPAP) machine, or a fitness tracker), or any other sensors or devices that provide relevant information about the host 102 (e.g., sensors on exercise equipment). Inputs 128 of host profile 118 provided by application 106 are described in further detail below with respect to FIG. 3.

[0050] Application 108 is configured to process the set of inputs 128 to determine one or more metrics 130. Metrics 130, discussed in more detail below with respect to FIG. 3, may, at least in some cases, be generally indicative of the health or state of a host 102, such as one or more of the physiological state of a host 102, trends associated with the health or state of a host 102, etc. In certain embodiments, one or more of the metrics 130 may be shared by the FPHS 114 with TPHS 150. As shown, metrics 130 are also stored in host profile 118.

[0051] Host profile 118 may also include demographic information 120, disease information 122, and / or medication information 124. In certain embodiments, such information may be provided through host input or obtained from certain data stores (e.g., electronic medical records, etc.). In certain embodiments, demographic information 120 may include one or more of the host’s age, BMI (body mass index), ethnicity, gender, etc. In certain embodiments, disease information 122 may include information about one or more diseases of a host 102. In certain embodiments, medication information 124 may include information about the amount and type of a medication taken by host 102, such as insulin or non-insulin diabetes medications and / or non-diabetes medication taken by host 102.

[0052] In certain embodiments, application 106 may obtain demographic information 120, disease information 122, and / or medication information 124 from the host 102 in the form of user input or from other sources. In certain embodiments, host profile 118 is dynamic because at least part of the information that is stored in host profile 118 may be revised or updated overtime and / or new information may be added to host profile 118 by FPHS 114 and / or application 106. Accordingly, information in host profile 118 stored in host database 110 provides an up-to-date repository of information related to the host 102.

[0053] Host database 110, in certain embodiments, refers to a storage server that operates, for example, in a public cloud, private cloud, or hybrid cloud. Host database 110 may be implemented as any type of datastore, such as relational databases, non-relational databases, key-value datastores, file systems including hierarchical file systems, and the like. In some exemplary implementations, host database 110 is distributed. For example, host database 110 may comprise a plurality of persistent storage devices, which are distributed. Furthermore, host database 110 may be replicated so that the storage devices are geographically dispersed.

[0054] Host database 110 may include host profiles 118 associated with a plurality of hosts 102, including hosts 102 who similarly interact or have interacted in the past with application 106 on their own devices. Host profiles 118 stored in host database 110 may be accessible to not only application 106, but FPHS 114 as well. Host profiles 118 in host database 110 may be accessible to application 106 and / or FPHS 114 over one or more networks (not shown), such as one or more wireless networks. As described above, FPHS 114, and more specifically application 108 of FPHS 114, can fetch inputs 128 from a host’s profile 118 stored in host database 110 and compute or determine one or more metrics 130 which can then be stored in application data 126 in the host’s profile 118.

[0055] As noted above, in certain embodiments, the FPHS 114 shares health data associated with one or more hosts 102 (e.g., within host database 110) with another health system, such as TPHS 150, in order to facilitate the health management of one or more hosts 102. TPHS 150 may include software components, hardware components, or combinations thereof. For example, the TPHS 150 may host (or otherwise include) applications, servers, storage systems (e.g., data stores), etc., for storing and / or sharing electronic medical records. In certain embodiments, TPHS 150 executes on or includes one or more computing devices in a private cloud, a public cloud, or a hybrid cloud. As illustrated, TPHS 150 includes, without limitation, an application server 158, which executes an application 156. As described in more detail herein, the TPHS 150 may use the application 156 as well as other components to seamlessly access or receive the host’s analyte data within the FPHS 114 (including components thereof) in a safe and secure manner to facilitate the host’s health management. For example, in certain embodiments, upon connecting with the FPHS 114 using the techniquesdescribed herein, the TPHS 150 may access or receive information maintained in host database 110 and / or FPHS 114 associated with a given host 102.

[0056] In some embodiments, application 154 is an EHR application that is configured to receive and display health information from TPHS 150. For example, the application 154 may access the host’s health data (e.g., analyte data) within TPHS 150 for the host’s health management. The application 154 may be installed and run locally on a display device (e.g., display device 152) and may be used to access application 156 on application server 158. In certain embodiments, the application 154 is representative of a client-side component of a client-server application (or other distributed application) which can interact with a server-side component, such as application 156 on application server 158. For example, application 154 may be a “thin” client where the processing is largely directed by the application 154, but performed by application server 158 within TPHS 150. In some embodiments, the display device 107 may be used to access the TPHS 150. For example, in some such embodiments, the display device 107 may be used to access the application 156 on application server 158 (e.g., to access the host’s health data, such as analyte data, within the TPHS 150).

[0057] FIG. 2 is a diagram 200 conceptually illustrating an example analyte monitoring system 104 including example analyte sensor(s) with sensor electronics, in accordance with certain aspects of the present disclosure. For example, analyte monitoring system 104 may be configured to continuously monitor one or more analytes of a host (e.g., host 102), in accordance with certain aspects of the present disclosure.

[0058] Analyte monitoring system 104 in the illustrated embodiment includes sensor electronics module 204 and one or more analyte sensor(s) 202 (individually referred to herein as analyte sensor 202 and collectively referred to herein as analyte sensors 202) associated with sensor electronics module 204. Sensor electronics module 204 may be in wireless communication (e.g., directly or indirectly) with one or more of display devices 210, 220, 230, and 240. In certain embodiments, sensor electronics module 204 may also be in wireless communication (e.g., directly or indirectly) with one or more medical devices, such as medical devices 208 (individually referred to herein as medical device 208 and collectively referred to herein as medical devices 208), and / or one or more other non-analyte sensors 206 (individually referred to herein as non-analyte sensor 206 and collectively referred to herein as non-analyte sensor 206).

[0059] In certain embodiments, an analyte sensor 202 may comprise one or more sensors for detecting and / or measuring analyte(s). The analyte sensor 202 may be a multi-analyte sensor configured to measure two or more analytes or a single analyte sensor configured to measure a single analyte as a non-invasive device, a subcutaneous device, a transcutaneous device, a transdermal device, and / or an intravascular device. In certain embodiments, the analyte sensor 202 may be configured to measure analyte levels of a host using one or more techniques, such as enzymatic techniques, chemical techniques, physical techniques, electrochemical techniques, spectrophotometric techniques, polarimetric techniques, calorimetric techniques, iontophoretic techniques, radiometric techniques, immunochemical techniques, and the like.

[0060] In certain embodiments, analyte monitoring system 104 is a continuous analyte monitoring system, which is configured to continuously monitor one or more analytes of a host (e.g., host 102). In such embodiments, the analyte sensor 202 is a continuous analyte sensor that includes one or more sensors for detecting and / or measuring analyte(s). The continuous analyte sensor may be a multi-analyte sensor configured to continuously measure two or more analytes or a single analyte sensor configured to continuously measure a single analyte as a non-invasive device, a subcutaneous device, a transcutaneous device, a transdermal device, and / or an intravascular device. In certain embodiments, the continuous analyte sensor may be configured to continuously measure analyte levels of a host using one or more techniques, such as enzymatic techniques, chemical techniques, physical techniques, electrochemical techniques, spectrophotometric techniques, polarimetric techniques, calorimetric techniques, iontophoretic techniques, radiometric techniques, immunochemical techniques, and the like.

[0061] The term “continuous,” as used herein, can mean fully continuous, semi-continuous, periodic, etc. In certain embodiments, the (continuous) analyte sensor 202 provides a data stream indicative of the concentration of one or more analytes in the host. The data stream may include raw data signals, which are then converted into a calibrated and / or filtered data stream used to provide estimated analyte value(s) to the host.

[0062] In certain embodiments, the analyte sensor 202 may be a multi-analyte sensor, configured to measure multiple analytes in a host’s body. For example, in certain embodiments, the multi-analyte sensor 202 may be a single sensor configured to measure lactate, glucose, ketones (e.g., 3-beta-hydroxybutyrate, acetoacetate, acetone, etc.), glycerol, and / or free fatty acids in the host’s body.

[0063] In certain embodiments, one or more multi-analyte sensors may be used in combination with one or more single analyte sensors. As an illustrative example, a multianalyte sensor may be configured to measure lactate and glucose and may, in some cases, be used in combination with an analyte sensor configured to measure only ketones or only potassium. Information from each of the multi-analyte sensor(s) and single analyte sensor(s) may be combined to provide detection of significant metabolic events using methods described herein. In further embodiments, other non-contact and or periodic or semi-continuous, but temporally limited, measurements for physiological information may be integrated into the system such as by including weight scale information or non-contact heart rate monitoring from a sensor pad under the host while in a chair or bed, through an infra-red camera detecting temperature and / or blood flow patterns of the host, and / or through a visual camera with machine vision for height, weight, or other parameter estimation without physical contact.

[0064] In certain embodiments, the analyte sensor(s) 202 may comprise a percutaneous wire that has a proximal portion coupled to the sensor electronics module 204 and a distal portion with several electrodes, such as a measurement electrode and a reference electrode. The measurement (or working) electrode may be coated, covered, treated, embedded, etc., with one or more chemical molecules that react with a particular analyte, and the reference electrode may provide a reference electrical voltage. The measurement electrode may generate the analog electrical signal, which is conveyed along a conductor that extends from the measurement electrode to the proximal portion of the percutaneous wire that is coupled to the sensor electronics module 204. After the analyte monitoring system 104 has been applied to epidermis of the patient, analyte sensor(s) 202 penetrates the epidermis, and the distal portion extends into the dermis and / or subcutaneous tissue under epidermis. Other configurations of analyte sensor(s) 202 may also be used, such as a multi-analyte sensor that includes multiple measurement electrodes, each generating an analog electrical signal that represents the concentration levels of a particular analyte.

[0065] Generally, a single-analyte sensor generates an analog electrical signal that is proportional to the concentration level of a particular analyte. Similarly, each multi-analyte sensor generates multiple analog electrical signals, and each analog electrical signal is proportional to the concentration level of a particular analyte. As an illustrative example, analyte sensor 202 may include a single- analyte sensor configured to measure lactate concentration levels, and another single- analyte sensor configured to measure glucose concentration levels of the patient. As another illustrative example, analyte sensor(s) 202 mayinclude a single-analyte sensor configured to measure lactate concentration levels, and one or more multi-analyte sensors configured to measure glucose concentration levels, ketone concentration levels, creatinine concentration levels, etc. As yet another illustrative example, analyte sensor(s) 202 may include a multi-analyte sensor configured to measure lactate concentration levels, glucose concentration levels, ketone concentration levels, creatinine concentration levels, etc. Accordingly, analyte sensor(s) 202 is configured to generate at least one analog electrical signal that is proportional to the concentration level of a particular analyte, and sensor electronics module 204 is configured to convert the analog electrical signal into an analyte sensor count values, calibrate the analyte sensor count values based on the sensitivity profile of the analyte sensor(s) 202 to generate measured analyte concentration levels, and transmit the measured analyte concentration level data, including the measured analyte concentration levels, to a display device, such as display devices 210, 220, and / or 230, via a wireless connection. For example, sensor electronics module 204 may be configured to sample the analog electrical signal at a particular sampling period (or rate), such as every 1 second (1 Hz), 5 seconds, 10 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes, etc., and to transmit the measured analyte concentration data to the display device at a particular transmission period (or rate), which may be the same as (or longer than) the sampling period, such as every 1 minute (0.016 Hz), 5 minutes, 10 minutes, 30 minutes, at the conclusion of the wear period, etc. Depending on the sampling and transmission periods, the measured analyte concentration data transmitted to the display device include at least one measured analyte concentration level having an associated time tag, sequence number, etc.

[0066] In certain embodiments, analyte sensor(s) 202 may incorporate a thermocouple within, or alongside, the percutaneous wire to provide an analog temperature signal to the sensor electronics module 204, which may be used to correct the analog electrical signal or the measured analyte data for temperature. In other embodiments, the thermocouple may be incorporated into the sensor electronics module 204 above the adhesive pad, or, alternatively, the thermocouple may contact the epidermis of the patient through openings in the adhesive pad.

[0067] In certain embodiments, the sensor electronics module 204 includes, inter alia, processor 233, storage element or memory 234, wireless transmitter / receiver (transceiver) 236, one or more antennas coupled to wireless transceiver 236, analog electrical signal processing circuitry, analog to-digital (A / D) signal processing circuitry, digital signal processing circuitry, a power source for analyte sensor(s) 202 (such as a potentiostat), etc.

[0068] Processor 233 may be a general-purpose or application-specific microprocessor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., that executes instructions to perform control, computation, input / output, etc. functions for the sensor electronics module 204. Processor 233 may include a single integrated circuit, such as a micro processing device, or multiple integrated circuit devices and / or circuit boards working in cooperation to accomplish the appropriate functionality. In certain embodiments, processor 233, memory 234, wireless transceiver 236, the A / D signal processing circuitry, and the digital signal processing circuitry may be combined into a system-on-chip (SoC).

[0069] Generally, processor 233 may be configured to sample the analog electrical signal using the A / D signal processing circuitry at regular intervals (such as the sampling period) to generate analyte sensor count values based on the analog electrical signals produced by the analyte sensor(s) 202, calibrate the analyte sensor count values based on the sensitivity profile of the analyte sensor(s) 202 to generate measured analyte concentration levels, and generate measured analyte data from the measured analyte concentration levels, generate sensor data packages that include, inter alia, the measured analyte concentration level data. Processor 233 may store the measured analyte concentration level data in memory 234, and generate the sensor data packages at regular intervals (such as the transmission period) for transmission by wireless transceiver 236 to a display device, such as display devices 210, 220, 230, and / or 240. Processor 233 may also add additional data to the sensor data packages, such as supplemental sensor information that includes a sensor identifier, a sensor status, temperatures that correspond to the measured analyte data, etc. The sensor data packages are then wirelessly transmitted over a wireless connection to the display device.

[0070] In various embodiments, memory 234 may include volatile and nonvolatile medium. For example, memory 234 may include combinations of random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), read only memory (ROM), flash memory, cache memory, and / or any other type of non-transitory computer-readable medium. Memory 234 may store one or more analyte sensor system applications, modules, instruction sets, etc. for execution by processor 233, such as instructions to generate measured analyte data from the analyte sensor count values, etc.

[0071] Memory 234 may also store certain sensor operating parameters 235, such as a calibration slope (or calibration sensitivity), a calibration baseline, etc. In particular, the calibration sensitivity, calibration baseline, and other information related to the sensitivity profile for the sensor electronics module 204 may be programmed into the sensor electronicsmodule 204 during the manufacturing process, and then used to convert the analyte sensor electrical signals into measured analyte concentration levels. For example, the calibration slope may be used to predict an initial in vivo sensitivity (Mo) and a final in vivo sensitivity (Mf), which are stored in memory 234 and used to convert the analyte sensor electrical signals into measured analyte concentration levels. In certain embodiments, calibration sensitivity (Mcc) 246 and / or calibration baseline 247 may be stored in memory 234.

[0072] In certain embodiments, sensor electronics module 204 includes electronic circuitry associated with measuring and processing the analyte sensor data, including prospective algorithms associated with processing and calibration of the sensor data. Sensor electronics module 204 can be physically connected to analyte sensor(s) 202 and can be integral with (non-releasably attached to) or releasably attachable to analyte sensor(s) 202. Sensor electronics module 204 may include hardware, firmware, and / or software that enable measurement of levels of analyte(s) via analyte sensor(s) 202. For example, sensor electronics module 204 can include a potentiostat, a power source for providing power to the sensor, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to, e.g., one or more display devices. Electronics can be affixed to a printed circuit board (PCB), or the like, and can take a variety of forms. For example, the electronics can take the form of an integrated circuit (IC), such as an Application-Specific Integrated Circuit (ASIC), a microcontroller, and / or a processor.

[0073] Display devices 210, 220, 230, and / or 240 are configured for displaying display able sensor data, including analyte data, which may be transmitted by sensor electronics module 204. Each of display devices 210, 220, 230, or 240 may include a display such as a touchscreen display 212, 222, 232, and / or 242 for displaying sensor data to a host and / or for receiving inputs from the host. For example, a graphical user interface (GUI) may be presented to the host 102 for such purposes. In certain embodiments, the display devices may include other types of user interfaces such as a voice user interface instead of, or in addition to, a touchscreen display for communicating sensor data to the host of the display device and / or for receiving host inputs. Display devices 210, 220, 230, and 240 may be examples of display device 107 illustrated in FIG. 1 used to display sensor data to a host 102 of the system of FIG. 1 and / or receive input from the host of the system of FIG. 1. Display devices 210, 220, 230, and 240 may also be examples of display device 152 used to display sensor data to a caregiver of the host 102 of the system of FIG. 1 or an HCP of the host 102 of the system of FIG. 1 and / or to receive inputfrom a caregiver of the host 102 of the system of FIG. 1 or an HCP of the host 102 of the system of FIG. 1.

[0074] In certain embodiments, one, some, or all of the display devices are configured to display or otherwise communicate (e.g., verbalize) the sensor data as it is communicated from the sensor electronics module (e.g., in a customized data package that is transmitted to display devices based on their respective preferences), without any additional prospective processing required for calibration and real-time display of the sensor data.

[0075] The plurality of display devices may include a custom display device specially designed for displaying certain types of display able sensor data associated with analyte data received from sensor electronics module. In certain embodiments, the plurality of display devices may be configured for providing alerts / alarms based on the displayable sensor data. Display device 210 is an example of such a custom device. In certain embodiments, one of the plurality of display devices is a smartphone, such as display device 220 which represents a mobile phone, using a commercially available operating system (OS), and configured to display a graphical representation of the (continuous) sensor data (e.g., including current and historic data). Other display devices can include other hand-held devices, such as display device 230 which represents a tablet, display device 240 which represents a smart watch or fitness tracker, medical device 208 (e.g., an insulin delivery device or a blood glucose meter), and / or a desktop or laptop computer (not shown).

[0076] Because different display devices provide different user interfaces, content of the data packages (e.g., amount, format, and / or type of data to be displayed, alarms, and the like) can be customized (e.g., programmed differently by the manufacture and / or by an end host) for each particular display device. Accordingly, in certain embodiments, a plurality of different display devices can be in direct wireless communication with a sensor electronics module (e.g., such as an on-skin sensor electronics module 204 that is physically connected to analyte sensor(s) 202) during a sensor session to enable a plurality of different types and / or levels of display and / or functionality associated with the display able sensor data.

[0077] As mentioned, sensor electronics module 204 may be in communication with a medical device 208. Medical device 208 may be a passive device in some example embodiments of the disclosure. For example, medical device 208 may be an insulin pump for administering insulin to a host 102. For a variety of reasons, it may be desirable for such an insulin pump to receive and track lactate, glucose, ketones, glycerol and free fatty acid valuestransmitted from analyte monitoring systems 104, where analyte sensor 202 is configured to measure lactate, glucose, ketones, glycerol, and / or free fatty acids.

[0078] Further, as mentioned, sensor electronics module 204 may also be in communication with other non-analyte sensors 206. Non-analyte sensors 206 may include, but are not limited to, an altimeter sensor, an accelerometer sensor, a global positioning system (GPS) sensor, a temperature sensor, a respiration rate sensor, etc. Non-analyte sensors 206 may also include monitors such as heart rate monitors, blood pressure monitors, pulse oximeters, caloric intake monitors, indirect calorimetry devices and medicament delivery devices. One or more of these non-analyte sensors 206 may provide data to FPHS 114. In certain embodiments, a host may manually provide some of the data for processing by FPHS 114 of FIG. 1.

[0079] In certain embodiments, non-analyte sensors 206 may further include sensors for measuring skin temperature, core temperature, sweat rate, and / or sweat composition.

[0080] In certain embodiments, the non-analyte sensors 206 may be combined in any other configuration, such as, for example, combined with one or more analyte sensors 202. As an illustrative example, a non-analyte sensor, e.g., a temperature sensor, may be combined with a lactate sensor 202 to form a lactate / temperature sensor used to transmit sensor data to the sensor electronics module 204 using common communication circuitry. As another illustrative example, a non-analyte sensor, e.g., a temperature sensor, may be combined with a multianalyte sensor 202 configured to measure lactate and glucose to form a lactate / glucose / temperature sensor used to transmit sensor data to the sensor electronics module 204 using common communication circuitry.

[0081] In certain embodiments, a wireless access point (WAP) may be used to couple one or more of analyte monitoring system 104, the plurality of display devices, medical device(s) 208, and / or non-analyte sensor(s) 206 to one another. For example, a WAP may provide WiFi and / or cellular connectivity among these devices. Near Field Communication (NFC) and or Bluetooth may also be used among devices depicted in diagram 200 of FIG. 2.

[0082] FIG. 3 illustrates example inputs and example metrics that are calculated based on the inputs for use by the system 100 of FIG. 1, according to some embodiments disclosed herein. In particular, FIG. 3 provides a more detailed illustration of example inputs and example metrics introduced in FIG. 1.

[0083] FIG. 3 illustrates example inputs 128 on the left, application 106 and application 108 in the middle, and metrics 130 on the right. In certain embodiments, each one of metrics130 may correspond to one or more values, e.g., discrete numerical values, ranges, or qualitative values (high / medium / low, stable / unstable, etc.), trends, etc. Some or all of metrics 130 may include time-series data and / or be provided in the form of time-series data. Application 106 obtains inputs 128, which may be in the form of time- series data, through one or more channels (e.g., manual host input, sensors, other applications executing on display device 107, an electronic medical record (EMR) system, etc.). As mentioned previously, in certain embodiments, inputs 128 may be processed by application 108 to output a plurality of metrics, such as metrics 130. Inputs 128, metrics 130, or any combination thereof, may be shared by FPHS 114 with another health system, such as TPHS 150, to facilitate health management for a host 102.

[0084] In certain embodiments, starting with inputs 128, host statistics, such as one or more of age, height, weight, BMI, body composition (e.g., % body fat or % muscle from a computed tomography (CT) scan, a magnetic resonance imaging (MRI) scan, dual-energy X-ray absorptiometry (DEXA) scan, etc.), stature, build, or other information may also be provided as an input. In certain embodiments, host statistics are provided through a user interface, by interfacing with an electronic source such as an EMR, and / or from measurement devices. In certain embodiments, the measurement devices include one or more wireless devices, e.g., Bluetooth-enabled, weight scale and / or camera, which may, for example, communicate with the display device 107 to provide host data.

[0085] In certain embodiments, treatment / medication information is also provided as an input. Medication information may include information about the type, dosage, and / or timing of when one or more medications are to be taken by the host. For example, the user’s medication intake may include the user’s insulin delivery. Such information may be received, via a wireless connection on a smart pen, via user input, and / or from an insulin pump (e.g., medical device 208). Insulin delivery information may include one or more of insulin volume, time of delivery, etc. Other configurations, such as insulin action time or duration of insulin action, may also be received as inputs. Treatment information may include information regarding different lifestyle habits recommended by the host’s physician. For example, the host’s physician may recommend a host follow specific diet recommendations, exercise for a minimum of thirty minutes a day, or adjust insulin dose to in order to put glucose levels in a desired range. In certain embodiments, treatment / medication information may be provided through manual host input.

[0086] In certain embodiments, analyte sensor data may also be provided as input, for example, through analyte monitoring system 104 and / or in any of the ways described with respect to FIGs. 1-2. An example of analyte data is glucose data, which may be provide and / or stored as a time series corresponding to time-stamped glucose measurements over time. Other types of analyte data, such as ketone data, potassium data, lactate data, etc., may similarly be provided and / or stored as a time series.

[0087] In certain embodiments, input may also be received from one or more non-analyte sensors, such as non-analyte sensors 206 described with respect to FIG. 2. Input from such non-analyte sensors 206 may include information related to a heart rate, a respiration rate, oxygen saturation, blood pressure, or a body temperature (e.g. to detect illness, physical activity, etc.) of a host. In certain embodiments, electromagnetic sensors may also detect low-power radio frequency (RF) fields emitted from objects or tools touching or near the object, which may provide information about host activity or location.

[0088] In certain embodiments, input received from non-analyte sensors may include input relating to a host’s insulin delivery. In particular, input related to the host’s insulin delivery may be received, via a wireless connection on a smart pen, via host input, and / or from an insulin pump. Insulin delivery information may include one or more of insulin volume, time of delivery, etc. Other parameters, such as exogenous insulin action time or duration of exogenous insulin action, may also be received as inputs.

[0089] In certain embodiments, activity information is also provided as an input. Activity information may be provided, for example, the one or more non-analyte sensors 206 of FIG. 2.In certain embodiments, activity information may additionally be provided through manual input by host 102. Activity information may include, for example, a time series for each of heart rate, activity minutes, step count, floors climbed, location information (e.g., GPS data), calories burned, sleep duration and / or quality, activity level (e.g., light, medium, or heavy), and / or similar information. In addition, or alternatively, the activity information can include one or more time series for recorded activities of one or more defined activity types (e.g., walk, run, sprint, swim, weightlift etc.), where each activity is associated with a duration and / or time period.

[0090] In certain embodiments, time may also be provided as an input, such as time of day or time from a real-time clock. For example, in certain embodiments, input analyte data maybe timestamped to indicate a date and time when the analyte measurement was taken for the host.

[0091] Host input of any of the above-mentioned inputs 128 may be provided through analyte monitoring system 104, non-analyte sensors 206, and / or a user interface, such as user interface of display device 107 of FIG. 1. As described above, in certain embodiments, application 108 determines or computes the host’s metrics 130 based on inputs 128. An example list of metrics 130 is shown in FIG.3.

[0092] In certain embodiments, metabolic rate is a metric that may indicate or include a basal metabolic rate (e.g., energy consumed at rest) and / or an active metabolism (e.g., energy consumed by activity, such as physical exertion). In some examples, basal metabolic rate and active metabolism may be tracked as separate outcome metrics. In certain embodiments, the metabolic rate may be calculated by application 108 based on one or more of inputs 128, such as one or more of activity information, analyte sensor data, non-analyte sensor data, time, etc. In certain embodiments, the metabolic rate may be calculated and metabolic rates calculated over time may be time-stamped and stored in the host’s profile 118.

[0093] In certain embodiments, the activity level metric may indicate the host’s level of activity. For example, the activity level may indicate whether the user is exercising, at rest, sleeping, etc. The activity level metric be determined, for example based on input from an activity sensor or other physiologic sensors, such as non-analyte sensors 206. In certain embodiments, the activity level metric may be calculated by application 108 based on one or more of inputs 128, such as one or more of activity information, non-analyte sensor data (e.g., accelerometer data), time, host input, etc. In certain embodiments, the activity level may be expressed as a step rate of the host. Activity level metrics may be time-stamped so that they can be correlated with the host’s glucose levels at the same time.

[0094] In certain embodiments, the metrics 130 include an insulin resistance metric (also referred to herein as “insulin resistance”). The insulin resistance metric may be determined using historical data, real-time data, or a combination thereof, and may, for example, be based upon one or more inputs 128, such as one or more of blood glucose information, insulin delivery information, the resulting glucose levels, etc.

[0095] In certain embodiments, the metrics 130 include an insulin on board (IOB) metric. The insulin on board metric may be determined using insulin delivery information, and / or known or learned (e.g., from patient data) insulin time action profiles, which may account forboth basal metabolic rate (e.g., update of insulin to maintain operation of the body) and insulin usage driven by activity or food consumption.

[0096] In certain embodiments, the metrics 130 include health and sickness metrics. Health and sickness metrics may be determined, for example, based on one or more of host input (e.g., pregnancy information or known sickness information), from non-analyte sensor(s) 206, such as physiologic sensors (e.g., temperature), activity sensors, or a combination thereof. In certain embodiments, based on the values of the health and sickness metrics, for example, the host’s state may be defined as being one or more of healthy, ill, rested, or exhausted. In certain embodiments, health and sickness metric may indicate the host’s heart rate, stress level, etc.

[0097] In certain embodiments, the metrics 130 include analyte level metrics (e.g., glucose level metrics). Analyte level metrics may be determined from analyte data (e.g., glucose measurements obtained from analyte monitoring system 104). In some examples, an analyte level metric may also be determined, for example, based upon historical information about analyte levels in particular situations, e.g., given a combination of food consumption, insulin, and / or activity. An analyte level metric may include a rate of change of the analyte, time in range, time spent below a threshold level, time spent above a threshold level, or the like. In certain embodiments, an analyte trend (e.g., glucose trend) may be determined based on the analyte level over a certain period of time. As described above, example analytes may include glucose, ketones, lactate, potassium and others described herein.

[0098] In certain embodiments, the metrics 130 include a disease stage. For example, disease stages for Type II diabetics may include a pre-diabetic stage, an oral treatment stage, and a basal insulin treatment stage. In certain embodiments, degree of glycemic control (not shown) may also be determined as an outcome metric, and may be based, for example, on one or more of glucose levels, variation in glucose level, or insulin dosing patterns.

[0099] In certain embodiments, the metrics 130 include clinical metrics. Clinical metrics generally indicate a clinical state a host is in with respect to one or more conditions of the host, such as diabetes. For example, in the case of diabetes, clinical metrics may be determined based on glycemic measurements, including one or more of A1C, trends in A1C, time in range, time spent below a threshold level, time spent above a threshold level, and / or other metrics derived from glucose values.

[0100] In certain embodiments, the metrics 130 include electrolyte levels. The electrolyte levels may be calculated by application 108 based on inputs 128. For example, the electrolytelevels may include potassium levels determined from sensor data (e.g. potassium measurements obtained from analyte monitoring system 104). Potassium levels may also be used to determine potassium metrics such as an absolute maximum potassium level, an individualized maximum potassium level, a duration of time where potassium is above a certain threshold, an individualized Zone 2 potassium range and / or a potassium rate of change.Example Seamless and Secure Health Data Sharing

[0101] FIG. 4 illustrates an example workflow 400 for seamless and secure health data sharing between a FPHS 114 (e.g., health system associated with an analyte monitoring system for a host) and a TPHS 150 (e.g., EHR system), according to certain embodiments.

[0102] As illustrated, the TPHS 150 hosts or includes, without limitation, application server 158, which executes application 156 (also referred to herein as TPHS app 156), and communication component 410. In certain embodiments, the application 156 allows a user account (e.g., a host 102 or a caregiver for the host 102) to access a host’s health information and manage the host’s care. For example, the application 156 may allow a host 102 and / or another user (e.g., caregiver, for instance, a parent or care provider providing care to a child or adult) responsible for managing the host’s care to view the host’s health information (e.g., access test results, medications, immunization history, upcoming appointments, etc.), communicate with the host’s health care provider(s), manage appointments, and share medical records, among other tasks. The communication component 410 may generally be representative of an application programming interface (API) server, which allows components of the TPHS 150 (including application 156) to communicate with other health systems (including components thereof), such as the FPHS 114 (including application 108). The communication component 410 can use any suitable communication protocol / standard to communicate with other health systems, such as the FPHS 114. In certain embodiments, the communication component 410 may use the fast healthcare interoperability resources (FHIR) standard to access and exchange data.

[0103] In certain embodiments, an HCP 424 (e.g., PCP) may manage aspects related to the host’s health, such as accessing the host’s health information and communicating with the host and / or caregiver, among other tasks, via computing system 422. Although depicted as discrete components for conceptual clarity, in some embodiments, the application server 158, communication component 410, and computing system 422 may be combined or distributed across any number of components.

[0104] As also illustrated in FIG. 4, the FPHS 114 hosts or includes, without limitation, application server 112, which executes application 108 (also referred to herein as FPHS app 108), remote server 420, communication component 430, and analyte monitoring system data service 454. As noted above with respect to FIG. 1, application 108 may be generally representative of a server-side component of a health application (e.g., CGM application) that is configured to receive and analyze analyte measurements from analyte monitoring system 104. For example, application 108 may access and share information about a host 102, including the host’s analyte measurements, in a host profile 118 associated with the host 102 with another health system, such as TPHS 150, to facilitate heath management for the host 102, as described herein. The remote server 420 may store information associated with the FPHS 114, including hardware and software inventory, information technology (IT) asset data, licenses, and data sharing agreements, as illustrative examples. The analyte monitoring system data service 454 (hereinafter “data service 454”) may store analyte data of hosts received via an analyte monitoring system, such as analyte monitoring system 104.

[0105] The communication component 430 may generally be representative of an API server, which allows components of the FPHS 114 (including application 108) to communicate with other health systems (including components thereof), such as the TPHS 150 (including application 156). The communication component 430 can use any suitable communication protocol to communicate with other health systems, such as the TPHS 150. In certain embodiments, the communication component 430 uses the FHIR standard to access and exchange data. Although depicted as discrete components for conceptual clarity, in some embodiments, the application server 112, remote server 420, communication component 430, and data service 454 may be combined or distributed across any number of components.

[0106] As illustrated in FIG. 4, at 460, the application 156 receives a request or an order from the HCP 424 (via computing system 422) for remote patient monitoring. That is, the HCP 424 (e.g., PCP) may submit an order for the application 156 to collect and / or receive the host’s health data (e.g., analyte data) from another health system, such as the FPHS 114. The health data obtained from the FPHS 114 may allow the HCP 424 to monitor the host’s health condition (e.g., diabetes) and manage treatment plans remotely, e.g., by tracking analyte data such as glucose through analyte monitoring systems. In some embodiments, the HCP 424 may send the request to a display device (e.g., display device 152) associated with a caregiver or parent of the host.

[0107] In response to the order from the HCP 424 for remote patient monitoring, the application 156 may cause a GUI element to be displayed on a display device (e.g., display device 107 or display device 152) associated with a user (e.g., host 102 or caregiver for the host 102). For example, the GUI element may be a button with text including “Connect to FPHS” or similar text. In another example, the GUI element may be an icon (e.g., graphical representation) that is representative of (or otherwise associated with) a “Connect to FPHS” action. The GUI element may allow the user (or user account) of the application 156 to trigger the TPHS 150 to signal or connect to the FPHS 114. For example, at 462, once the GUI element is selected, the application 156 may transmit an access request to the FPHS 114 on behalf of the user account to initialize a connection between the FPHS 114 and TPHS 150.

[0108] As illustrated, the access request is sent to the communication component 430 within the FPHS 114. As described in greater detail with respect to FIG. 6, in certain embodiments, the access request may include an authentication token (e.g., launch token), which identifies the user account in the TPHS 150 and indicates that the user account in the TPHS 150 that has initiated the access request is authenticated on the TPHS 150. The authentication token does not include any PII associated with the user account in the TPHS 150.

[0109] As illustrated at 464 in FIG. 4, in response to receiving the authentication token, the FPHS 114 (via communication component 430) performs a token exchange with the TPHS 150 (via communication component 410) to receive a user access token associated with an identifier of the user account of the TPHS 150. In particular, the communication component 430 may exchange the authentication token for the user access token. In certain embodiments, the token exchange may be performed via a Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR token exchange. In certain embodiments, the user access token may include a user context. The user context may include a TPHS specific identifier associated with the user account of the TPHS 150, for example, a user ID associated with the user account of the TPHS 150 (but does not include any PII associated with the user account) (e.g., the user ID, for instance, 128 random characters generated by TPHS 150, may not be indicative of (or include) a medical records number (MRN) for the user account or an internal primary key for the user account on TPHS 150). In addition to the user ID, the user context may include an indication that the user account on TPHS 150 is authorized to access one or more components within the FPHS 114, such as the application 108 and communication component 430. The TPHS specific identifier (e.g., userID) or the user access token from theTPHS 150 may be used by the FPHS 114 to send or communicate data to the TPHS 150 with the TPHS specific identifier or the user access token attached or included so that the data can be associated with the user account in the TPHS 150. In certain embodiments, the steps illustrated at 460, 462, and 464 may be performed using the OpenlD and OAuth 2.0 authorization models for authorization and authentication.

[0110] As illustrated at 466 in FIG. 4, the communication component 430 redirects the access request from the TPHS 150 to the application 108 for continued onboarding. In some embodiments, the communication component 430 may redirect the access request from the user account of the TPHS 150 to a user account of the FPHS 114. For example, the communication component 430 may modify the access request to include a platform generated state value (e.g., a random generated value or other value that is associated with the user account within FPHS 114 and allows onboarding tracking with FPHS 114). The platform generated state value may be generally a random string that identifies the communication session between the TPHS 150 and the FPHS 114 as the user account of the FPHS 114 is redirected between components within the FPHS 114. For example, the platform generated state value may include a session identifier, a FPHS 114 generated access token, FPHS 114 generated cookie, etc., that associates one or more redirects of the user account of the FPHS 114 between components within the FPHS 114 to the communication session that was initiated between the FPHS 114 and the TPHS 150. In some examples, the platform generated state value may indicate that the user account of the TPHS 150 is authorized to access the application 108 for a period of time. Once the access request is redirected from the TPHS 150 to the application 108, the application 108 may determine whether the user account of the TPHS 150 is authenticated with the application 108 (e.g., successfully logged into the application 108), based on the access request.

[0111] As illustrated at 468 in FIG. 4, if the application 108 determines the user account of the FPHS 114 is authenticated with the application 108, then the application 108 automatically redirects the access request to the communication component 430 with the state value and user identifier within FPHS 114 in order to store a “Health System Connection” IN_PROGRESS connection state for the user account of the FPHS 114 (e.g., in association with user identifier within FPHS 114).

[0112] On the other hand, as illustrated at 470 in FIG. 4, if the application 108 determines the user account of the FPHS 114 is not authenticated with the application 108 (e.g., the user account of the FPHS 114 is not logged into the application 108), then the application 108 redirects the user account of the FPHS 114 to the remote server 420 to handle the user login.In this case, an IN_PROGRESS connection state is not stored for the user account of the FPHS 114. In some embodiments, remote server 420 and application server 112 may be a single entity or distributed across one or more systems (e.g., servers, computing systems, etc.).

[0113] In certain embodiments, the FPHS 114 determines, based on the user context within the user access token (e.g., after confirmation that a user is logged in or after login), whether the user account of the FPHS 114 is associated with one or more dependent accounts in the FPHS 114. That is, the FPHS 114 may determine whether the user account of the FPHS 114 is a host / dependent type (e.g., patient) or a caregiver type (e.g., caregiver acting on behalf of the host). If the user account of the FPHS 114 is associated with one or more dependent accounts in the FPHS 114, then the FPHS 114 (via the communication component 430) may set a proxy flag to a value indicating that the user account of the FPHS 114 has one or more associated dependent accounts in the FPHS 114. As illustrated at 472 in FIG. 4, the communication component 430 redirects the user account of the FPHS 114 to the remote server 420 to complete a health data sharing agreement. In certain embodiments, the communication component 430 may render web content from the remote server 420 on a display device associated with the user in order to allow the user account of the FPHS 114 to complete and accept the health data sharing agreement (e.g., a consent agreement). When redirecting the user account of the FPHS 114 to the remote server 420, the communication component 430 may provide the user access token (including user context), platform generated state value, and proxy information (including the proxy flag) to the remote server 420.

[0114] As illustrated at 474 in FIG. 4, when the proxy flag indicates the user account of the FPHS 114 has one or more dependents, the remote server 420 provides a dependent account selection screen for display on the display device associated with the user. In response to selection of a dependent account, the remote server 420 may present a health data sharing agreement (e.g., consent agreement) associated with the selected dependent account for display on the display device. The remote server 420 may store the completed agreement upon acceptance of the health data sharing agreement.

[0115] As illustrated at 476 in FIG. 4, a communication link is established between the FPHS 114 and the TPHS 150 and the user is presented with a connection result screen for display on the display device. As described herein, the connection result screen may indicate that the connection between the user account on the FPHS 114 and the user account on the TPHS 150 has been successfully established.

[0116] As illustrated at 478 and 480 in FIG. 4, once the communication link is established between the FPHS 114 and the TPHS 150, the communication component 430 may periodically (e.g., every 7 days, 14 days, or some other time interval) obtain, at 478, the dependent’s health data from the analyte monitoring system data service 454 (e.g., via a get analyte data request) and provide, at 480, the dependent’s health data (e.g., analyte data) to the TPHS 150.

[0117] As illustrated at 482, the TPHS 150 (via communication component 410) may notify the HCP 424 of new health data (e.g., analyte data) available for the host (e.g., dependent).

[0118] Note the workflow 400 depicted in FIG. 4 is provided as an illustrative example workflow for seamless and secure health data sharing between a FPHS 114 and TPHS 150 and that other workflows consistent with the functionality described herein are contemplated. By way of example, FIG. 5 depicts another workflow 500 for seamless and secure health data sharing between a FPHS 114 (e.g., health system associated with an analyte monitoring system for a host) and TPHS 150 (e.g., EHR system), according to certain embodiments. Compared to the workflow 400 illustrated in FIG. 4, the workflow 500 illustrated in FIG. 5 may be used for sharing the health data of one or more hosts with a TPHS, such as TPHS 150. Similar to the FPHS 114 illustrated in FIG. 4, the FPHS 114 illustrated in FIG. 5 hosts or includes an application server 112, which executes application 108, and remote server 420. Compared to the FPHS 114 illustrated in FIG.4, the FPHS 114 illustrated in FIG.5 further hosts or includes a storage system 520, a communication component 530, and a remote server 540 (e.g., a third-party linking server).

[0119] The storage system 520 may be generally representative of a database (e.g., host database 110) that stores health data (e.g., analyte data) of one or more hosts (e.g., host(s) 102). For example, as illustrated at 564 in FIG. 5, the application 108 may continuously upload health data associated with one or more hosts to the storage system 520, e.g., upon receiving the respective health data (e.g., analyte data) from a respective display device 107 which received the data from a respective analyte monitoring system 104 associated with a respective host. The communication component 530 may be generally representative of an API server, which allows components of the FPHS 114 (including application 108) to communicate with other health systems (including components thereof), such as the TPHS 150 (including application 156). The communication component 530 can use any suitable communication protocol to communicate with other health systems, such as the TPHS 150. In certainembodiments, the communication component 530 may use the FHIR standard to access and exchange data.

[0120] The remote server 540 may be generally representative of a third-party linking server that facilitates linking between the FPHS 114 and TPHS 150. In certain embodiments, the remote server 540 may include or store host information for one or more hosts associated with the TPHS 150. For example, the remote server 540 may include EHR(s), EMR(s), or other records (from the TPHS 150) for one or more hosts. In certain embodiments, after the user account of the TPHS 150 has successfully onboarded with the FPHS 114, the remote server 540 may include or store an association between a TPHS specific identifier (e.g., from the user access token) for a host in the TPHS 150 and a FPHS specific identifier for the host in the FPHS 114, as described herein.

[0121] As illustrated at 560 in FIG. 5, an HCP 424 (e.g., PCP) submits a request or an order for the application 156 to collect and / or receive the host’s health data (e.g., analyte data) from another health system, such as the FPHS 114. Note, the step illustrated at 560 in FIG. 5 may be similar to the step illustrated at 460 in FIG. 4.

[0122] In response to the request or order from the HCP 424 for remote patient monitoring, the application 156 may cause a GUI element to be displayed on a display device (e.g., display device 107 or display device 152) associated with a user (e.g., host 102 or parent / caregiver for the host 102). For example, the GUI element may be a button with text including “Connect to FPHS” or similar text. In another example, the GUI element may be an icon (e.g., graphical representation) that is representative of (or otherwise associated with) a “Connect to FPHS” action. The GUI element may allow the user (or user account) of the application 156 to trigger the TPHS 150 to signal or connect to the FPHS 114. For example, at 562, once the GUI element is selected, the application 156 may transmit an access request to the FPHS 114 on behalf of the user account (e.g., of the TPHS 150) to initialize a connection between the FPHS 114 and TPHS 150.

[0123] As illustrated, the access request is sent to the application 108. Similar to the access request described with respect to the workflow 400 illustrated in FIG. 4, the access request sent at 562 may include an authentication token (e.g. launch token) (that does not include PII), which is associated with the user account in the TPHS 150 and indicates that the user account of TPHS 150 that has initiated the access request is authenticated on the TPHS 150. In certain embodiments, similar to the token exchange described with respect to the workflow 400illustrated in FIG. 4, the FPHS 114 may perform a token exchange with the TPHS 150 to receive a user access token associated with an identifier of the user account of the TPHS 150. The user access token may include a TPHS specific identifier associated with the user account of the TPHS 150 (e.g., a TPHS 150 specific user ID or other TPHS user ID, for example, that does not include PII).

[0124] At 566, in response to receiving the authentication token and determining that a user account of FPHS 114 is authenticated (e.g., based on the user being logged into the FPHS 114) with the application 108, the application 108 forwards the access request to the communication component 530. As illustrated at 568, in response to receiving the access request, the communication component 530 redirects the user account of the FPHS 114 to the remote server 420 to complete a health data sharing agreement (e.g., consent agreement). In certain embodiments, the communication component 530 may render web content from the remote server 420 on a display device associated with the user in order to allow the user account of the FPHS 114 to complete and accept the health data sharing agreement. Once the health data sharing agreement is completed, the remote server 420 may store the completed agreement upon acceptance of the health data sharing agreement. Note, the step illustrated at 568 in FIG.5 may be similar to the step illustrated at 472 in FIG.4.

[0125] As illustrated at 570, the communication component 530 optionally stores the host information (from the access token) of the TPHS 150 (e.g., with the host information for one or more hosts from the FPHS 114 in the remote server 540. The storing of the host information enables recording a link between the TPHS 150 and FPHS 114 (e.g., associated with the specific account of FPHS 114 and the TPHS specific identifier, for example, from the access token).

[0126] As illustrated at 572, the communication component 530 prepares or processes health data (e.g., analyte data) for delivery (e.g., real-time, scheduled, etc.) for one or more hosts to the TPHS 150. For example, the processing of the health data may include processing raw analyte values (e.g., to estimated analyte values, for instance, estimated glucose values, estimated potassium values, estimated lactate values, etc.), aggregating analyte data (e.g., in to average hourly values, average daily values, etc.), etc. As illustrated at 574, upon initiating the delivery, the communication component 530 obtains an indication of one or more hosts linked with the TPHS 150 from the remote server 540. As illustrated at 576, the remote server 540 retrieves one or more consents for the one or more hosts linked with the TPHS 150. As illustrated at 578 and 580, the communication component 530 obtains health data for the oneor more linked hosts from the storage system 520, and send or provides the health data to the TPHS 150. As illustrated at 582, the TPHS 150 (via communication component 410) may notify the HCP 424 of new health data (e.g., analyte data) available for the one or more linked hosts.

[0127] FIG. 6 illustrates an example communication flow 600 for seamless and secure health data sharing, according to certain embodiments. In certain embodiments, the communication flow 600 may be used to implement the workflow 400 illustrated in FIG. 4 or the workflow 500 illustrated in FIG. 5.

[0128] As illustrated at 602, the TPHS 150 redirects an access request (including an authentication token as described herein) to the FPHS 114. For example, as noted above, the application 156 may transmit an access request to the FPHS 114 on behalf of a user account of the application 156 (of TPHS 150) to initialize a connection between the FPHS 114 and TPHS 150. As also noted above, the authentication token (e.g., launch token) may identify the user account in the TPHS 150 (but does not include any PII associated with the user account) and may indicate that the user account in the TPHS 150 that has initiated the access request is authenticated on the TPHS 150.

[0129] As illustrated at 604 and 606, the FPHS 114 performs a token exchange with the TPHS 150 to exchange the authentication token for a user access token. FPHS 114 may authenticate the access token received from TPHS 150 by using a public key associated with the TPHS 150 (e.g., a public key associated with an EHR, EMR, or other record system) or by sending a request to TPHS 150 to confirm validity of the access token. As noted, the user access token may include a user context. The user context may include a TPHS specific identifier associated with the user account of the TPHS 150, for example, a user ID associated with the user account of the TPHS 150 (but does not include any PII associated with the user account) (e.g., the user ID, for instance, 128 random characters generated by TPHS 150, may not be indicative of (or include) a medical records number (MRN) for the user account or an internal primary key for the user account on TPHS 150). . In some embodiments, at 606, the TPHS 150 may provide a proxy identifier in addition to the user access token to the FPHS 114. The proxy identifier may include an indication of whether the user account on the TPHS 150 is associated with one or more dependent accounts on the TPHS 150 (e.g., one or more TPHS 150 specific identifiers which may include one or more TPHS 150 specific identifiers associated with one or more dependents, a flag or value indicating that there are one or more dependents associated with user account of the TPHS 150, a flag identifying the user account of the TPHS 150 as adependent account, etc.) (but does not include any PII associated with the user account and / or the dependent accounts).

[0130] As illustrated at 608, the communication component 430 initializes a platform generated state value (e.g., session identifier, FPHS 114 generated access token, FPHS 114 generated cookie, etc.) to identify the communication session between the TPHS 150 and the FPHS 114 as the user account of the FPHS 114 is redirected (or interacts) with components of the FPHS 114. As noted above, the platform generated state value may indicate that the user account of the FPHS 114 is authorized to access the application 108 of FPHS 114. At 608, the communication component 430 may also store the user access token and the proxy identifier (if available) in association with the platform generated state value.

[0131] As illustrated at 610, the communication component 430 redirects the access request from the TPHS 150 to the application 108 for continued onboarding. As noted, here the communication component 430 may modify the access request to include the platform generated state value.

[0132] As illustrated at 612, in response to the application 108 determining the user account of the FPHS 114 is authenticated with the application 108, the application 108 redirects the access request to the communication component 430 with the state value and user identifier (e.g., within FPHS 114). As illustrated at 614, the communication component 430 verifies the user access token and identifies the communication session, based on the platform generated state value. As illustrated at 616, the communication component 430 stores a “Health System Connection” IN_PROGRESS connection state for the user identifier of the FPHS 114.

[0133] As illustrated at 618, the communication component 430 redirects the user account of the FPHS 114 to the remote server 420 to complete a health data sharing agreement (e.g., consent agreement). In certain embodiments, the communication component 430 provides an indication of a proxy flag, user identifier (e.g., with FPHS 114) and the platform generated state value when redirecting the user account of the FPHS 114 to the remote server 420. The proxy flag may be set to a value indicating that the user account of TPHS 150 has one or more associated dependent accounts. As noted, the FPHS 114 may determine, in response to the user context within the user access token indicating that the request from TPHS 150 is associated with one or more dependents, whether the user account of FPHS 114 is associated with one or more dependent accounts.

[0134] As illustrated at 620, when the proxy flag indicates the user account of the TPHS 150 has one or more dependents, the remote server 420 provides a dependent account selection screen for display on the display device associated with the user. As illustrated at 622, in response to selection of a dependent account, the remote server 420 presents a health data sharing agreement (e.g., consent agreement) associated with the selected dependent for display on the display device. The remote server 420 then stores the completed agreement upon acceptance of the health data sharing agreement.

[0135] As illustrated at 624, the remote server 420 redirects the user account of the FPHS 114 to the communication component 430. The redirect may include a success or failure value indicating whether the user account of the FPHS 114 has been associated or linked with the TPHS 150 or whether data sharing has been enabled, and a state parameter (e.g., the platform generated state value mentioned above). As illustrated at 626, the communication component 430 may determine the communication session, based on the platform generated state value, associated with the user account of FPHS 114 (e.g., a dependent user account of FPHS 114). As illustrated at 628, the communication component 430 updates a state of the health system connection or link to active or inactive, based on the communication session associated with the user account FPHS 114 (e.g., a dependent user account FPHS 114) (e.g., determined at 626). As illustrated at 630, the FPHS app 108 may display an indication of whether the connection is successful on a display device associated with the user account of the FPHS 114.

[0136] In certain embodiments, the third-party consent view that is provided for display on the display device associated with the user of the FPHS 114 (e.g., display device 107 or display device 152) may be based on (z) whether the user account of the FPHS 114 is a host type, caregiver type (e.g., parent or caregiver), or dependent type (e.g., minor, child, adult with a caregiver, etc.), (zz) whether the user account of the TPHS 150 is authenticated with the TPHS 150 (e.g., based on the authentication token from the TPHS 150, based on the access token from the TPHS 150, or combination thereof), (zzz) whether the user account of the FPHS 114 is authenticated with the FPHS 114 (e.g., logged in to FPHS 114), or (zv) any combination thereof. By way of example, FIG. 7 depicts a table 700 illustrating different flows for the consent view depending on the type of user account of the FPHS 114, whether the user account of the TPHS 150 is authenticated with the TPHS 150, and whether the user account of the FPHS 114 is authenticated with the FPHS 114, according to certain embodiments.

[0137] As shown in FIG. 7, for row or flow 1, when the user account of the TPHS 150 is authenticated with the TPHS 150 (e.g., as a host or patient), the user account of the FPHS 114authenticated with the FPHS 114 (e.g., as a host or patient), and the user account of the FPHS 114 is a host type (e.g., patient account), the FPHS 114 may not display the dependent account selection screen. Instead, the FPHS 114 may display a connect account screen, followed by a consent screen, followed by a connection established screen. In certain embodiments, the connect account screen may include a “return to login” button that enables the user to return to login into a different account of the FPHS 114, such as a parent or caregiver account.

[0138] As shown in FIG. 7, for row or flow 2, when the user account of the TPHS 150 is authenticated with the TPHS 150 (e.g., as a parent or caregiver), the user account of the FPHS 114 authenticated with the FPHS 114 (e.g., as a parent or caregiver), and the user account of the FPHS 114 is a caregiver type (e.g., parent, guardian, relative, caregiver, for example, nurse, home health aide, personal hygiene assistant, etc.), the FPHS 114 may display the dependent account selection screen (e.g., multi-account selection screen, for example, FIG. 8C or FIG.10C). Once the user account of the FPHS 114 (e.g., caregiver) selects a dependent account, the FPHS 114 may display a consent screen for the dependent account followed by a connection established screen. In this flow 2, the FPHS 114 can determine that the user is coming from the TPHS 150 (e.g., based on the authentication token received from the TPHS 150) and that the user is the caregiver (or proxy) as opposed to the host 102 (e.g., patient / dependent, for example, as shown with flow 1). Thus, the FPHS 114 shows the caregiver the dependent account selection screen to allow the caregiver to select the correct dependent account to link with the TPHS 150. The link between the FPHS 114 and TPHS 150 may then be used to share or communicate data as described herein.

[0139] As shown in FIG. 7, for row or flow 3, when the user account of TPHS 150 is authenticated with the TPHS 150 (e.g., as a dependent), the user account of the FPHS 114 authenticated with the FPHS 114 (e.g., as a dependent), and the user account of the FPHS 114 is a dependent type (e.g., minor or adult dependent), the FPHS 114 may not display the dependent account selection screen. It is appreciated that flow 3 may be similar to flow 1. Additionally, it is noted that in certain embodiments, dependents / minors may be allowed to provide consent for third-party health system connections. Instead, the FPHS 114 may display a connect account screen, followed by a consent screen, followed by a connection established screen. In certain embodiments, the connect account screen may include a “return to login” button that enables the user to return to login into a different account of the FPHS 114, such as a parent or caregiver account.

[0140] As shown in FIG. 7, for row or flow 4, when the user account of TPHS 150 is authenticated with the TPHS 150 (e.g., as a partner or spouse of the host), the user account of the FPHS 114 authenticated with the FPHS 114 (e.g. as the patient or host), and the user account of the FPHS 114 is a caregiver type (e.g., partner or spouse), the FPHS 114 may not display the dependent account selection screen (e.g., due to the partner or spouse not being a dependent or having dependents, or being a caregiver account). Instead, the FPHS 114 may display a connect account screen, followed by a consent screen, followed by a connection established screen. Here, because the user account of the FPHS 114 is a non-dependent associated account type (e.g., another parent without associated dependent account(s), an adult dependent, a partner, etc.), the FPHS 114 does not open or display the dependent account selection screen since there are no dependent accounts to select from. Instead, the FPHS 114 may display a connect account screen, followed by a consent screen, followed by a connection established screen. In certain embodiments, the connect account screen may include a “return to login” button that enables the user to return to login into a different account of the FPHS 114, such as a parent or caregiver account.

[0141] As shown in FIG. 7, for row or flow 5, when the user account of TPHS 150 is authenticated with the TPHS 150 (e.g., as a parent or caregiver), the user account of the FPHS 114 authenticated with the FPHS 114 (e.g., as a dependent, the FPHS 114 may not display the dependent account selection screen. In other words, the account logged into the FPHS 114 is the dependent’s account. Instead, the FPHS 114 may display a connect account screen, followed by a consent screen, followed by a connection established screen. Similar to flow 1, in certain embodiments, the connect account screen may include a “return to login” button available that enables the user to return to login for the FPHS 114 into a different account, such as a caregiver account.

[0142] FIGs. 8A-8E depict an example scenario for setting up sharing of dependent health information (e.g., analyte data, account information, etc.) from a FPHS (e.g., FPHS 114) to a TPHS (e.g., TPHS 150) via (or using) a caregiver account, according to certain embodiments. In particular, FIGs. 8A-8E illustrate an example sequence of screens (e.g., GUIs) presented on a display device (e.g., display device 152) for sharing the dependent’s health information from the FPHS to the TPHS. In FIGs. 8A-8E, the user account is a caregiver type (e.g., parent) that is authenticated with the FPHS 114 and the TPHS 150.

[0143] As shown in FIG.8A, a connections dashboard 800 presents an account screen 810 showing a set of GUI elements 802 (e.g., icons) corresponding to a set of user accounts withinthe TPHS 150. The connections dashboard 800 may be presented to an HCP (e.g., HCP 424), a parent, guardian, or a caregiver, within a TPHS application (e.g., EHR, EMR, or other system). The connections dashboard 800 may be presented on a display device (e.g., display device 107, 152, etc.) as part of application 156. For example, the set of GUI elements 802 includes a GUI element 802-1 associated with a “Dad” account, a GUI element 802-2 associated with a “Mom” account, a GUI element 802-3 associated with a “Child” account, and a GUI element 802-4 associated with a “Teen” account. In certain embodiments, a user (e.g., health care provider, for example, a doctor, a nurse, etc.) may select one of the GUI elements 802 in order to trigger the TPHS 150 to connect to the FPHS 114.

[0144] Upon selecting a GUI element associated with a user account that has a caregiver type (e.g., GUI element 802-1 associated with “Dad” account or GUI element 802-2 associated with “Mom” account), the connections dashboard 800 displays a screen 820 indicating that the user is being directed from the TPHS 150 to the FPHS 114, e.g., as shown in FIG. 8B. Upon onboarding from the TPHS 150 as a proxy / parent, the connections dashboard 800 is automatically modified to present a dependent account selection screen 830, which includes a list of one or more dependents for the user to select from, e.g., as shown in FIG. 8C.Connections dashboard 800 as shown in FIG.8C, may include one or more graphical elements generated from applications 106 and / or 108. For example, application 106 may display dependents based on information from host database 110. As another example, graphical elements from application 108 may be displayed within application 106 (e.g., via a webpage or webview).

[0145] As shown in FIG.8D, in response to selection of a dependent on the screen 830, a health data sharing agreement (e.g., consent agreement) is displayed on the connections dashboard 800 (e.g. from FPHS 114 via application 108 or from application 106). Once the health data sharing agreement is completed and accepted, the connections dashboard 800 displays a screen indicating a successful connection between the TPHS 150 and FPHS 114, e.g., as shown in FIG.8E.

[0146] FIGs. 9A-9D depict an example scenario for setting up sharing of host health information from a FPHS (e.g., FPHS 114) to a TPHS (e.g., TPHS 150) via (or using) a host account, according to certain embodiments. In particular, FIGs. 9A-9D illustrate an example sequence of screens (e.g., GUIs) presented on a display device (e.g., display device 107) for sharing the host’s health information from the FPHS to the TPHS. In FIGs. 9A-9D, the user account is a host type (e.g., patient or dependent) that is authenticated with the TPHS 150.Note, in some cases, certain dependents (e.g., minors) may not be able to consent to sharing their health data with another health system, such as TPHS 150.

[0147] As shown in FIG.9A, a connections dashboard 900 displays a screen 920 indicating that the user (e.g., host account of the TPHS 150) is being directed from the TPHS 150 to the FPHS 114. In certain embodiments, if the user account of FPHS 114 is not authenticated with the FPHS 114 as a host type, then the connections dashboard 900 may present a user login screen 930 that allows the user to login into the host account within the FPHS 114, e.g., as shown in FIG. 9B, before displaying the health data sharing agreement as shown in FIG. 9C.On the other hand, if the user account of the FPHS 114 is authenticated with the FPHS 114 as a host type, then the connections dashboard 900 may automatically present the health data sharing agreement as shown in FIG.9C.

[0148] Once the health data sharing agreement is completed and accepted, the connections dashboard 900 displays a screen indicating a successful connection between the TPHS 150 and FPHS 114 (e.g., between the user account of the TPHS 150 and the user account of the FPHS 114), e.g., as shown in FIG.9D.

[0149] FIGs. 10A-10E depict an example scenario for setting up sharing of dependent health information from a FPHS (e.g., FPHS 114) to a TPHS (e.g., TPHS 150) via (or using) a caregiver account, according to certain embodiments. In particular, FIGs. 10A-10E illustrate an example sequence of screens presented on a display device (e.g., display device 152, for example if a parent or caregiver device, or display device 107, for example, if a parent or caregiver device) for sharing the dependent’s health information from the FPHS to the TPHS. In FIGs. 10A-10E, the user account is a caregiver type (e.g., parent, guardian, caregiver, etc.) that is authenticated with the TPHS 150.

[0150] As shown in FIG. 10A, a connections dashboard 1000 displays a screen 1020 indicating that the user (e.g., caregiver account of the TPHS 150) is being directed from the TPHS 150 to the FPHS 114. In certain embodiments, if the user account of the FPHS 114 is not authenticated with the FPHS 114 as a caregiver type, then the connections dashboard 1000 may present a user login screen 1030 (e.g., presented via a web browser, webveiw, or application 106) that allows the user to login into the caregiver account within the FPHS 114, e.g., as shown in FIG. 10B, before displaying the dependent account selection screen 1040 as shown in FIG. 10C. On the other hand, if the user account of the FPHS 114 is authenticatedwith the FPHS 114 as a caregiver type, then the connections dashboard 1000 may automatically present the dependent account selection screen 1040 as shown in FIG. 10C.

[0151] As shown in FIG. 10D, in response to selection of a dependent on the screen 1040, a health data sharing agreement is displayed on the connections dashboard 1000. Once the health data sharing agreement is completed and accepted, the connections dashboard 1000 displays a screen indicating a successful connection between the TPHS 150 and FPHS 114 (e.g., between the user account of the TPHS 150 and the user account of the FPHS 114), e.g., as shown in FIG. 10E.Example Operations for Seamless and Secure Health Data Sharing

[0152] FIG. 11 illustrates an example flowchart 1100 for seamless and secure health data sharing between health systems, such as a FPHS (e.g., FPHS 114) and a TPHS (e.g., TPHS 150), in accordance with certain embodiments of the disclosure. In certain embodiments, the flowchart 1100 can be executed, for example, by the FPHS 114. In addition or alternatively, in certain embodiments, the flowchart 1100 can be executed, for example, by the application 108 (e.g., associated with or part of a FPHS). In addition or alternatively, in certain embodiments, the flowchart 1100 can be executed generally by any of the display devices 210, 220, 230 and / or 240 of FIG.2. In addition or alternatively, in certain embodiments, one or more portions of the flowchart 1100 can be executed by one or more computing devices (e.g., application server 112, remote server 420, data service 454, etc.) in a cloud computing environment. Although any number of systems, in whole or in part, can implement the flowchart 1100, to simplify discussion, the flowchart 1100 will be described primarily in relation to the FPHS (e.g., FPHS 114).

[0153] Flowchart 1100 may enter at block 1102, where the FPHS receives a request from a user account associated with the TPHS (e.g., TPHS 150) to access the FPHS. For example, a user of a display device running an application (e.g., application 154) associated with the TPHS may trigger the application to send the request to a communication component (e.g., communication component 430) within the FPHS. In some cases, the display device (e.g., display device 107) running the application associated with the TPHS may be associated with a host 102 (e.g., patient, dependent, etc.). In other cases, the display device (e.g., display device 152) running the application associated with the TPHS may be associated with a caregiver of the host 102 (e.g., parent or care provider providing care for a dependent, for example, a child, a minor, or an adult person). The request may include a first token (e.g.,authentication token) indicating that the user account of the TPHS is authenticated with the TPHS. The first token includes non-personally identifiable information (PIT) (non-PII) for a user associated with the user account of the TPHS. For example, the first token lacks any indication of PII for the user associated with the user account of the TPHS (e.g., the first token omits any indication of PII for the user associated with the user account of the TPHS).

[0154] At block 1104, the FPHS obtains, from the TPHS, a second token (e.g., user access token) associated with the user account of the TPHS. For example, the communication component within the FPHS may obtain the second token from a communication component (e.g., communication component 410) within the TPHS. The second token includes a non-PII identifier for a user associated with the user account of the TPHS. In some examples, the second token may include an indication of a type of the user account of the TPHS but lack any indication of PII for the user associated with the user account of the TPHS (e.g., the second token omits any indication of PII for the user associated with the user account of the TPHS). For instance, the second token may have one or more fields including a token type, a patient-associated identifier (e.g., TPHS specific identifier as described herein), a scope value (e.g., a permission indicator, for example, a value indicating that data can be written to the TPHS 150, a value indicating that data can be read from the TPHS 150, etc.), an expiration time or life, and an access token value (e.g., user context as mentioned herein). The patient-associated identifier may be similar to or the same as the user ID mentioned above. As noted above, the type of the user account may optionally be included in the access token and may be a caregiver account type, a host account type, or a dependent account type.

[0155] At block 1106, the FPHS determines whether the type of user account is a caregiver account type, e.g., based on the second token. If the type of the user account is the caregiver account type, then the flowchart 1100 proceeds to block 1108. On the other hand, if the type of the user account is a host account type or a dependent account type, then the flowchart 1100 proceeds to block 1128.

[0156] At block 1108, the FPHS determines whether the user account of the FPHS is authenticated with the FPHS as the caregiver account type (e.g., the FPHS may determine whether the user account of the FPHS is logged into the application 108 as a caregiver). If the user account of the FPHS is authenticated with the FPHS as the caregiver account type (e.g., the user account of the FPHS is logged into the application 108 as a caregiver), then the flowchart 1100 proceeds to block 1110. On the other hand, if the user account of the FPHS is not authenticated with the FPHS as the caregiver account type (e.g., the user account of theFPHS is not logged into the application 108 as a caregiver), then the flowchart 1100 proceeds to block 1120.

[0157] At block 1120, the FPHS causes a screen prompting the user associated with the user account of the FPHS to authenticate with the FPHS as a caregiver account to display in a GUI on a display device (e.g., display device 152) associated with the user. By way of example, the user login screen 1030 illustrated in FIG. 10B may be presented in the GUI on the display device (e.g., display device 107 or display device 152) to allow the user to login into the caregiver account within the FPHS. The flowchart 1100 may proceed to block 1108 from block 1120.

[0158] At block 1110, the FPHS determines whether there is at least one dependent account associated with the caregiver account type. If not, then the flowchart 1100 proceeds to block 1122, where the FPHS causes a screen prompting the user associated with the user account of the FPHS to authenticate with the FPHS using another account having a different account type (e.g., host account type or dependent account type) to display in a GUI on the display device. By way of example, the user login screen 1030 illustrated in FIG. 10B may be presented in the GUI on the display device to allow the user to login into another account type within the FPHS. The flowchart 1100 may proceed to block 1106 from block 1122.

[0159] On the other hand, if, at block 1110, the FPHS determines there is at least one dependent account associated with the caregiver account type at 1110, then the flowchart 1100 proceeds to block 1112, where the FPHS causes a screen including an indication of the at least one dependent account to display in a GUI on the display device. By way of example, the dependent account selection screen 830 illustrated in FIG.8C or dependent account selection screen 1040 illustrated in FIG.10C may be presented in the GUI on the display device to allow the user to select one of the dependent accounts.

[0160] At block 1114, the FPHS determines whether one of the dependent accounts within the dependent account selection screen has been selected. If not, the flowchart 1100 may remain at block 1114 until a dependent account is selected or the flowchart 1100 may exit (e.g., the user may return to a different screen, the user may cancel the health sharing onboarding, etc.). In response to selection of a dependent account from the dependent account selection screen, the flowchart 1100 proceeds to block 1116, where the FPHS causes a screen including a consent agreement for sharing health data of the selected dependent account with the TPHS to display in the GUI on the display device. By way of example, the health data sharing agreementillustrated in FIG. 8D or the health data sharing agreement illustrated in FIG. 10D may be displayed in the GUI on the display device.

[0161] At block 1124, the FPHS receives an indication that the consent agreement is completed and accepted. At block 1126, in response to the indication that the consent agreement is completed and accepted, the FPHS establishes a communication link between the FPHS and the TPHS for sharing the health data of the selected dependent account. For example, the health data may include analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account. In certain embodiments, the analyte monitor is a continuous analyte monitor.

[0162] Referring back to block 1106, if the type of the user account is a host account type or a dependent account type (e.g., a patient’s own account, a child’s account, a dependent adult’s account, etc.), then the flowchart 1100 proceeds to block 1128, where the FPHS determines whether the user account of the FPHS is authenticated with the FPHS. For example, if the type of the user account is a host account type, then the FPHS may determine whether the user account of the FPHS is authenticated with the FPHS as the host account type. In another example, if the type of the user account is a dependent account type, then the FPHS may determine whether the user account of the FPHS is authenticated with the FPHS as the dependent account type.

[0163] If, at block 1128, the FPHS determines that the user account of the FPHS is not authenticated with the FPHS, then the flowchart 1100 proceeds to block 1130, where the FPHS causes a screen prompting the user account of the FPHS to authenticate with the FPHS to display in a GUI on the display device. By way of example, assuming the user account is a host account type, the user login screen 930 illustrated in FIG. 9B may be presented in the GUI on the display device to allow the user associated with the user account of the FPHS to authenticate with the FPHS as the host account type. Similarly, by way of another example, assuming the user account is a dependent account type, the user login logic screen 930 illustrated in FIG. 9B may be presented in the GUI on the display device to allow the user associated with the user account of the FPHS to authenticate with the FPHS as the dependent account type.

[0164] On the other hand, if, at block 1128, the FPHS determines that the user account of the FPHS is authenticated with the FPHS, then the flowchart 1100 proceeds to block 1132, where the FPHS causes a screen including a consent agreement for sharing health data of the user account (e.g., host account type or dependent account type) with the TPHS to display inthe GUI on the display device (e.g., display device 107 or display device 152). By way of example, the health data sharing agreement illustrated in FIG. 9C may be presented in the GUI on the display device to allow the user to complete and accept (or authorize) the health data sharing agreement.

[0165] At block 1134, the FPHS receives an indication that the consent agreement is completed and accepted. At block 1136, in response to the indication that the consent agreement is completed and accepted, the FPHS establishes a communication link between the FPHS and the TPHS (e.g., between the user account of the FPHS and the user account of the TPHS) for sharing the health data of the user account of the FPHS. For example, the health data may include analyte data obtained via an analyte monitor worn by a user associated with the user account. In certain embodiments, the analyte monitor is a continuous analyte monitor.Example Seamless and Secure Healthcare Provider Access to Health Systems

[0166] FIG. 12 illustrates an example workflow 1200 for seamless and secure HCP access to a FPHS 114 (e.g., health system associated with an analyte monitoring system for a host), according to certain embodiments. Compared to the workflow 400 illustrated in FIG. 4 and the workflow 500 illustrated in FIG. 5, the workflow 1200 illustrated in FIG. 12 may be used for allowing an HCP (e.g., HCP 424) of a host (e.g., patient or dependent, such as a minor or adult person receiving care from a caregiver) to seamlessly and securely access the host’s health information (e.g., analyte data, such as CGM data) in a FPHS 114, without transferring or exchanging the host’s PHI and / or PII. For example, the HCP may be granted access to an application or platform of FPHS 114 that can present host data or patient data (e.g., in a GUI).

[0167] Similar to the TPHS 150 illustrated in FIGs. 4 and 5, the TPHS 150 illustrated in FIG. 12 hosts or includes an application server 158, which executes application 156, and communication component 410. Compared to the TPHS 150 illustrated in FIGs. 4 and 5, the TPHS 150 illustrated in FIG. 12 further hosts or includes health records system 1220 (e.g., EHR(s), EMR(s), or other records) and an authorization server 1258.

[0168] The health records system 1220 may be generally representative of an EHR system, EMR system, or other clinical data management system maintained by a health system, such as the TPHS 150 or health system associated with the HCP 424. The health records system 1220 may include, without limitation, one or more servers (e.g., application servers) and associated databases configured to store, manage, and provide access to host information (e.g., diagnoses, laboratory results, medications, health data (including analyte data), etc.). Thehealth records system 1220 may be accessed by an HCP 424 via the computing system 422 and / or display device 152.

[0169] The authorization server 1258 may be generally representative of a computing system configured to perform secure login, authentication validation, and issuance of authorization codes and access tokens, among other tasks. For example, as described in greater detail herein, the authorization server 1258 may be configured to generate and issue a provider access token (e.g., an access token associated with an identifier of a provider account of the TPHS 150) that allows the provider account to access one or more components of the FPHS 114. In some embodiments, the provider access token may be similar to the user access token described above, for example, including a user context associated with the provider in this case. Although depicted separately from the application server 158 for the sake of clarity, in certain embodiments, the authorization server 1258 may be included within (or otherwise implemented as part of) the application server 158. In some embodiments, the health records system 1220, application server 158, authorization server 1258, and communication component 410 may be a single entity or distributed across one or more systems (e.g., servers, computing systems, etc.). Further, it should be noted that the TPHS 150 including components thereof (e.g., health records system 1220, application server 158, authorization server 1258) may communicate with other health systems, such as the FPHS 114 and components thereof, via the communication component 410.

[0170] Similar to the FPHS 114 illustrated in FIGs. 4 and 5, the FPHS 114 illustrated in FIG. 12 includes an application server 112, which executes application 108. Similar to the FPHS 114 illustrated in FIG. 5, the FPHS 114 illustrated in FIG. 12 includes a remote server 540 (e.g., a third-party linking server). Compared to the FPHS 114 illustrated in FIGs. 4 and 5, the FPHS 114 illustrated in FIG. 12 includes a communication component 1230. The communication component 1230 may be generally representative of an API server, which allows components of the FPHS 114 (including application 108) to communicate with other health systems (including components thereof), such as the TPHS 150 (including application 156, authorization server 1258, health records system 1220, and communication component 410). The communication component 1230 can use any suitable communication protocol to communicate with other health systems, such as the TPHS 150. In certain embodiments, the communication component 1230 may use the FHIR standard to access and exchange data. In some embodiments, the communication component 1230 may include or have functionality similar to communication components 430 and 530.

[0171] As illustrated at 1260 in FIG. 12, an HCP 424 (e.g., PCP) accesses a host’s health data (e.g., analyte data) in the TPHS 150. For example, the HCP 424 may access the host’s health data in the health records system 1220 (e.g., EHR system) to manage the host’s care (e.g., access test results, medications, immunization history, upcoming appointments, etc.), communicate with the host’s other health care provider(s), manage appointments, and share medical records, among other tasks. In some cases, the HCP 424 may access the host’s health data using a provider account associated with an identifier of the HCP 424 (e.g., provider ID) in the TPHS 150. The identifier of the HCP 424 may include a TPHS specific provider ID (e.g., 128 random characters generated by TPHS 150) that identifies the provider account but does not include (e.g., omits) any PII for the HCP 424.

[0172] In some cases, when accessing the host’s health data in the health records system 1220, the HCP 424 may determine a need or a desire to access the host’s health data (e.g., analyte data) in a FPHS 114 (e.g., a health system associated with a CGM application for the host), e.g., to obtain current (or more recent) or additional health information for the host. In such cases, the HCP 424 may launch a request within the TPHS 150 to access the host’s health data in the FPHS 114. For example, the application 156 may cause a GUI element to be displayed on a display device (e.g., display device 152) or computing system 422 associated with the HCP 424. For instance, the GUI element may be a button with text including “Provider Launch to FPHS” or similar text. In another example, the GUI element may be an icon (e.g., graphical representation) that is representative of (or otherwise associated with) a “Provider Launch to EPHS” action. In some embodiments, the GUI element may represent an application or platform associated with the LPHS 114. Lor example, the GUI element may include a logo, name, etc., of an analyte report generation application of LPHS 114 (e.g., analyte reports, for example, including trends or graphs, reports of analyte sensor utilization), or of a medication recommendation application or platform (e.g., insulin, hormone, medication, etc.). The GUI element may allow the HCP 424 to trigger the TPHS 150 to signal or connect to the LPHS 114. Lor example, at 1264, once the GUI element is selected, the health records system 1220 (e.g., EHR system) transmits (via the communication component 410) a launch request to the FPHS 114 on behalf of the provider account associated with the HCP 424.

[0173] As illustrated, the launch request is sent to the communication component 1230 within the FPHS 114. In certain embodiments, the launch request may include a launch token that is associated with the host account in the TPHS 150 that the provider account has accessed. In some examples, the launch token may include a TPHS specific identifier associated with thehost (e.g., a TPHS specific host ID, for instance, 128 random characters generated by TPHS 150), but does not include any PII associated with the host (e.g., the TPHS specific host ID may not be indicative of (or include) a MRN for the host or an internal primary key for the host on TPHS).

[0174] As illustrated at 1266 in FIG. 12, in response to receiving the launch request, the communication component 1230 acquires a provider access token that includes the provider ID and the TPHS specific host ID. As noted, the provider ID may include a TPHS specific provider ID associated with the provider account in the TPHS 150, but does not include any PII associated with the provider account. As described in greater detail herein, in some embodiments, the communication component 1230 may acquire the provider access token from the authorization server 1258 in response to validating (or confirming with the authorization server 1258, e.g., using cryptographic verification) that the provider account that initiated the launch request is authenticated on the TPHS 150 (e.g., the provider account is still logged into the TPHS 150).

[0175] The TPHS specific identifier (e.g., TPHS specific host ID) or the provider access token from the TPHS 150 may be used by the FPHS 114 to identify and retrieve a FPHS specific identifier associated with the host account (e.g., FPHS specific host ID) in the FPHS 114, and to establish a provider communication session for the FPHS specific identifier associated with the host account in the FPHS 114. For example, as illustrated at 1268 in FIG.12, in response to receiving the provider access token, the communication component 1230 performs a lookup for the FPHS specific identifier associated with the host account in the remote server 540, e.g., using the TPHS specific identifier associated with the host account in the TPHS 150. As discussed, as a result of the onboarding process described herein with respect to FIGs. 4-6 and 11, the remote server 540 may have previously included or stored an association (or mapping) between the TPHS specific identifier for the host account in the TPHS 150 and the FPHS specific identifier for the host account in the FPHS 114.

[0176] As illustrated at 1270 in FIG. 12, in response to obtaining the FPHS specific identifier for the host account in the FPHS 114, the FPHS 114 (via the communication component 1230 and application server 112) generates a session code and creates a provider session for the FPHS specific host ID using the generated session code. For example, the communication component 1230 may send the FPHS specific host ID to the application server 112. The application server 112 may then generate the session code (e.g., to enable access to a provider session to access the patient’s data), based on the FPHS specific host ID, and createthe provider session using the generated session code. In certain embodiments, the session code (e.g., a session identifier)) may be bound or associated with the authenticated provider account, the FPHS specific host ID (e.g., user identifier), one or more scope values (e.g., one or more provider permission indicators, for example, a value indicating that the provider can write data to FPHS 114, for instance, a medication treatment recommendation, a value indicating that the provider can read particular data from the FPHS 114, etc.), an expiration time or life (e.g., how long the provider can access data, application, platform, etc.), or any combination thereof.

[0177] As illustrated at 1272 in FIG.12, the application server 112 returns the session code 1272 to the communication component 1230 to allow the communication component 1230 to redirect or open an application portal (e.g., UI interface, such as a web browser, webview, or application 154) for the session with the session code, as illustrated at 1274 in FIG. 12. For example, at 1274, the communication component 1230 may send a hypertext transfer protocol (HTTP) redirect with a “location: uniform resource locator (URL)” that targets the application portal (e.g., on computing system 422 or display device 152) and carries the session code. As illustrated at 1276 in FIG. 12, the application portal presents the session code back to the application server 112 for validation (e.g., based on a record associating session code with the user identifier within FPHS 114). As illustrated at 1278, on successful validation of the session code, the application portal may open or display a screen (e.g., homepage, web browser GUI, displayed via THPS app 156, etc.) for the provider account to interact with. For example, the application portal may provide or display the host’s health data (e.g., analyte data) from the FPHS 114 on the screen (e.g., homepage), without requiring a manual lookup of the host or entry of the host’s PII.

[0178] FIG. 13 illustrates an example communication flow 1300 for seamless and secure healthcare provider access to a health system (e.g., FPHS 114), according to certain embodiments. In certain embodiments, the communication flow 1300 may be used to implement the workflow 1200 illustrated in FIG. 12. For example, the communication flow 1300 may allow an HCP to access an application or platform of another health system (e.g., FPHS 114).

[0179] As illustrated at 1310, a provider account associated with an identifier of an HCP 424 in the TPHS 150 may select a host account (e.g., patient account) in the TPHS 150 and access the health data of the host’s account in the TPHS 150. For example, the HCP 424 may access the host’s account in the TPHS 150 using a display device 152 (executing application 154) or a computing system 422 (executing application 156). After accessing the host’s accountin the TPHS 150, the provider account may initiate a launch into the FPHS 114, e.g., to view the health data of the host’s account in the FPHS 114. As noted, the HCP 424 may want to access the host’s health data in the FPHS 114 to manage the host’s care (e.g., access test results, medications, immunization history, upcoming appointments, etc.), communicate with the host’s other health care provider(s), manage appointments, and share medical records, make dosing recommendations (e.g., insulin, medications, etc.), among other tasks.

[0180] As illustrated at 1312, the health records system 1220 (e.g., via the communication component 410) optionally sends the launch request to the FPHS 114 on behalf of the provider account in the TPHS 150. As also noted above, the launch request may optionally include a launch token that is associated with the host account in the TPHS 150. For example, the launch token may include a TPHS specific identifier associated with the host account in the TPHS 150 (e.g., a TPHS specific host ID), but does not include any PII associated with the host account in the TPHS 150.

[0181] As illustrated at 1314, the FPHS 114 optionally redirects the provider account (e.g., computing system’s 422 web browser, webview, or application 154) to the authorization server 1258 with the launch token, e.g., to verify that the provider account that initiated the launch request is authenticated on the TPHS 150. For instance, the authorization server 1258 may verify that the provider account has a valid login into or has been authenticated with the TPHS 150. As illustrated at 1316, if authenticated or the authentication is performed (e.g., provider logs in), the authorization server 1258 redirects the provider account to the FPHS 114 with an authorization code (e.g., OAuth2 authorization code) associated with TPHS 150.

[0182] As illustrated at 1318, the FPHS 114 sends the authorization code to the authorization server 1258 to retrieve a provider access token associated with the provider account (e.g., of TPHS 150). For example, at 1318, the FPHS 114 may send a HTTP POST request, which includes the authorization code, to the authorization server 1258. At 1322, the authorization server returns the provider access token to the FPHS 114. For example, at 1322, the authorization server may send the provider access token in response to the HTTP POST request. As discussed, the provider access token may include a provider ID and the TPHS specific host ID. The provider ID may include a TPHS specific provider ID associated with the provider account in the TPHS 150, but does not include any PII associated with the provider account or the host. In some embodiments, the provider ID may be associated with a provider and with a particular host (e.g., patient) of TPHS 150 (but not include any PII associated with the provider or the host).

[0183] As illustrated at 1324, the FPHS 114 performs a lookup for a FPHS specific identifier for the host account in the FPHS 114, e.g., using the TPHS specific host ID. As discussed, the FPHS 114 may determine the FPHS specific host ID that is associated with the TPHS specific host ID, based on a previously established association (or mapping) between the FPHS specific host ID and the TPHS specific host ID obtained from an onboarding process described herein (e.g., as described with respect to FIGs. 4-5, etc.).

[0184] As illustrated at 1326, in response to obtaining the FPHS specific host ID, the FPHS 114 may initiate a provider session for the FPHS specific host ID. For example, the FPHS 114 may initiate the provider session by sending a HTTP POST request to an application portal 1320 (e.g., web browser, webview, or application 154) associated with the application 108 (e.g., CGM application) in the FPHS 114. Application portal 1320 may include one or more displays or GUIs of an application (e.g., analyte reporting application, medication recommendation application or platform, etc.) that may be generated, in part or in whole, by FPHS 114 (e.g., including content or data from FPHS app 108). Portions of application portal 1320 may be displayed on computing system 422, display device 152, or other system getting data from application 156.

[0185] As illustrated at 1328, the application portal 1320 creates the provider session, generates a session code (e.g., session identifier) and stores the session code. As illustrated at 1330, the application portal 1320 returns the session code to the FPHS 114. As illustrated at 1332, the FPHS 114 redirects the provider account to the application portal 1320 with the session code. As illustrated at 1334, the application portal 1320 validates the session code (e.g., based on a record associating the session code with the user identifier within FPHS 114). As illustrated at 1336, in response to a successful validation of the session code, the application portal 1320 locates the FPHS specific host ID and opens a screen (e.g., homepage) of the application portal 1320 for the HCP 424 to interact with.Example Operations for Seamless and Secure Healthcare Provider Access to Health Systems

[0186] FIG. 14 illustrates an example flowchart 1400 for seamless and secure healthcare provider access to a health system, such as a FPHS (e.g., FPHS 114), in accordance with certain embodiments of the disclosure. In certain embodiments, the flowchart 1400 can be executed, for example, by the FPHS 114 (or one or more portions thereof). In addition or alternatively, in certain embodiments, the flowchart 1400 can be executed, for example, by the application 108 (e.g., associated with or part of a FPHS). In addition or alternatively, in certainembodiments, the flowchart 1400 can be executed generally by any of the display devices 210, 220, 230 and / or 240 of FIG. 2 or display devices 107 and 152 of FIG. 1. In addition or alternatively, in certain embodiments, one or more portions of the flowchart 1400 can be executed by one or more computing devices (e.g., application server 112, remote server 540, etc.) in a cloud computing environment. Although any number of systems, in whole or in part, can implement the flowchart 1400, to simplify discussion, the flowchart 1400 will be described primarily in relation to the FPHS (e.g., FPHS 114).

[0187] Flowchart 1400 may enter at block 1402, where the FPHS receives a provider launch request to access health data of a host account in a FPHS. As discussed above, the launch request may include a launch token indicating a TPHS specific identifier (e.g., TPHS specific host ID) associated with a host account in a TPHS, but does not include PII of the host account in the TPHS. In some examples, a provider account associated with an identifier of an HCP (e.g., HCP 424) in the TPHS may trigger the TPHS (e.g., TPHS 150) to send the launch request to the FPHS (e.g., FPHS 114). For example, a display device (e.g., display device 152) or computing system (e.g., computing system 422) may trigger an application (e.g., application 156) associated with the TPHS to send the launch request to the FPHS.

[0188] At block 1404, the FPHS obtains a provider access token including a provider ID associated with the provider account and the TPHS specific identifier (e.g., TPHS specific host ID) for the host account in the TPHS. As discussed above, the FPHS may exchange an authorization code (e.g., obtained from the TPHS and used to authenticate the provider account) for the provider access token.

[0189] At block 1406, the FPHS may use the provider access token to perform a lookup of FPHS specific identifiers associated with one or more host accounts within the FPHS (e.g., within a remote server 540 of the FPHS) and determine whether the FPHS includes a FPHS specific host ID that is associated with the TPHS specific host ID (e.g., which may be associated based on prior sharing of data from FPHS 114 to TPHS 150). If so, then the flowchart 1400 proceeds to block 1410. If not, then the flowchart 1400 proceeds to block 1408.

[0190] At block 1408, the FPHS may notify the provider account or display notification that a FPHS specific host ID associated with the TPHS specific host ID was not located and / or route the provider account to an alternate workflow (e.g., establish data sharing between FPHS 114 and TPHS 150, establish data sharing between an account of FPHS 114 and an account of TPHS 150) to access the health data of the host account in the FPHS. For example, the FPHSmay instruct or request the provider account to complete an onboarding procedure for the host account in the TPHS, for instance, using the onboarding techniques described herein (e.g., described with respect to FIGs. 4-6, etc.).

[0191] At block 1410, the FPHS generates a FPHS session code (e.g., session identifier). At block 1412, the FPHS creates a session for the provider account with the FPHS session code. At block 1414, the FPHS validates the FPHS session code. At block 1416, the FPHS opens a screen of an application portal associated with the session to allow the provider account to access the health data of the host account in the FPHS.Example Computing System

[0192] FIG. 15 is a block diagram depicting a computing system 1500. In certain embodiments, the computing system 1500 is representative of a FPHS 114 configured to execute application 108. In other embodiments, the computing system 1500 is representative of a TPHS 150 configured to execute application 156. Although depicted as a single physical device, in embodiments, computing system 1500 may be implemented using virtual device(s), and / or across a number of devices, such as in a cloud environment. As illustrated, computing system 1500 includes a processor 1505, memory 1510, storage 1515, a network interface 1525, and one or more VO interfaces 1520. In the illustrated embodiment, processor 1505 retrieves and executes programming instructions stored in memory 1510, as well as stores and retrieves application data residing in storage 1515. Processor 1505 is generally representative of a single central processing unit (CPU) and / or graphics processing unit (GPU), multiple CPUs and / or GPUs, a single CPU and / or GPU having multiple processing cores, and the like. Memory 1510 is generally included to be representative of a random-access memory. Storage 1515 may be any combination of disk drives, flash-based storage devices, and the like, and may include fixed and / or removable storage devices, such as fixed disk drives, removable memory cards, caches, optical storage, network attached storage (NAS), or storage area networks (SAN).

[0193] In some embodiments, input and output (VO) devices 1535 (such as keyboards, monitors, etc.) can be connected via the VO interface(s) 1520. Further, via network interface 1525, computing system 1500 can be communicatively coupled with one or more other devices and components, such as host database 110, as an illustrative example. In certain embodiments, computing system 1500 is communicatively coupled with other devices via a network, which may include the Internet, local network(s), and the like. The network may include wired connections, wireless connections, or a combination of wired and wireless connections. Asillustrated, processor 1505, memory 1510, storage 1515, network interface(s) 1525, and I / O interface(s) 1520 are communicatively coupled by one or more interconnects 1530. In certain embodiments, computing system 1500 is representative of display device 107 associated with the host or display device 152. In certain embodiments, as discussed above, the display device 107 can include the host’s laptop, computer, smartphone, and the like. In another embodiment, computing system 1500 is a server executing in a cloud environment.

[0194] In the illustrated embodiment, storage 1515 includes host profile 118. In certain embodiments, memory 1510 includes application 108. In other embodiments, memory 1510 includes application 156.Example Embodiments

[0195] Implementation examples are described in the following numbered clauses:

[0196] Clause 1: A computer-implemented method for seamless and secure access to a third-party health system for sharing health data, the computer-implemented method comprising: receiving a request from a user account associated with the third-party health system to access a first-party health system, wherein the request comprises a first token indicating that the user account is authenticated with the third-party health system; obtaining, from the third-party health system, a second token associated with the user account; determining a type of the user account, based on the second token; determining whether the user account is authenticated with the first-party health system; and in response to determining (z) the type of the user account is a caregiver account type and (zz) the user account is authenticated with the first-party health system as the caregiver account type: determining at least one dependent account associated with the user account; causing a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receiving an indication of a selected dependent account from the first screen; responsive to the indication of the selected dependent account, causing a second screen comprising an indication of a consent agreement for sharing health data of the selected dependent account with the third-party health system to display in the GUI on the display device; and establishing a communication link between the first-party health system and the third-party health system for sharing the health data of the selected dependent account.

[0197] Clause 2: The computer-implemented method of Clause 1, wherein determining whether the user account is authenticated with the first-party health system comprises determining that the user account is unauthenticated with the first-party health system as thecaregiver account type, the computer-implemented method further comprising, in response to determining that (z) the type of the user account is the caregiver account type and (zz) the user account is unauthenticated with the first-party health system as the caregiver account type, refraining from causing the first screen comprising the indication of the at least one dependent account to display in the GUI on the display device.

[0198] Clause 3: The computer- implemented method of Clause 2, wherein, in response to determining that (z) the type of the user account is the caregiver account type and (zz) the user account is unauthenticated with the first-party health system as the caregiver account type, the computer-implemented method further comprises causing a third screen prompting a user associated with the user account to authenticate with the first-party health system as the caregiver account type to display in the GUI on the display device.

[0199] Clause 4: The computer-implemented method according to any of Clauses 2-3, wherein determining that the user account is unauthenticated with the first-party health system as the caregiver account type comprises determining that the user account is authenticated with the first-party health system as a host account type.

[0200] Clause 5: The computer- implemented method according to any of Clauses 2-3, wherein determining that the user account is unauthenticated with the first-party health system as the caregiver account type comprises determining that the user account is authenticated with the first-party health system as a dependent account type.

[0201] Clause 6: The computer-implemented method according to any of Clauses 1-5, further comprising, in response to determining that (z) the type of the user account is a dependent account type and (zz) the user account is authenticated with the first-party health system as the dependent account type: causing a third screen comprising an indication of a consent agreement for sharing health data of the user account with the third-party health system to display in the GUI on the display device; and establishing a communication link between the first-party health system and the third-party health system for sharing the health data of the user account.

[0202] Clause 7: The computer-implemented method of Clause 6, wherein a user associated with the user account is a dependent adult.

[0203] Clause 8: The computer-implemented method according to any of Clauses 1-7, further comprising, in response to determining that (z) the type of the user account is a host account type and (zz) the user account is authenticated with the first-party health system as thehost account type: causing a third screen comprising an indication of a consent agreement for sharing health data of the user account with the third-party health system to display in the GUI on the display device; and establishing a communication link between the first-party health system and the third-party health system for sharing the health data of the user account.

[0204] Clause 9: The computer-implemented method according to any of Clauses 1-8, wherein each of the first token and the second token comprises non-personally identifiable information (PIT) (non-PII) for a user associated with the user account.

[0205] Clause 10: The computer-implemented method according to any of Clauses 1-9, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0206] Clause 11: The computer-implemented method according to any of Clauses 1-10, wherein the second token comprises an indication of the type of the user account.

[0207] Clause 12: A computer-implemented method for seamless and secure access to a third-party health system for sharing health data, the computer-implemented method comprising: receiving a request from a user account associated with the third-party health system to access a first-party health system, wherein the request comprises a first token indicating that the user account is authenticated with the third-party health system; obtaining, from the third-party health system, a second token associated with the user account; determining a type of the user account, based on the second token; determining whether the user account is authenticated with the first-party health system; and in response to determining (z) the type of the user account is a caregiver account type and (zz) the user account is authenticated with the first-party health system as the caregiver account type: determining at least one dependent account associated with the user account; causing a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receiving an indication of a selected dependent account from the first screen; and after receiving an indication of the selected dependent account, establishing a communication link between the first-party health system and the third-party health system for sharing health data of the selected dependent account.

[0208] Clause 13: The computer-implemented method of Clause 12, wherein, in response to determining (z) the type of the user account is the caregiver account type and (zz) the user account is authenticated with the first-party health system as the caregiver account type, the computer-implemented method further comprises causing a second screen comprising anindication of a consent agreement for sharing the health data of the selected dependent account with the third-party health system to display in the GUI on the display device.

[0209] Clause 14: The computer-implemented method of Clause 13, wherein, in response to determining (z) the type of the user account is the caregiver account type and (zz) the user account is authenticated with the first-party health system as the caregiver account type, the computer-implemented method further comprises receiving an indication that the consent agreement has been completed and accepted by a user associated with the user account.

[0210] Clause 15: The computer-implemented method of Clause 14, wherein the communication link is established between the first-party health system and the third-party health system after receiving the indication that the consent agreement has been completed and accepted by the user associated with the user account.

[0211] Clause 16: The computer-implemented method according to any of Clauses 12-15, wherein each of the first token and the second token comprises non-personally identifiable information (PIT) (non-PII) for a user associated with the user account.

[0212] Clause 17: The computer-implemented method according to any of Clauses 12-16, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0213] Clause 18: The computer-implemented method according to any of Clauses 12-17, wherein the second token comprises an indication of the type of the user account.

[0214] Clause 19: A method for sharing data to a third-party health system, the method comprising: receiving a request, at a first-party health system, from a user account associated with the third-party health system to receive health data from the first-party health system, wherein the request comprises a first token indicating that the user account of the third-party health system is authenticated with the third-party health system; obtaining, from the third-party health system, a second token associated with the user account of the third-party health system; determining whether a user account of the first-party health system is authenticated with the first-party health system, wherein a session associated with the user account of the first-party health system receives the request from the user account associated with the third-party health system; determining a type of the user account associated with the first-party health system; and in response to determining (z) the type of the user account associated with the first-party health system is a caregiver account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the caregiveraccount type: determining at least one dependent account associated with the user account of the first-party health system; causing a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receiving an indication of a selected dependent account from the first screen; and establishing a link between the selected dependent account of the first-party health system and the user account of the third-party health system for sharing health data of the selected dependent account with the third-party health system.

[0215] Clause 20: The method of Clause 19, further comprising associating the second token with the selected dependent account of the first-party health system.

[0216] Clause 21: The method according to any of Clauses 19-20, further comprising providing the first token to the third-party health system, wherein the second token is obtained based on the first token being provided to the third-party health system.

[0217] Clause 22: The method according to any of Clauses 19-21, further comprising, responsive to the indication of the selected dependent account, causing a second screen comprising an indication of a consent agreement for sharing the health data of the selected dependent account with the third-party health system to display in the GUI on the display device.

[0218] Clause 23: The method according to any of Clauses 19-22, wherein determining whether the user account of the first-party health system is authenticated with the first-party health system comprises determining that the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type, the method further comprising, in response to determining that (z) the type of the user account associated with the first-party health system is the caregiver account type and (zz) the user account associated with the first-party health system is unauthenticated with the first-party health system as the caregiver account type, refraining from causing the first screen comprising the indication of the at least one dependent account to display in the GUI on the display device.

[0219] Clause 24: The method of Clause 23, further comprising, in response to determining that (z) the type of the user account of the first-party health system is the caregiver account type and (zz) the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type, causing a third screen to display in the GUI on the display device, the third screen prompting a user associated with the user account of the first-party health system to authenticate with the first-party health system as the caregiver accounttype; wherein determining that the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type comprises determining that the user account of the first-party health system is authenticated with the first-party health system as a dependent account type.

[0220] Clause 25: The method according to any of Clauses 19-24, further comprising, in response to determining that (z) the type of the user account associated with the first-party health system is a dependent account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the dependent account type: causing a third screen comprising an indication of a consent agreement for sharing health data of the user account associated with the first-party health system with the third-party health system to display in the GUI on the display device; and establishing a link between the user account associated with the first-party health system and the user account associated with the third-party health system for sharing the health data of the user account associated with the first-party health system with the third-party health system.

[0221] Clause 26: The method according to any of Clauses 19-25, further comprising, in response to determining that (z) the type of the user account of the first-party health system is a host account type and (zz) the user account of the first-party health system is authenticated with the first-party health system as the host account type: causing a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing health data of the user account of the first-party health system with the third-party health system; and establishing a link between the user account of the first-party health system and the user account of the third-party health system for sharing the health data of the user account of the first-party health system with the third-party health system.

[0222] Clause 27: The method according to any of Clauses 19-26, wherein each of the first token and the second token omits personally identifiable information (PII) for a user associated with the user account.

[0223] Clause 28: The method according to any of Clauses 19-27, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0224] Clause 29: The method according to any of Clauses 19-28, further comprising: receiving, at the first-party health system, a request from a provider account associated with the third-party health system to access health data of a host account in the first-party healthsystem, wherein the request comprises a third token indicating a first identifier associated with a host account in the third-party health system; determining a second identifier associated with the host account in the first-party health system, based on an association between (z) the first identifier associated with the host account in the third-party health system and (zz) the second identifier associated with the host account in the first-party health system; and establishing a session associated with the provider account for accessing the health data of the host account in the first-party health system based on the second identifier.

[0225] Clause 30: The method of Clause 29, further comprising: verifying that the provider account is authenticated with the third-party health system; and obtaining, from the third-party health system, a fourth token associated with the provider account in response to the verification of the authentication of the provider account with the third-party health system.

[0226] Clause 31 : The method of Clause 30, wherein each of the third token and the fourth token omits personally identifiable information (PIT) for a provider associated with the provider account and a host associated with the host account in the third-party health system.

[0227] Clause 32: The method according to any of Clauses 29-31, further comprising determining the association between the first identifier and the second identifier in response to establishing a link between the host account of the first-party health system and the host account of the third-party health system.

[0228] Clause 33: The method according to any of Clauses 29-32, wherein the host account of the first-party health system is a dependent account.

[0229] Clause 34: A method by a display device, the method comprising: causing a first screen to display in a graphical user interface (GUI) on the display device, the first screen comprising an indication of at least one user account in a third-party health system; receiving an indication of a selected user account from the first screen; in response to the indication of the selected user account, transmitting, to the third-party health system, a request from the selected user account associated with the third-party health system to receive health data from the first-party health system; and when (z) the selected user account of the third-party health system is authenticated with the third-party health system and (zz) a user account associated with the first-party health system is authenticated with the first-party health system as a caregiver account type: causing a second screen to display in the GUI on the display device, the second screen comprising an indication of at least one dependent account in the first-party health system; receiving a selection of a dependent account from the second screen; andtransmitting an indication of the selected dependent account from the second screen, wherein a link is established between the selected dependent account of the first-party health system and the selected user account of the third-party health system.

[0230] Clause 35: The method according to Clause 34, further comprising, responsive to the indication of the selected dependent account from the second screen, causing a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing the health data of the selected dependent account.

[0231] Clause 36: The method according to any of Clauses 34-35, further comprising, when the user account associated with the first-party health system is unauthenticated with the first-party health system as a caregiver account type, refraining from causing the second screen to display in the GUI on the display device.

[0232] Clause 37: The method according to any of Clauses 34-36, further comprising, when the user account associated with the first-party health system is authenticated with the first-party health system as a dependent account type, causing a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing the health data of the user account associated with the first-party health system, wherein a link is established between the user account of the first-party health system and the selected user account of the third-party health system.

[0233] Clause 38: The method according to any of Clauses 34-37, further comprising, when the user account associated with the first-party health system is authenticated with the first-party health system as a host account type, causing a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing the health data of the user account associated with the first-party health system, wherein a link is established between the user account of the first-party health system and the selected user account of the third-party health system.

[0234] Clause 39: The method according to any of Clauses 34-38, wherein the request omits personally identifiable information (PII) for a user associated with the selected user account of the third-party health system.

[0235] Clause 40: The method according to any of Clauses 34-39, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0236] Clause 41: The method according to any of Clauses 34-40, further comprising transmitting, to the third-party health system, a request from a provider account associated with the third-party health system to access health data of a host account in the first-party health system, wherein responsive to the request from the provider account being transmitted, a session associated with the provider account is established for accessing the health data of the host account in the first-party health system.

[0237] Clause 42: The method according to Clause 41, wherein the request transmitted to the third-party health system from the provider account omits personally identifiable information (PIT) for a healthcare provider associated with the provider account of the third-party health system.

[0238] Clause 43: The method according to any of Clauses 41-42, further comprising: causing a third screen to display in the GUI on the display device, the GUI comprising an element associated with triggering a connection from the third-party health system to the first-party health system; and receiving an indication of a selection of the GUI element, wherein the request from the provider account is transmitted to the third-party health system in response to receiving the indication of the selection of the GUI element.

[0239] Clause 44: A system comprising: a memory; and a processor communicatively coupled to the memory, the processor configured to: receive a request from a user account associated with a third-party health system to access a first-party health system, wherein the request comprises a first token indicating that the user account is authenticated with the third-party health system; obtain, from the third-party health system, a second token associated with the user account; determine a type of the user account, based on the second token; determine whether the user account is authenticated with the first-party health system; and in response to determining that (z) the type of the user account is a caregiver account type and (zz) the user account is authenticated with the first-party health system as the caregiver account type: determine at least one dependent account associated with the user account; cause a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receive an indication of a selected dependent account from the first screen; response to the indication of the selected dependent account, cause a second screen comprising an indication of a consent agreement for sharing health data of the selected dependent account with the third-party health system to display in the GUI on the display device; and establish a communication link between the first-party health system and the third-party health system for sharing the health data of the selected dependent account.

[0240] Clause 45 : The system of Clause 44, wherein: to determine whether the user account is authenticated with the first-party health system, the processor is configured to determine that the user account is unauthenticated with the first-party health system as the caregiver account type; and the processor is further configured to, in response to determining that (z) the type of the user account is the caregiver account type and (zz) the user account is unauthenticated with the first-party health system as the caregiver account type, refrain from causing the first screen comprising the indication of the at least one dependent account to display in the GUI on the display device.

[0241] Clause 46: The system of Clause 45, wherein: in response to determining that (z) the type of the user account is the caregiver account type and (zz) the user account is unauthenticated with the first-party health system as the caregiver account type, the processor is further configured to cause a third screen prompting a user associated with the user account to authenticate with the first-party health system as the caregiver account type to display in the GUI on the display device.

[0242] Clause 47: The system according to any of Clauses 45-46, wherein to determine that the user account is unauthenticated with the first-party health system as the caregiver account type, the processor is configured to determine that the user account is authenticated with the first-party health system as a host account type.

[0243] Clause 48: The system according to any of Clauses 45-46, wherein to determine that the user account is unauthenticated with the first-party health system as the caregiver account type, the processor is configured to determine that the user account is authenticated with the first-party health system as a dependent account type.

[0244] Clause 49: The system according to any of Clauses 44-48, wherein the processor is further configured to, in response to determining that (z) the type of the user account is a dependent account type and (zz) the user account is authenticated with the first-party health system as the dependent account type: cause a third screen comprising an indication of a consent agreement for sharing health data of the user account with the third-party health system to display in the GUI on the display device; and establish a communication link between the first-party health system and the third-party health system for sharing the health data of the user account.

[0245] Clause 50: The system of Clause 49, wherein a user associated with the user account is a dependent adult.

[0246] Clause 51: The system according to any of Clauses 44-50, wherein the processor is further configured to, in response to determining that (z) the type of the user account is a host account type and (zz) the user account is authenticated with the first-party health system as the host account type: cause a third screen comprising an indication of a consent agreement for sharing health data of the user account with the third-party health system to display in the GUI on the display device; and establish a communication link between the first-party health system and the third-party health system for sharing the health data of the user account.

[0247] Clause 52: The system according to any of Clauses 44-51, wherein each of the first token and the second token omits personally identifiable information (PIT) for a user associated with the user account.

[0248] Clause 53: The system according to any of Clauses 44-52, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0249] Clause 54: The system according to any of Clauses 44-53, wherein the second token comprises an indication of the type of the user account.

[0250] Clause 55: A system comprising: a memory; and a processor communicatively coupled to the memory, the processor configured to: receive a request from a user account associated with the third-party health system to access a first-party health system, wherein the request comprises a first token indicating that the user account is authenticated with the third-party health system; obtain, from the third-party health system, a second token associated with the user account; determine a type of the user account, based on the second token; determine whether the user account is authenticated with the first-party health system; and in response to determining (z) the type of the user account is a caregiver account type and (zz) the user account is authenticated with the first-party health system as the caregiver account type: determine at least one dependent account associated with the user account; cause a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receive an indication of a selected dependent account from the first screen; and after receiving an indication of the selected dependent account, establish a communication link between the first-party health system and the third-party health system for sharing health data of the selected dependent account.

[0251] Clause 56: The system of Clause 55, wherein, in response to determining (z) the type of the user account is the caregiver account type and (zz) the user account is authenticatedwith the first-party health system as the caregiver account type, the processor is further configured to cause a second screen comprising an indication of a consent agreement for sharing the health data of the selected dependent account with the third-party health system to display in the GUI on the display device.

[0252] Clause 57 : The system of Clause 56, wherein in response to determining (z) the type of the user account is the caregiver account type and (zz) the user account is authenticated with the first-party health system as the caregiver account type, the processor is further configured to receive an indication that the consent agreement has been completed and accepted by a user associated with the user account.

[0253] Clause 58: The system of Clause 57, wherein the communication link is established between the first-party health system and the third-party health system after receiving the indication that the consent agreement has been completed and accepted by the user associated with the user account.

[0254] Clause 59: The system according to any of Clauses 55-58, wherein each of the first token and the second token comprises non-personally identifiable information (PIT) (non-PII) for a user associated with the user account.

[0255] Clause 60: The system according to any of Clauses 55-59, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0256] Clause 61 : The system according to any of Clauses 55-60, wherein the second token comprises an indication of the type of the user account.

[0257] Clause 62: A first-party health system comprising: a memory; and a processor communicatively coupled to the memory, the processor configured to: receive, at the first-party health system, a request from a user account associated with a third-party health system to receive health data from the first-party health system, wherein the request comprises a first token indicating that the user account of the third-party health system is authenticated with the third-party health system; obtain, from the third-party health system, a second token associated with the user account of the third-party health system; determine whether a user account of the first-party health system is authenticated with the first-party health system, wherein a session associated with the user account of the first-party health system receives the request from the user account associated with the third-party health system; determine a type of the user account associated with the first-party health system; and in response to determining (z) the type of theuser account associated with the first-party health system is a caregiver account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the caregiver account type: determine at least one dependent account associated with the user account of the first-party health system; cause a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device; receive an indication of a selected dependent account from the first screen; and establish a link between the selected dependent account of the first-party health system and the user account of the third-party health system for sharing health data of the selected dependent account with the third-party health system.

[0258] Clause 63: The first-party health system of Clause 62, wherein the processor is further configured to: associate the second token with the selected dependent account of the first-party health system.

[0259] Clause 64: The first-party health system according to any of Clauses 62-63, wherein: the processor is further configured to provide the first token to the third-party health system; and the second token is obtained based on the first token being provided to the third-party health system.

[0260] Clause 65: The first-party health system according to any of Clauses 62-64, wherein the processor is further configured to, responsive to the indication of the selected dependent account, cause a second screen comprising an indication of a consent agreement for sharing the health data of the selected dependent account with the third-party health system to display in the GUI on the display device.

[0261] Clause 66: The first-party health system according to any of Clauses 62-65, wherein: to determine whether the user account of the first-party health system is authenticated with the first-party health system, the processor is configured to determine that the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type; and the processor is further configured to, in response to determining that (z) the type of the user account associated with the first-party health system is the caregiver account type and (zz) the user account associated with the first-party health system is unauthenticated with the first-party health system as the caregiver account type, refrain from causing the first screen comprising the indication of the at least one dependent account to display in the GUI on the display device.

[0262] Clause 67: The first-party health system of Clause 66, wherein: the processor is further configured to, in response to determining that (z) the type of the user account of the first-party health system is the caregiver account type and (zz) the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type, cause a third screen to display in the GUI on the display device, the third screen prompting a user associated with the user account of the first-party health system to authenticate with the first-party health system as the caregiver account type; and to determine that the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type, the processor is configured to determine that the user account of the first-party health system is authenticated with the first-party health system as a dependent account type.

[0263] Clause 68: The first-party health system according to any of Clauses 62-67, wherein: the processor is further configured to, in response to determining that (z) the type of the user account associated with the first-party health system is a dependent account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the dependent account type: cause a third screen comprising an indication of a consent agreement for sharing health data of the user account associated with the first-party health system with the third-party health system to display in the GUI on the display device; and establish a link between the user account associated with the first-party health system and the user account associated with the third-party health system for sharing the health data of the user account associated with the first-party health system with the third-party health system.

[0264] Clause 69: The first-party health system according to any of Clauses 62-68, wherein the processor is further configured to, in response to determining that (z) the type of the user account of the first-party health system is a host account type and (zz) the user account of the first-party health system is authenticated with the first-party health system as the host account type: cause a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing health data of the user account of the first-party health system with the third-party health system; and establish a link between the user account of the first-party health system and the user account of the third-party health system for sharing the health data of the user account of the first-party health system with the third-party health system.

[0265] Clause 70: The first-party health system according to any of Clauses 62-69, wherein each of the first token and the second token omits personally identifiable information (PIT) for a user associated with the user account.

[0266] Clause 71 : The first-party health system according to any of Clauses 62-70, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0267] Clause 72: The first-party health system according to any of Clauses 62-71 , wherein the processor is further configured to: receive, at the first-party health system, a request from a provider account associated with the third-party health system to access health data of a host account in the first-party health system, wherein the request comprises a third token indicating a first identifier associated with a host account in the third-party health system; determine a second identifier associated with the host account in the first-party health system, based on an association between (z) the first identifier associated with the host account in the third-party health system and (zz) the second identifier associated with the host account in the first-party health system; and establish a session associated with the provider account for accessing the health data of the host account in the first-party health system based on the second identifier.

[0268] Clause 73: The first-party health system of Clause 72, wherein the processor is further configured to: verify that the provider account is authenticated with the third-party health system; and obtain, from the third-party health system, a fourth token associated with the provider account in response to the verification of the authentication of the provider account with the third-party health system.

[0269] Clause 74: The first-party health system of Clause 73, wherein each of the third token and the fourth token omits personally identifiable information (PIT) for a provider associated with the provider account and a host associated with the host account in the third-party health system.

[0270] Clause 75: The first-party health system according to any of Clauses 72-74, wherein the processor is further configured to determine the association between the first identifier and the second identifier in response to establishing a link between the host account of the first-party health system and the host account of the third-party health system.

[0271] Clause 76: A display device comprising: a memory; and a processor communicatively coupled to the memory, the processor configured to: cause a first screen to display in a graphical user interface (GUI) on the display device, the first screen comprising anindication of at least one user account in a third-party health system; receive an indication of a selected user account from the first screen; in response to the indication of the selected user account, transmit, to the third-party health system, a request from the selected user account associated with the third-party health system to receive health data from the first-party health system; and when (z) the selected user account of the third-party health system is authenticated with the third-party health system and (zz) a user account associated with the first-party health system is authenticated with the first-party health system as a caregiver account type: cause a second screen to display in the GUI on the display device, the second screen comprising an indication of at least one dependent account in the first-party health system; receive a selection of a dependent account from the second screen; and transmit an indication of the selected dependent account from the second screen, wherein a link is established between the selected dependent account of the first-party health system and the selected user account of the third-party health system.

[0272] Clause 77: The display device of Clause 76, wherein the processor is further configured to, responsive to the indication of the selected dependent account from the second screen, cause a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing the health data of the selected dependent account.

[0273] Clause 78: The display device according to any of Clauses 76-77, wherein the processor is further configured to, when the user account associated with the first-party health system is unauthenticated with the first-party health system as a caregiver account type, refrain from causing the second screen to display in the GUI on the display device.

[0274] Clause 79: The display device according to any of Clauses 76-78, wherein: the processor is further configured to, when the user account associated with the first-party health system is authenticated with the first-party health system as a dependent account type, cause a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing the health data of the user account associated with the first-party health system; and a link is established between the user account of the first-party health system and the selected user account of the third-party health system.

[0275] Clause 80: The display device according to any of Clauses 76-79, wherein: the processor is further configured to, when the user account associated with the first-party health system is authenticated with the first-party health system as a host account type: cause a thirdscreen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing the health data of the user account associated with the first-party health system; and a link is established between the user account of the first-party health system and the selected user account of the third-party health system.

[0276] Clause 81: The display device according to any of Clauses 76-80, wherein the request omits personally identifiable information (PIT) for a user associated with the selected user account of the third-party health system.

[0277] Clause 82: The display device according to any of Clauses 76-81, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

[0278] Clause 83: The display device according to any of Clauses 76-82, wherein: the processor is further configured to transmit, to the third-party health system, a request from a provider account associated with the third-party health system to access health data of a host account in the first-party health system; and responsive to the request from the provider account being transmitted, a session associated with the provider account is established for accessing the health data of the host account in the first-party health system.

[0279] Clause 84: The display device of Clause 83, wherein the request transmitted to the third-party health system from the provider account omits personally identifiable information (PIT) for a healthcare provider associated with the provider account of the third-party health system.

[0280] Clause 85: The display device according to any of Clauses 83-84, wherein: the processor is further configured to: cause a third screen to display in the GUI on the display device, the GUI comprising an element associated with triggering a connection from the third-party health system to the first-party health system; and receive an indication of a selection of the GUI element; and the request from the provider account is transmitted to the third-party health system in response to receiving the indication of the selection of the GUI element.

[0281] Clause 86: A system comprising: a memory; and a processor communicatively coupled to the memory, the processor configured to perform a computer-implemented method according to any of Clauses 1-33.

[0282] Clause 87: A non-transitory computer-readable storage medium comprising computer-executable code, which when executed by one or more processors, perform a computer- implemented method according to any of Clauses 1-33.

[0283] Clause 88: An apparatus, comprising means for performing a method in accordance with any of Clauses 1-33.

[0284] Clause 89: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any of Clauses 1-33.

[0285] Clause 90: A system comprising: a memory; and a processor communicatively coupled to the memory, the processor configured to perform a computer-implemented method according to any of Clauses 34-43.

[0286] Clause 91: A non-transitory computer-readable storage medium comprising computer-executable code, which when executed by one or more processors, perform a computer- implemented method according to any of Clauses 34-43.

[0287] Clause 92: An apparatus, comprising means for performing a method in accordance with any of Clauses 34-43.

[0288] Clause 93: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any of Clauses 34-43.Additional Considerations

[0289] The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0290] As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a- a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).

[0291] As used herein, “a processor,” “at least one processor,” or “one or more processors” generally refer to a single processor configured to perform one or multiple operations or multiple processors configured to collectively perform one or more operations. In the case of multiple processors, performance of the one or more operations could be divided amongst different processors, though one processor may perform multiple operations, and multiple processors could collectively perform a single operation. Similarly, “a memory,” “at least onememory,” or “one or more memories” generally refer to a single memory configured to store data and / or instructions or multiple memories configured to collectively store data and / or instructions.

[0292] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.”

[0293] While various examples of the invention have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the disclosure, which is done to aid in understanding the features and functionality that can be included in the disclosure. The disclosure is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, although the disclosure is described above in terms of various example examples and aspects, it should be understood that the various features and functionality described in one or more of the individual examples are not limited in their applicability to the particular example with which they are described. They instead can be applied, alone or in some combination, to one or more of the other examples of the disclosure, whether or not such examples are described, and whether or not such features are presented as being a part of a described example. Thus the breadth and scope of the present disclosure should not be limited by any of the above-described example examples.

[0294] All references cited herein are incorporated herein by reference in their entirety. To the extent publications and patents or patent applications incorporated by reference contradict the disclosure contained in the specification, the specification is intended to supersede and / or take precedence over any such contradictory material.

[0295] Unless otherwise defined, all terms (including technical and scientific terms) are to be given their ordinary and customary meaning to a person of ordinary skill in the art, and are not to be limited to a special or customized meaning unless expressly so defined herein.

[0296] Terms and phrases used in this application, and variations thereof, especially in the appended claims, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing, the term ‘including’ should be read to mean ‘including, without limitation,’ ‘including but not limited to,’ or the like; the term ‘comprising’ as used herein is synonymous with ‘including,’ ‘containing,’ or ‘characterized by,’ and is inclusive or open-ended and does not exclude additional, unrecited elements or method steps; the term ‘having’ should be interpreted as ‘having at least;’ the term ‘includes’ should be interpreted as ‘includes but is not limited to;’ the term ‘example’ is used to provide example instances of the item in discussion, not an exhaustive or limiting list thereof; adjectives such as ‘known’, ‘normal’, ‘standard’, and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass known, normal, or standard technologies that may be available or known now or at any time in the future; and use of terms like ‘preferably,’ ‘preferred,’ ‘desired,’ or ‘desirable,’ and words of similar meaning should not be understood as implying that certain features are critical, essential, or even important to the structure or function of the invention, but instead as merely intended to highlight alternative or additional features that may or may not be utilized in a particular example of the invention. Likewise, a group of items linked with the conjunction ‘and’ should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as ‘and / or’ unless expressly stated otherwise. Similarly, a group of items linked with the conjunction ‘or’ should not be read as requiring mutual exclusivity among that group, but rather should be read as ‘and / or’ unless expressly stated otherwise.

[0297] The term “comprising as used herein is synonymous with “including.” “containing,” or “characterized by” and is inclusive or open-ended and does not exclude additional, unrecited elements or method steps.

[0298] All numbers expressing quantities of ingredients, reaction conditions, and so forth used in the specification are to be understood as being modified in all instances by the term ‘about.’ Accordingly, unless indicated to the contrary, the numerical parameters set forth herein are approximations that may vary depending upon the desired properties sought to be obtained. At the very least, and not as an attempt to limit the application of the doctrine of equivalents to the scope of any claims in any application claiming priority to the present application, each numerical parameter should be construed in light of the number of significant digits and ordinary rounding approaches.

[0299] Furthermore, although the foregoing has been described in some detail by way of illustrations and examples for purposes of clarity and understanding, it is apparent to those skilled in the art that certain changes and modifications may be practiced. Therefore, the description and examples should not be construed as limiting the scope of the invention to the specific examples and examples described herein, but rather to also cover all modification and alternatives coming with the true scope and spirit of the invention.

Claims

1. CLAIMS1. A first-party health system comprising:a memory; anda processor communicatively coupled to the memory, the processor configured to: receive, at the first-party health system, a request from a user account associated with a third-party health system to receive health data from the first-party health system, wherein the request comprises a first token indicating that the user account of the third- party health system is authenticated with the third-party health system;obtain, from the third-party health system, a second token associated with the user account of the third-party health system;determine whether a user account of the first-party health system is authenticated with the first-party health system, wherein a session associated with the user account of the first-party health system receives the request from the user account associated with the third-party health system;determine a type of the user account associated with the first-party health system; andin response to determining (z) the type of the user account associated with the first-party health system is a caregiver account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the caregiver account type:determine at least one dependent account associated with the user account of the first-party health system;cause a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device;receive an indication of a selected dependent account from the first screen; andestablish a link between the selected dependent account of the first-party health system and the user account of the third-party health system for sharing health data of the selected dependent account with the third-party health system.

2. The first-party health system of claim 1, wherein the processor is further configured to associate the second token with the selected dependent account of the first-party health system.

3. The first-party health system of claim 1, wherein:the processor is further configured to provide the first token to the third-party health system; andthe second token is obtained based on the first token being provided to the third-party health system.

4. The first-party health system of claim 1, wherein the processor is further configured to, responsive to the indication of the selected dependent account, cause a second screen comprising an indication of a consent agreement for sharing the health data of the selected dependent account with the third-party health system to display in the GUI on the display device.

5. The first-party health system of claim 1, wherein:to determine whether the user account of the first-party health system is authenticated with the first-party health system, the processor is configured to determine that the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type; andthe processor is further configured to, in response to determining that (z) the type of the user account associated with the first-party health system is the caregiver account type and (zz) the user account associated with the first-party health system is unauthenticated with the first-party health system as the caregiver account type, refrain from causing the first screen comprising the indication of the at least one dependent account to display in the GUI on the display device.

6. The first-party health system of claim 5, wherein:the processor is further configured to, in response to determining that (z) the type of the user account of the first-party health system is the caregiver account type and (zz) the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type, cause a third screen to display in the GUI on the display device, the third screen prompting a user associated with the user account of the first-party health system to authenticate with the first-party health system as the caregiver account type; andto determine that the user account of the first-party health system is unauthenticated with the first-party health system as the caregiver account type, the processor is configured to determine that the user account of the first-party health system is authenticated with the first-party health system as a dependent account type.

7. The first-party health system of claim 1, wherein:the processor is further configured to, in response to determining that (z) the type of the user account associated with the first-party health system is a dependent account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the dependent account type:cause a third screen comprising an indication of a consent agreement for sharing health data of the user account associated with the first-party health system with the third-party health system to display in the GUI on the display device; and establish a link between the user account associated with the first-party health system and the user account associated with the third-party health system for sharing the health data of the user account associated with the first-party health system with the third-party health system.

8. The first-party health system of claim 1, wherein the processor is further configured to, in response to determining that (z) the type of the user account of the first-party health system is a host account type and (zz) the user account of the first-party health system is authenticated with the first-party health system as the host account type:cause a third screen to display in the GUI on the display device, the third screen comprising an indication of a consent agreement for sharing health data of the user account of the first-party health system with the third-party health system; andestablish a link between the user account of the first-party health system and the user account of the third-party health system for sharing the health data of the user account of the first-party health system with the third-party health system.

9. The first-party health system of claim 1, wherein each of the first token and the second token omits personally identifiable information (PIT) for a user associated with the user account.

10. The first-party health system of claim 1, wherein the health data comprises analyte data obtained via an analyte monitor worn by a user associated with the selected dependent account.

11. The first-party health system of claim 1, wherein the processor is further configured to:receive, at the first-party health system, a request from a provider account associated with the third-party health system to access health data of a host account in the first-party health system, wherein the request comprises a third token indicating a first identifier associated with a host account in the third-party health system;determine a second identifier associated with the host account in the first-party health system, based on an association between (z) the first identifier associated with the host account in the third-party health system and (zz) the second identifier associated with the host account in the first-party health system; andestablish a session associated with the provider account for accessing the health data of the host account in the first-party health system based on the second identifier.

12. The first-party health system of claim 11, wherein the processor is further configured to:verify that the provider account is authenticated with the third-party health system; and obtain, from the third-party health system, a fourth token associated with the provider account in response to the verification of the authentication of the provider account with the third-party health system.

13. The first-party health system of claim 12, wherein each of the third token and the fourth token omits personally identifiable information (PIT) for a provider associated with the provider account and a host associated with the host account in the third-party health system.

14. The first-party health system of claim 11, wherein the processor is further configured to determine the association between the first identifier and the second identifier in response to establishing a link between the host account of the first-party health system and the host account of the third-party health system.

15. A method for sharing data to a third-party health system, the method comprising: receiving a request, at a first-party health system, from a user account associated with the third-party health system to receive health data from the first-party health system, wherein the request comprises a first token indicating that the user account of the third-party health system is authenticated with the third-party health system;obtaining, from the third-party health system, a second token associated with the user account of the third-party health system;determining whether a user account of the first-party health system is authenticated with the first-party health system, wherein a session associated with the user account of the first-party health system receives the request from the user account associated with the third-party health system;determining a type of the user account associated with the first-party health system; and in response to determining (z) the type of the user account associated with the first-party health system is a caregiver account type and (zz) the user account associated with the first-party health system is authenticated with the first-party health system as the caregiver account type:determining at least one dependent account associated with the user account of the first-party health system;causing a first screen comprising an indication of the at least one dependent account to display in a graphical user interface (GUI) on a display device;receiving an indication of a selected dependent account from the first screen; andestablishing a link between the selected dependent account of the first-party health system and the user account of the third-party health system for sharing health data of the selected dependent account with the third-party health system.

Images