Patent Description:
Medical treatment machines can be designed to aid in the diagnosis, monitoring, and/or treatment of a variety of medical conditions. One example of a medical treatment machine is a dialysis machine. Dialysis is a treatment used to support a patient with insufficient renal function. The two principal dialysis methods are hemodialysis and peritoneal dialysis. During hemodialysis ("HD"), the patient's blood is passed through a dialyzer of the dialysis machine while also passing a dialysis solution or dialysate through the dialyzer. A semi-permeable membrane in the dialyzer separates the blood from the dialysate within the dialyzer and allows diffusion and osmosis exchanges to take place between the dialysate and the blood stream. These exchanges across the membrane result in the removal of waste products, including solutes like urea and creatinine, from the blood. These exchanges also regulate the levels of other substances, such as sodium and water, in the blood. In this way, the dialysis machine acts as an artificial kidney for cleansing the blood.

During peritoneal dialysis ("PD"), the patient's peritoneal cavity is periodically infused with dialysate. The membranous lining of the patient's peritoneum acts as a natural semi-permeable membrane that allows diffusion and osmosis exchanges to take place between the solution and the blood stream. These exchanges across the patient's peritoneum result in the removal of waste products, including solutes like urea and creatinine, from the blood, and regulate the levels of other substances, such as sodium and water, in the blood.

Automated PD machines called PD cyclers are designed to control the entire PD process so that it can be performed at home usually overnight without clinical staff in attendance. This process is termed continuous cycler-assisted PD ("CCPD"). Many PD cyclers are designed to automatically infuse, dwell, and drain dialysate to and from the patient's peritoneal cavity. The treatment typically lasts for several hours, often beginning with an initial drain cycle to empty the peritoneal cavity of used or spent dialysate. The sequence then proceeds through the succession of fill, dwell, and drain phases that follow one after the other. Each phase is called a cycle.

<CIT> describes a dialysis system that includes a dialysis machine; a communication module configured to communicate using a short-range wireless technology protocol; data storage configured to store data corresponding to identities of one or more short-range wireless devices; and a processor configured to identify presence of a short-range wireless device and cause the dialysis machine to carry out an action when one or both of i) the presence of the short-range wireless device is identified, and ii) the presence of the short-range wireless device is no longer identified.

<CIT> describes a system, method, and program that enable a client system to pass authorization, received from a file source, to a printer to retrieve and print a file directly from the file source without the client system ever receiving a copy of the file.

Implementations can include one or more of the following advantages.

In some implementations, the prescription file can be generated and delivered digitally. In some implementations, the digital prescription file can be signed digitally in a non-forgeable manner that uniquely identifies both the digital prescription file and the issuer of the digital prescription file. In some implementations, the certificate that includes the public key that corresponds to the issuer (e.g., the certificate of the issuer) may itself be embedded in the digitally signed digital prescription file. For example, in some implementations, the certificate of the issuer does not require separate and/or secure delivery. In some implementations, the digital prescription file may be delivered using any digital medium and may use either secure or insecure means (e.g., because the nature of the digital signature can expose attempts to modify the file in transit).

In some implementations, a receiver of the digital prescription file (e.g., the dialysis machine) requires no prior knowledge of the existence of the particular issuer. For example, in some implementations, any issuer, known or unknown by the receiver, may issue a valid (e.g., verifiable) digital prescription file. In some implementations, the issuer of the digital prescription file requires no prior knowledge of the particular receiver (e.g., the particular dialysis machine). For example, in some implementations, any dialysis machine may consume any prescription file without the issuer having prior knowledge of the existence of the particular dialysis machine.

In some implementations, the certificate that includes the public key that corresponds to the authority service (e.g., the certificate of the certificate authority) is pre-loaded on the dialysis machine or received by the dialysis machine. In some implementations, the certificate authority is authorized to sign certificates (e.g., issuer certificates) for issuers who are approved to provide digital prescription files. In some implementations, the dialysis machine may use the signer of the issuer's certificate (e.g., the certificate authority) as the sole authorization and indication to determine that the issuer (e.g., the signer) of the digital prescription file is an authorized issuer.

In some implementations, by using a certificate authority to verify identities of issuers, issuers need not be authorized one-by-one by the dialysis machine, and in turn, digital prescription files can be securely delivered without the original source or the recipient being known ahead of time (e.g., irrespective of the particular issuer or the particular recipient dialysis machine).

In some implementations, by encrypting the digital prescription file according to a public-key cryptography scheme, only recipients who possess the corresponding private key can decrypt the file and view its original contents. Further, by employing a digital signature, the recipient can confirm that the issuer is in fact who they claim to be and the file was not modified since it was signed by the issuer.

Other aspects, features, and advantages of the subject matter included herein will be apparent from the description and drawings, and from the claims.

Described herein is a technique for allowing digital prescription files to be transmitted to and from entities who have no a priori knowledge of one another, in some cases irrespective of the inherent security (or lack thereof) of the transmission medium, in a tamper-evident format, using minimal resources necessary to verify the validity of the digital prescription file and its issuer. The technique also enables additional security measures to be supplemented using the technique, including but not limited to encryption and real-time authentication and/or authorization, without inherently altering the technique. The term "digital prescription file" may be understood to include and refer to a set of programming instructions that may be used to carry out a medical treatment that has been medically prescribed by an appropriate doctor or other medical practitioner. In some implementations, the term "prescription" may be understood to refer to what the doctor actually prescribes to the patient and may be captured in the patient's electronic health record (EHR). This prescription may be appropriately translated, formatted, encrypted and/or otherwise converted into the digital prescription file that contains the program and/or instruction sets for the medical device (e.g., the dialysis machine) to carry out the prescribed treatment.

Cryptographic systems and methods can be employed to encrypt information and/or authenticate a source of information. For example, a file that includes sensitive information (e.g., a digital prescription file) may be encrypted and/or digitally signed before being sent to a destination. The encryption can ensure that the communication is kept integral and confidential during transit, while a digital signature can ensure the integrity of the contents without requiring decryption, and ensures that the source can be properly authenticated by the recipient.

When a file is encrypted, the information included in the original file called "plaintext" (e.g., the prescription) is transformed into a different form according to a cryptographic algorithm. For example, a file that includes the text string (e.g., "Hello World") maybe transformed into a format called "cyphertext" (e.g., "3B582EC3D210A12C38541DE975672B0272B9345") by encrypting the file with a key. A person who intercepts the encrypted file will only be able to see the cyphertext and not the original plaintext. In order to convert the cyphertext back to plaintext, a recipient typically must be in possession of a key that corresponds to the key used to encrypt the file. The key in possession of the recipient can be applied to the cyphertext to decrypt the file, thereby reproducing the plaintext. In this way, the issuer of encrypted information can ensure that only those who possess the correct key can view the sensitive information.

In addition to being encrypted, the file may also be digitally signed by the issuer. When the file is digitally signed, the plaintext is hashed (e.g., a hash algorithm is applied to the data) in order to produce a digest (e.g., sometimes referred to as a hash). The digest is then encrypted using a private key that corresponds to the issuer (e.g., a different key than the one described above with respect to the decryption), thereby producing a digital signature. The recipient can verify the signature by: i) computing the digest of the plaintext; ii) verifying (e.g., decrypting) the digital signature using a public key that corresponds to the issuer's private key in order to reproduce the digest; and iii) comparing the computed digest with the reproduced (e.g., decrypted) digest. If the computed digest and the decrypted digest are equal, it can be confirmed that: i) the file was unmodified since being signed; and ii) the signer (e.g., the issuer) performed the signature operation.

Thus, by employing a digital signature, the recipient can confirm that the issuer is in fact who they claim to be and the file was not modified since it was signed by the issuer.

A medical treatment machine such as a dialysis machine (e.g., a home dialysis machine ("HDM")) can be configured to receive a digital prescription file that defines parameters of a medical treatment (e.g., a dialysis treatment) to be administered to a patient. The digital prescription file can be prepared and delivered in such a way that the medical treatment machine can confirm that the issuer of the digital prescription file is an authorized issuer without having any a priori knowledge of the particular issuer. For example, the digital prescription file may be digitally signed by the issuer using a private key unique to the issuer. The signed digital prescription file is delivered to the medical treatment machine via a secured or unsecured medium. The medical treatment machine reads the digital prescription file, identifies the purported issuer, and confirms that the purported issuer is an authorized issuer.

In some implementations, the medical treatment machine confirms that the purported issuer is an authorized issuer by verifying that a certificate that corresponds to the issuer (and, e.g., that corresponds to the issuer's private key used to digitally sign the digital prescription file) is digitally signed by a trusted authority service (e.g., a known authorizer of issuers responsible for verifying identities of issuers and certifying ownership of public keys corresponding to such issuers), as described in more detail below.

In some implementations, an issuer may communicate with a certificate authority (e.g., a certificate authority that is trusted by the medical treatment machine to authorize issuers) ahead of time to obtain authorized status. For example, the issuer may provide their public key to the certificate authority for verification, and the certificate authority can verify the identity of the issuer and provide an issuer certificate in return. The issuer certificate, which includes the issuer's public key, is digitally signed by the certificate authority using a private key of the certificate authority. The issuer certificate can be provided to the medical treatment machine along with the digital prescription file. The certificate authority's public key, which is accessible by the medical treatment machine, can be used to verify that the issuer certificate was in fact signed by the certificate authority. Because the certificate authority is a trusted entity, the medical treatment machine can treat the information included in the issuer's certificate (e.g., the issuer's public key) as trusted. The medical treatment machine may then use the issuer's public key to confirm that the digital prescription file was, in fact, signed by the authorized issuer and was not modified since being signed. In this way, issuers need not be authorized individually by the medical treatment machine, and in turn, digital prescription files can be securely delivered without the original source or the recipient being known ahead of time (e.g., irrespective of the particular issuer or the particular recipient medical treatment machine).

In some implementations, the medical treatment machine can confirm that the purported issuer is an authorized issuer by communicating with a third-party authority service, which can provide the medical treatment machine with a public key known to correspond to the authorized issuer. The medical treatment machine may then use the public key to confirm that the digital prescription file was, in fact, signed by the authorized issuer and was not modified once signed.

In addition to being digitally signed by the issuer, the digital prescription file can be encrypted using a public key that is known to the issuer. The public key has a corresponding private key that can be pre-loaded on the medical treatment machine. In some implementations, the private key is available to the medical treatment machine for download from a trusted source. In some implementations, the private key is available for use by the medical treatment machine by sending the encrypted digital prescription file to a trusted processor for decryption and receiving the decrypted file in return. Upon receipt of the encrypted digital prescription file, the medical treatment machine can use the corresponding private key to decrypt the digital prescription file. Because the private key can be pre-loaded on all medical treatment machines (e.g., at the time of manufacture or at any time thereafter), digital prescription files can be securely delivered to any medical treatment machine and decrypted by the medical treatment machine without restriction. In some implementations, the digital prescription file is encrypted with a symmetric key, which itself is then encrypted using the public key.

In some implementations, the medical treatment machine may be a peritoneal dialysis machine. <FIG> shows an example of a PD system <NUM> that is configured to receive a digital prescription file. In some implementations, the PD system <NUM> is configured for use at a patient's home (e.g., a home PD system). The PD system <NUM> includes a PD machine (also referred to as a PD cycler) <NUM> seated on a cart <NUM>. The PD machine <NUM> includes a housing <NUM>, a door <NUM>, and a cassette interface that contacts a disposable PD cassette when the cassette is disposed within a cassette compartment formed between the cassette interface and the closed door <NUM>. A heater tray <NUM> is positioned on top of the housing <NUM>. The heater tray <NUM> is sized and shaped to accommodate a bag of dialysate (e.g., a <NUM>-liter bag of dialysate). The PD machine <NUM> also includes a user interface such as a touch screen <NUM> and control panel <NUM> that can be operated by a user (e.g., a caregiver or a patient) to allow, for example, set up, initiation, and/or termination of a PD treatment.

Dialysate bags <NUM> are suspended from fingers on the sides of the cart <NUM>, and a heater bag <NUM> is positioned in the heater tray <NUM>. The dialysate bags <NUM> and the heater bag <NUM> are connected to the cassette via dialysate bag lines <NUM> and a heater bag line <NUM>, respectively. The dialysate bag lines <NUM> can be used to pass dialysate from dialysate bags <NUM> to the cassette during use, and the heater bag line <NUM> can be used to pass dialysate back and forth between the cassette and the heater bag <NUM> during use. In addition, a patient line <NUM> and a drain line <NUM> are connected to the cassette. The patient line <NUM> can be connected to a patient's abdomen via a catheter and can be used to pass dialysate back and forth between the cassette and the patient's peritoneal cavity during use. The drain line <NUM> can be connected to a drain or drain receptacle and can be used to pass dialysate from the cassette to the drain or drain receptacle during use.

The touch screen <NUM> and the control panel <NUM> allow an operator to input various treatment parameters to the PD machine <NUM> and to otherwise control the PD machine <NUM>. In addition, the touch screen <NUM> servers as a display. The touch screen <NUM> functions to provide information to the patient and the operator of the PD system <NUM>. For example, the touch screen <NUM> may display information related to a dialysis treatment to be applied to the patient, including information related to a prescription, as described in more detail below.

The PD machine <NUM> includes a processing module <NUM> that resides inside the PD machine <NUM> and which is configured to communicate with the touch screen <NUM> and the control panel <NUM>. The processing module <NUM> is configured to receive data from the touch screen <NUM> and the control panel <NUM> and control the PD machine <NUM> based on the received data. For example, the processing module <NUM> can adjust the operating parameters of the PD machine <NUM>. In some implementations, the processing module <NUM> is an MPC823 PowerPC device manufactured by Motorola, Inc.

The PD machine <NUM> is configured to connect to a network <NUM>. The PD machine <NUM> includes a transceiver <NUM> that is configured to facilitate the connection to the network <NUM>. Other medical devices (e.g., peripheral devices or monitors, other dialysis machines, etc.) may be configured to connect to the network <NUM> and communicate with the PD machine <NUM>. Similarly, one or more remote entities, such as issuers of digital prescription files and/or authority services tasked with verifying identities of issuers and certifying ownership of public keys corresponding to the issuers, may be able to connect to the network <NUM> and communicate with the PD machine <NUM> in order to provide digital prescriptions for implementing on the PD machine <NUM>, digital certificates, and/or public keys usable to verify digital signatures. Such connections to the network <NUM> may be made through a cloud-based service (e.g., a Connected Health Service ("CHS")), as described in more detail below.

<FIG> illustrates a system for communicating information between the dialysis machine ("DM") <NUM>, a certificate authority ("CA") <NUM>, and an issuer <NUM>. The CA <NUM> may be a third party that is trusted by the DM <NUM> to authorize and authenticate the identity of the issuer <NUM>, and the issuer <NUM> may be any entity that seeks to provide prescriptions to the DM <NUM>, such as a hospital or a clinic.

Before providing a prescription to the DM <NUM>, the issuer <NUM> may communicate with the CA <NUM> to verify its identity and obtain authorized status. The CA <NUM> is tasked with confirming that the issuer <NUM> is in fact who they say they are, and also verifying that the issuer <NUM> has the authority, trust, and/or qualifications to issue prescriptions to the DM <NUM>. Once it is determined by the CA <NUM> that the issuer <NUM> is authorized to issue prescriptions, the issuer <NUM> provides an issuer public key <NUM> to the CA <NUM>. After verifying that the issuer public key <NUM> does in fact correspond to the issuer <NUM>, the CA <NUM> provides an issuer certificate <NUM> to the issuer <NUM>. The issuer certificate <NUM> includes the issuer public key <NUM> and is digitally signed by the CA <NUM> using a private key (e.g., a CA private key <NUM>) that corresponds to the CA <NUM>. The issuer <NUM>, now authorized, is able to provide prescriptions to the DM <NUM>.

The issuer <NUM> may create a prescription that is to be provided to the DM <NUM>. The prescription may be defined in plaintext that is readable by the DM <NUM>. For example, the DM <NUM> may read a set of instructions included in the plaintext and execute functions based on the instructions. The prescription may include instructions such as the flow rate to be employed during a fill phase of a cycle, a flow rate to be employed during a drain phase of a cycle, a number of rounds of treatment to be performed, a number of cycles to be performed per treatment round, a fill volume to be used for each cycle, and a dwell time to be used for each cycle, among others.

The prescription is included as part of a digital prescription file <NUM> that is provided to the DM <NUM>. To protect the privacy of the information included therein, the digital prescription file <NUM> may be encrypted using a public key (e.g., a DM public key <NUM>) that corresponds to the DM <NUM> and other DMs. In some implementations, the DM public key <NUM> is known and accessible to any issuer <NUM> who seeks to provide encrypted information to the DM <NUM>. In some implementations, the CA <NUM> can provide the DM public key <NUM> to the issuer <NUM> after verifying the identity of the issuer <NUM>. ADM private key <NUM> that corresponds to the DM public key <NUM> may be stored on the DM <NUM> or otherwise accessible by the DM <NUM>. For example, the DM private key <NUM> may be stored on the DM <NUM> at the time of manufacture of the DM <NUM> or any time thereafter. After receiving the digital prescription file <NUM>, the DM <NUM> can use the DM private key <NUM> to decrypt the digital prescription file <NUM> and obtain the plaintext of the prescription. The decrypted digital prescription file can also be used by the DM <NUM> to identify the particular issuer <NUM> of the digital prescription file <NUM>.

The DM public key <NUM> and the DM private key <NUM> correspond to not only the particular DM <NUM>, but also any related DM that is included as part of the system. That is, the DM private key <NUM> can be stored on all related DMs and can be used to decrypt information that is encrypted using the DM public key <NUM>. In this way, digital prescription files <NUM> can be securely delivered by the issuer <NUM> without the particular recipient DM being known ahead of time, and can be decrypted by the DM <NUM> before the DM <NUM> learns the identity of the issuer <NUM> (or, in some cases, without the DM <NUM> ever learning the particular identity of the issuer <NUM>, as described in more detail below).

Because the DM public key <NUM> may be widely known (e.g., including to issuers who are not authorized to provide prescriptions to the DM <NUM>), received encrypted digital prescription files <NUM> are not necessarily safe to implement without further verification. For example, someone who is not authorized to provide prescriptions may obtain the DM public key <NUM>, create a prescription that includes dangerous instructions, encrypt the prescription using the DM public key <NUM>, and provide the encrypted prescription to a DM. To prevent such a situation, the DM <NUM> is configured to verify the identity of the issuer <NUM> before trusting the digital prescription file <NUM>.

In addition to being encrypted, the digital prescription file <NUM> is digitally signed with a private key (e.g., an issuer private key <NUM>) that corresponds to the issuer <NUM>. The digital signature can be verified using the issuer public key <NUM>, which corresponds to the issuer private key <NUM>. If the digital signature is verified, it is confirmed that i) the digital prescription file <NUM> was unmodified since being signed, and ii) the signer (e.g., the issuer <NUM>) performed the signature operation. Further information about how the digital signature is verified using the issuer public key <NUM> is described below with respect to <FIG>.

In some implementations (e.g., implementations in which the digital prescription file <NUM> is encrypted), the DM <NUM> identifies the issuer <NUM> of the digital prescription file <NUM> using the decrypted digital prescription file. The decrypted digital prescription file may include identification information related to the particular issuer <NUM>. The DM <NUM> then communicates with (e.g., queries) the CA <NUM> to obtain the issuer public key <NUM> that corresponds to the issuer <NUM>. For example, after decrypting the digital prescription file <NUM> and identifying the purported issuer <NUM>, the DM <NUM> may ask the CA <NUM> whether the purported issuer <NUM> is an authorized issuer (e.g., an issuer who is authorized to provide prescriptions). If the purported issuer <NUM> is authorized to provide prescriptions, the CA <NUM> can provide the issuer public key <NUM> that corresponds to the issuer <NUM> who is known to be authorized. The DM <NUM> can use the issuer public key <NUM> to confirm that the digital prescription file <NUM> was in fact signed by the authorized issuer <NUM> and was not modified since being signed, as described in more detail below.

In some implementations, the DM <NUM> may obtain the issuer public key <NUM>, confirm that the purported issuer <NUM> is authorized to provide prescriptions, and verify the digital signature without communicating (e.g., concurrently communicating) with the CA <NUM>. This type of verification may be performed if the DM <NUM> is unable to communicate with the CA <NUM> (e.g., due to lack of Internet access).

As described above, before providing prescriptions to the DM <NUM>, the issuer <NUM> may obtain authorized status by communicating with the CA <NUM>. Once the issuer <NUM> is authorized, the CA <NUM> provides an issuer certificate <NUM> to the issuer <NUM>. The issuer certificate <NUM> includes the issuer public key <NUM> and is digitally signed by the CA <NUM> using the CA private key <NUM>. The issuer certificate <NUM> can be provided to the DM <NUM> along with the digital prescription file <NUM>.

A CA certificate <NUM> is stored on the DM <NUM>. The CA certificate <NUM> may be provided to the DM <NUM> before prescriptions are received (e.g., at the time of manufacture of the DM <NUM> or any time thereafter). In some implementations, the CA certificate <NUM> is stored on the DM <NUM> or stored in a location that is accessible by the DM <NUM> (e.g., via the network <NUM>). In some implementations, the CA certificate <NUM> is received by the DM <NUM> in a manner that indicates that the CA is a trusted authorizer of prescriptions issues. For example, the CA certificate <NUM> may be delivered via a secure channel that is only accessible by those who are trusted authorizers of prescription issuers. In some implementations, the CA certificate <NUM> is stored in a data repository that includes information related to one or more trusted certificate authorities. The CA certificate <NUM> includes a public key (e.g., a CA public key <NUM>) that corresponds to the CA <NUM>. The digital signature on the issuer certificate <NUM> can be verified using the CA public key <NUM>. If the digital signature is verified, it is confirmed that i) the issuer certificate <NUM> was unmodified since being signed by the CA <NUM>, and ii) the signer (e.g., the CA <NUM>) performed the signature operation. Because the CA <NUM> is a trusted entity, the DM <NUM> can treat the information included in the issuer certificate <NUM> (e.g., the issuer public key <NUM>) as trusted. The DM <NUM> may then use the issuer public key <NUM> included in the issuer certificate <NUM> to verify the signature on the digital prescription file, thereby confirming that the digital prescription file <NUM> was in fact signed by the issuer <NUM> (e.g., who is now known to be trusted and authorized) and was not modified since being signed. The DM <NUM> may then implement the treatment defined by the prescription.

The digital prescription file <NUM> can include a prescription, which in some implementations can be in plaintext format. The prescription is usable by the dialysis system <NUM> to perform a dialysis treatment. The digital prescription file <NUM> can include patient attributes such as a Patient ID, a serial number of a cycler to be used, information related to a date and time at which the cycler was assigned to the patient, an ID associated with the patient's provider (e.g., issuer), an ID associated with the patient's clinic, the patient's first and last name, a minimum peritoneal volume of the patient, and a maximum peritoneal volume of the patient. In some implementations, the digital prescription file <NUM> can contain multiple prescriptions (e.g., six) for the patient. The digital prescription file <NUM> can include a date/time stamp identifying a time at which each prescription was created and/or assigned to the patient.

The digital prescription file <NUM> also includes attributes related to each prescription. For example, the prescription may have attributes related to a prescription sequence ID, a prescription ID, a name (e.g., to be displayed on the DM <NUM>), a type for a disposable line set to be used when providing the treatment (e.g., "low feature," "medium feature," "high feature"), a quality of a catheter to be used when providing the treatment (e.g., "slow," "average," "fast"), a flow rate to be used during the fill phase of a cycle, a flow rate to be used during the drain phase of a cycle, and a requested time at which the treatment is to end.

Within a prescription, a patient can have one or more rounds of treatment. Each round can have one cycle or multiple repeating cycles. Repeating cycles within a particular round may have the same settings. In some implementations, the digital prescription file <NUM> includes attributes related to the particular prescription round and/or cycle, such as a prescription round ID (e.g., giving the position of the round in the treatment sequence), a number of cycles included in a particular round, a cycle type code (e.g., "cycler," "manual," "PD+," "last fill"), a requested fill volume for each cycle in the round, a requested dwell time for each cycle in the round, an expected ultrafiltration volume for each cycle in the round, a drain mode (e.g., "standard," "complete"), and a requested drain volume for each cycle in the round. In some implementations, the digital prescription file <NUM> also includes attributes related to a type of bag prescribed for a particular treatment.

<FIG> shows an example of a technique that may be employed to encrypt <NUM> and digitally sign <NUM> a digital prescription file (e.g., the digital prescription file <NUM> of <FIG>) for implementations in which the digital prescription file is encrypted.

As described above, the digital prescription file <NUM> includes a prescription in plaintext that defines one or more parameters of a dialysis treatment to be applied to the patient by the DM <NUM>. The digital prescription file <NUM> may be prepared by an issuer (e.g., the issuer <NUM> of <FIG>). The digital prescription file <NUM> may be encrypted using a cryptography system such as an asymmetric cryptography system, sometimes referred to as public-key cryptography. For example, the information included in the digital prescription file <NUM> may be encrypted <NUM> using a DM public key <NUM> that corresponds to the DM <NUM> (and, e.g., other related DMs). The information in the digital prescription file <NUM> is transformed into a different form according to a cryptographic algorithm that considers the DM public key <NUM>, thereby resulting in an encrypted digital prescription file <NUM>. The cryptographic algorithm may be based on a mathematical problem that admits no efficient solution. As a result of the encryption <NUM>, the encrypted digital prescription file <NUM> may take the form of an alphanumeric code that is unintelligible on its face to anyone who may intercept the encrypted digital prescription file <NUM>. Thus, the encryption <NUM> helps to ensure that the information contained in the digital prescription file <NUM> is kept confidential during transit.

The digital prescription file <NUM> is also digitally signed <NUM> by the issuer <NUM>. When we say that data is "digitally signed," we mean that a digital signature has been appended to the data. A digital signature typically contains an encrypted digest of the data. As shown in <FIG>, the contents of the digital prescription file <NUM> are hashed according to a hash algorithm <NUM> in order to produce a digest <NUM>. In some implementations, the hash algorithm <NUM> is a mathematical algorithm that is designed to be a one-way function (e.g., a function that is infeasible to invert). The digest <NUM> is then encrypted <NUM> using an issuer private key <NUM> that corresponds to the issuer <NUM>, thereby creating a digital signature <NUM>. The digital signature <NUM> and the encrypted digital prescription file <NUM> are then provided to the DM <NUM>.

<FIG> shows an example of a technique that may be employed by the DM <NUM> to verify the digital signature <NUM> of the encrypted digital prescription file <NUM>. In this example, the technique includes decrypting <NUM> the encrypted digital prescription file <NUM> and checking <NUM> the digital signature <NUM>. In implementations in which the digital prescription file is not encrypted and therefore does not need to be decrypted, the decrypting <NUM> step can be omitted.

After receiving the encrypted digital prescription file <NUM> from the issuer <NUM>, the DM <NUM> decrypts <NUM> the file using a DM private key <NUM> that corresponds to the DM public key <NUM>. For example, the private key <NUM> can provide the information necessary for the cryptographic algorithm to convert the unintelligible alphanumeric code back into plaintext, thereby reproducing the original digital prescription file <NUM>.

Because the digital prescription file <NUM> was encrypted using a public key (e.g., the DM public key <NUM>), it is possible that someone who is not authorized to provide prescriptions may nonetheless obtain the DM public key <NUM> and provide an encrypted prescription to the DM <NUM>. Thus, to ensure that the digital prescription file <NUM> comes from a trustworthy source and is safe to implement, the source of the digital prescription file (e.g., the issuer <NUM>) can be verified by checking <NUM> the digital signature <NUM>.

After the encrypted digital prescription file <NUM> is decrypted <NUM> to reproduce the plaintext contained therein, the plaintext is hashed according to the hash algorithm <NUM> to produce a computed digest <NUM>. The digital signature <NUM>, which includes an encrypted version of the digest <NUM>, is decrypted <NUM> using an issuer public key <NUM> that corresponds to the issuer private key <NUM> in order to reproduce the digest <NUM>. The computed digest <NUM> is then compared to the reproduced (e.g., decrypted) digest <NUM>. If the computed digest <NUM> and the reproduced digest <NUM> are equal, it can be confirmed that the digital prescription file <NUM> was not modified since being digitally signed by the issuer <NUM>, and the issuer <NUM> was the one who performed the signature operation. The steps of reproducing the digest, computing a digest using the hash algorithm <NUM>, and comparing the reproduced digest <NUM> to the computed digest <NUM> are sometimes collectively referred to herein as verifying the digital signature <NUM>.

As described above, there are multiple ways in which the DM <NUM> can obtain the issuer public key <NUM> in order to verify the digital signature <NUM>. In some implementations, the DM <NUM> communicates with the CA (<NUM> of <FIG>) to obtain the issuer public key <NUM>. For example, after decrypting the encrypted digital prescription file <NUM> and identifying the purported issuer <NUM>, the DM <NUM> may ask the CA <NUM> whether the purported issuer <NUM> is authorized to provide prescriptions. If the purported issuer <NUM> is authorized to provide prescriptions, the CA <NUM> can provide the issuer public key <NUM> that corresponds to the issuer <NUM> who is known to be authorized. The DM <NUM> can use the issuer public key <NUM> to confirm that the digital prescription file <NUM> was in fact signed by the authorized issuer <NUM> and was not modified since being signed.

In some implementations, the DM <NUM> may obtain the issuer public key <NUM> directly from the issuer <NUM>. For example, along with the encrypted digital prescription file <NUM>, the issuer <NUM> may provide an issuer certificate (<NUM> of <FIG>) to the DM <NUM> that includes the issuer public key <NUM> and which is signed by the CA <NUM> using the CA private key <NUM>. A CA certificate (<NUM> of <FIG>) that is stored on the DM <NUM> includes the CA public key <NUM> that corresponds to the CA private key <NUM>. The digital signature on the issuer certificate <NUM> can be verified by the DM <NUM> using the CA public key <NUM>. If the digital signature is verified, it is confirmed that the issuer certificate <NUM> was unmodified since being signed by the CA <NUM>, and the CA <NUM> was the one who performed the signature operation. Because the CA <NUM> is a trusted entity, the DM <NUM> can treat the information included in the issuer certificate <NUM> (e.g., the issuer public key <NUM>) as trusted. The DM <NUM> may then use the issuer public key <NUM> included in the issuer certificate <NUM> to verify the digital signature accompanying the encrypted digital prescription file <NUM>. In this way, in some implementations, the DM <NUM> can confirm that the issuer <NUM> is authorized to provide prescriptions without the DM <NUM> ever knowing the actual identity of the issuer <NUM>.

In some implementations, the digital prescription file <NUM> and the issuer certificate <NUM> may be provided to the DM <NUM> using a portable storage medium. For example, the digital prescription file <NUM> and the issuer certificate <NUM> may be uploaded to the DM <NUM> from a portable memory device such as a USB flash drive. In some examples, the digital prescription file <NUM> is digitally signed and encrypted before it is uploaded to the USB flash drive. The USB flash drive can be inserted into a USB port of the DM <NUM> and the digital prescription file <NUM> can be uploaded. The DM <NUM> can then decrypt the digital prescription file <NUM> and verify the digital signature. In this way, a communications network need not be used to deliver the digital prescription file <NUM>.

Accordingly, providing the digital prescription file <NUM> via a USB flash drive may be beneficial for situations in which the DM <NUM> does not have access to the network (<NUM> of <FIG>) and/or the Internet. As described above, using only the DM private key <NUM> and the information contained in the digital prescription file <NUM>, the issuer certificate <NUM>, and the CA certificate <NUM>, the DM <NUM> may confirm that the issuer <NUM> is an authorized issuer (e.g., authorized to provide prescriptions) and also decrypt the digital prescription file <NUM> to obtain the prescription for implementing on the DM <NUM>. Verification of the authorized status of the issuer <NUM> can be performed without concurrent communication with the CA <NUM>.

While certain implementations have been described, other implementations are possible.

While the DM private key and the CA certificate have been described as being stored on the dialysis machine, in some implementations, the DM private key and the CA certificate may be stored in another location that is accessible by the DM. For example, the DM private key and the CA certificate may be stored on a server that is accessible by the DM via the network.

In some implementations, CA certificate may be updated periodically. For example, the CA certificate and/or the CA public key contained therein may be updated according to a planned rotation over time. The dialysis machine may replace a current version of the CA certificate and/or the CA public key with an updated version that can subsequently be used to check the CA signature on issuer certificates.

While the dialysis machine has been described as communicating with remote entities through the network, in some implementations, the dialysis machine is configured to communicate directly with remote entities. For example, the transceiver may be configured to facilitate a direct connection between the dialysis machine and a remote entity, such as an issuer of a digital prescription file and/or a certificate authority.

While the systems and techniques described herein have been largely described with reference to a dialysis machine, and in particular, a PD machine, other types of medical treatment systems and/or machines may also use the systems and techniques to transmit digital prescription files and verify the validity of the digital prescription files and their issuers. Examples of other medical treatment systems that may employ the techniques described herein include hemofiltration systems, hemodiafiltration systems, apheresis systems, cardiopulmonary bypass systems, and hemodialysis ("HD") systems. In some implementations, the medical treatment system is a dialysis machine configured for use at a patient's home (e.g., a home dialysis machine ("HDM")). The HDM can take the form of a home PD machine or a home hemodialysis ("HD") machine.

<FIG> shows an HD system <NUM> that is configured to receive a digital prescription file in a manner similar to that described above. In some implementations, the HD system <NUM> is configured for use at a patient's home (e.g., a home HD system). The HD system <NUM> includes an HD machine <NUM> to which a disposable blood component set <NUM> that forms a blood circuit is connected. During hemodialysis, arterial and venous patient lines <NUM>, <NUM> of the blood component set <NUM> are connected to a patient and blood is circulated through various blood lines and components, including a dialyzer <NUM>, of the blood component set <NUM>. At the same time, dialysate is circulated through a dialysate circuit formed by the dialyzer <NUM> and various other dialysate components and dialysate lines connected to the HD machine <NUM>. Many of these dialysate components and dialysate lines are located inside the housing <NUM> of the HD machine <NUM>, and are thus not visible in <FIG>. The dialysate passes through the dialyzer <NUM> along with the blood. The blood and dialysate passing through the dialyzer <NUM> are separated from one another by a semi-permeable structure (e.g., a semi-permeable membrane and/or semi-permeable microtubes) of the dialyzer <NUM>. As a result of this arrangement, toxins are removed from the patient's blood and collected in the dialysate. The filtered blood exiting the dialyzer <NUM> is returned to the patient. The dialysate that exits the dialyzer <NUM> includes toxins removed from the blood and is commonly referred to as "spent dialysate. " The spent dialysate is routed from the dialyzer <NUM> to a drain.

One of the components of the blood component set <NUM> is an air release device <NUM>. The air release device <NUM> includes a self-sealing vent assembly that allows air to pass through while inhibiting (e.g., preventing) liquid from passing through. As a result, if blood passing through the blood circuit during treatment contains air, the air will be vented to atmosphere as the blood passes through the air release device <NUM>.

As shown in <FIG>, a dialysate container <NUM> is connected to the HD machine <NUM> via a dialysate supply line <NUM>. A drain line <NUM> and an ultrafiltration line <NUM> also extend from the HD machine <NUM>. The dialysate supply line <NUM>, the drain line <NUM>, and the ultrafiltration line <NUM> are fluidly connected to the various dialysate components and dialysate lines inside the housing <NUM> of the HD machine <NUM> that form part of the dialysate circuit. During hemodialysis, the dialysate supply line <NUM> carries fresh dialysate from the dialysate container <NUM> to the portion of the dialysate circuit located inside the HD machine <NUM>. As noted above, the fresh dialysate is circulated through various dialysate lines and dialysate components, including the dialyzer <NUM>, that form the dialysate circuit. As the dialysate passes through the dialyzer <NUM>, it collects toxins from the patient's blood. The resulting spent dialysate is carried from the dialysate circuit to a drain via the drain line <NUM>. When ultrafiltration is performed during treatment, a combination of the spent dialysate and excess fluid drawn from the patient is carried to the drain via the ultrafiltration line <NUM>.

The blood component set <NUM> is secured to a module <NUM> attached to the front of the HD machine <NUM>. The module <NUM> includes a blood pump <NUM> capable of driving blood through the blood circuit. The module <NUM> also includes various other instruments capable of monitoring the blood flowing through the blood circuit. The module <NUM> includes a door that when closed, as shown in <FIG>, cooperates with the front face of the module <NUM> to form a compartment sized and shaped to receive the blood component set <NUM>. In the closed position, the door presses certain blood components of the blood component set <NUM> against corresponding instruments exposed on the front face of the module <NUM>. Such an arrangement facilitates control of the flow of blood through the blood circuit and monitoring of the blood flowing through the blood circuit.

The blood pump <NUM> can be controlled by a blood pump module <NUM>. The blood pump module <NUM> includes a display window, a start/stop key, an up key, a down key, a level adjust key, and an arterial pressure port. The display window displays the blood flow rate setting during blood pump operation. The start/stop key starts and stops the blood pump <NUM>. The up and down keys increase and decrease the speed of the blood pump <NUM>. The level adjust key raises a level of fluid in an arterial drip chamber.

A drug pump <NUM> also extends from the front of the HD machine <NUM>. The drug pump <NUM> is a syringe pump that includes a clamping mechanism configured to retain a syringe <NUM> of the blood component set <NUM>. The drug pump <NUM> also includes a stepper motor configured to move the plunger of the syringe <NUM> along the axis of the syringe <NUM>. A shaft of the stepper motor is secured to the plunger in a manner such that when the stepper motor is operated in a first direction, the shaft forces the plunger into the syringe <NUM>, and when operated in a second direction, the shaft pulls the plunger out of the syringe <NUM>. The drug pump <NUM> can thus be used to inject a liquid drug (e.g., heparin) from the syringe <NUM> into the blood circuit via a drug delivery line <NUM> during use, or to draw liquid from the blood circuit into the syringe <NUM> via the drug delivery line <NUM> during use.

The HD machine <NUM> includes a touch screen <NUM> and a control panel <NUM>. The touch screen <NUM> and the control panel <NUM> allow an operator to input various treatment parameters to the HD machine <NUM> and to otherwise control the HD machine <NUM>. In addition, the touch screen <NUM> serves as a display. The touch screen <NUM> functions to provide information to the patient and the operator of the HD system <NUM>. For example, the touch screen <NUM> may display information related to a dialysis treatment to be applied to the patient, including information related to a prescription, as described above.

The HD machine <NUM> includes a processing module <NUM> that resides inside the machine and which is configured to communicate with the touch screen <NUM> and the control panel <NUM>. The processing module <NUM> is configured to receive data from the touch screen <NUM> and the control panel <NUM> and control the HD machine <NUM> based on the received data. For example, the processing module <NUM> can adjust the operating parameters of the HD machine <NUM>.

The HD machine <NUM> is configured to connect to a network <NUM>. The HD machine <NUM> includes a transceiver <NUM> that is configured to facilitate the connection to the network <NUM>. Other medical devices (e.g., peripheral devices or monitors, other dialysis machines, etc.) may be configured to connect to the network <NUM> and communicate with the HD machine <NUM>. Similarly, one or more remote entities, such as issuers of digital prescription files and/or authority services tasked with verifying identities of issuers and certifying ownership of public keys corresponding to the issuers, may be able to connect to the network <NUM> and communicate with the HD machine <NUM> in order to provide digital prescriptions for implementing on the HD machine <NUM>, digital certificates, and/or public keys usable to check digital signatures, as described above.

In some implementations, a dialysis machine (DM) <NUM> (e.g., like the PD machine <NUM> of <FIG> and/or the HD machine <NUM> of <FIG>) is configured to communicate with the certificate authority (e.g., the CA <NUM> of <FIG>) and/or the issuer (e.g., the issuer <NUM> of <FIG>) through a connected system (e.g., via the network <NUM> of <FIG> and/or the network <NUM> of <FIG>). <FIG> is a schematic illustration showing an example of a Connected Health Service ("CHS") <NUM> system that can include, among other things, a CH Cloud <NUM> and a CH Gateway <NUM>, which collectively may also be referred to as Reciprocity. The CH Cloud <NUM> may be a cloud-based application that serves as a communication pipeline (e.g., facilitates the transfer of data) among components of the CHS system <NUM>. The CH Gateway <NUM> may serve as a communication device (e.g., a standard communication device) among dialysis machines that are part of the CHS system <NUM>. The CH Gateway <NUM> is in communication with the DM <NUM> and the CH Cloud <NUM> and is configured to receive data from the CH Cloud <NUM> and provide the data to the DM <NUM>. In some examples, the digital prescription file <NUM> is encrypted and then uploaded to the CH Cloud <NUM>. In some implementations, the digital prescription file <NUM> may be checked for compatibility and/or otherwise processed by a processing system <NUM> that may be part of the system of the issuer <NUM> and/or provided by an Internet or cloud-based system before being uploaded to the CH Cloud <NUM>. The DM <NUM> may poll the CH Cloud <NUM> for available files (e.g., via the CH Gateway <NUM>), and the DM <NUM> may temporarily store available files for processing. In situations in which multiple digital prescription files are available on the CH Cloud <NUM>, the DM <NUM> may identify and implement newer digital prescription files (e.g., based on a date associated with the digital prescription file). Such date identification can allow the DM <NUM> to implement up-to-date prescriptions (e.g., the most up-to-date prescriptions) associated with the particular patient. The patient may then follow a patient confirmation process to accept the digital prescription file <NUM> before the prescription data is programmed into the DM <NUM> for implementation.

In some implementations, the CH Cloud <NUM> may include a component that acts as a proxy for performing digital signature operations. For example, the issuer <NUM> may communicate with the CH Cloud <NUM> to authenticate itself. Upon verification of the identity of the issuer <NUM>, the CH Cloud <NUM> may confirm that it has access to the issuer private key and perform the digital signature operation on behalf of the issuer <NUM>.

The communication between the DM <NUM> and the CA <NUM> and/or the issuer <NUM> may be secured according to one or more cryptographic protocols. For example, Transport Layer Security ("TLS") may be employed to provide communications security over the network <NUM>, <NUM>. TLS can provide privacy and data integrity between the DM <NUM> and the CA <NUM> and/or the issuer <NUM>. In some implementations, TLS employs encryption according to one or more standards, such as the Advanced Encryption Standard ("AES"). In some implementations, other data besides the digital prescription file <NUM> may be exchanged among the components of the CHS system <NUM>, including treatment data and/or device maintenance data transmitted between the DM <NUM> and the issuer <NUM>.

In some implementations, Reciprocity is an application and services platform that enables medical device service providers (e.g., dialysis service providers) and patients (e.g., dialysis patients) to easily exchange data electronically through the lifecycle of care. The Reciprocity ecosystem may be segregated into three major areas. The first area may be the home space where a patient can receive their dialysis treatment (e.g., at the dialysis machine <NUM>). With a combination of device agents and a gateway connection (e.g., the CH Gateway <NUM>), the patient can download new prescription and configuration files, wirelessly integrate biometric vital measurements into their treatment, and/or upload critical treatment data to the cloud (e.g., CH Cloud <NUM>). The second area is a series of backend business and data processing services (e.g., the processing system <NUM>) built onto the latest Internet of Things (IoT) platform technologies. The cloud (e.g., the CH Cloud <NUM>) may be the communication hub and delivery system for Reciprocity. The cloud facilitates the capturing, storing, and/or publishing out of both treatment and device data files. The third area is the integration application and services used with service providers (e.g., the issuer <NUM> the CA <NUM>). The integration application and services allow service providers to create and manage prescriptions and/or configurations without incorporating the required logic to properly check for compatibility or format for a targeted device.

For example, referring to <FIG> and <FIG>, the processing modules <NUM>, <NUM> could be examples of the system <NUM> described here. The system <NUM> includes a processor <NUM>, a memory <NUM>, a storage device <NUM>, and an input/output device <NUM>. Each of the components <NUM>, <NUM>, <NUM>, and <NUM> can be interconnected, for example, using a system bus <NUM>. The processor <NUM> is capable of processing instructions for execution within the system <NUM>. The processor <NUM> can be a single-threaded processor, a multi-threaded processor, or a quantum computer. The processor <NUM> is capable of processing instructions stored in the memory <NUM> or on the storage device <NUM>. The processor <NUM> may execute operations such as causing the dialysis system to carry out functions related to a dialysis treatment according to a prescription received in a digital prescription file.

In some implementations, the memory <NUM> is a computer-readable medium. The memory <NUM> can, for example, be a volatile memory unit or a non-volatile memory unit. In some implementations, the memory <NUM> stores information related to patients' identities. In some implementations, the memory <NUM> stores information related to issuers and/or certificate authorities, such as certificates and/or public keys that correspond to particular issuers and/or certificate authorities. In some implementations, the memory <NUM> stores a private key that corresponds to the dialysis machine (e.g., the DM private key).

In some implementations, the storage device <NUM> is a non-transitory computer-readable medium. The storage device <NUM> can include, for example, a hard disk device, an optical disk device, a solid-date drive, a flash drive, magnetic tape, or some other large capacity storage device. The storage device <NUM> may alternatively be a cloud storage device, e.g., a logical storage device including multiple physical storage devices distributed on a network and accessed using a network. In some implementations, the information stored on the memory <NUM> can also or instead be stored on the storage device <NUM>.

In some implementations, the input/output device <NUM> includes one or more of network interface devices (e.g., an Ethernet card), a serial communication device (e.g., an RS-<NUM><NUM> port), and/or a wireless interface device (e.g., a short-range wireless communication device, an <NUM> card, a <NUM> wireless modem, or a <NUM> wireless modem). In some implementations, the input/output device <NUM> includes driver devices configured to receive input data and send output data to other input/output devices, e.g., a keyboard, a printer, and display devices (such as the touch screen <NUM>, <NUM>). In some implementations, mobile computing devices, mobile communication devices, and other devices are used.

In some implementations, the system <NUM> is a microcontroller. A microcontroller is a device that contains multiple elements of a computer system in a single electronics package. For example, the single electronics package could contain the processor <NUM>, the memory <NUM>, the storage device <NUM>, and input/output devices <NUM>.

Although an example processing system has been described in <FIG>, implementations of the subject matter and the functional operations described above can be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier, for example a computer-readable medium, for execution by, or to control the operation of, a processing system. The computer readable medium can be a machine readable storage device, a machine readable storage substrate, a memory device, a composition of matter effecting a machine readable propagated signal, or a combination of one or more of them.

The term "computer system" may encompass all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. A processing system can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

A computer program (also known as a program, software, software application, script, executable logic, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile or volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks or magnetic tapes; magneto optical disks; and CD-ROM and DVD-ROM disks.

Claim 1:
A method comprising:
receiving, by a medical treatment machine (<NUM>, <NUM>, <NUM>, <NUM>), a digital prescription file (<NUM>, <NUM>) that is encrypted using a public key (<NUM>, <NUM>, <NUM>) of the medical treatment machine, wherein the digital prescription file (<NUM>, <NUM>) is digitally signed by an issuer (<NUM>) of the digital prescription file using an issuer private key (<NUM>, <NUM>) of the issuer (<NUM>);
receiving, by the medical treatment machine, a certificate (<NUM>) of the issuer (<NUM>), wherein the certificate includes a public key (<NUM>) of the issuer and is digitally signed by a trusted authority service (<NUM>) using a private key (<NUM>) of the trusted authority service (<NUM>);
decrypting the digital prescription file using a private key (<NUM>, <NUM>) of the medical treatment machine that corresponds to the public key of the medical treatment machine, wherein the private key (<NUM>, <NUM>) of the medical treatment machine is accessible by the medical treatment machine;
identifying the issuer (<NUM>) of the digital prescription file (<NUM>) using the decrypted digital prescription file (<NUM>, <NUM>);
determining that the issuer of the digital prescription file is an authorized issuer by verifying, using a public key (<NUM>) of the trusted authority service (<NUM>), that the certificate (<NUM>) of the issuer (<NUM>) was digitally signed using the private key (<NUM>) of the trusted authority service (<NUM>); and
verifying a digital signature (<NUM>) on the digital prescription file using the issuer public key (<NUM>) of the authorized issuer to confirm that the issuer (<NUM>) is authorized to issue prescriptions.