Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
Applicant’s election without traverse of claims 8-30 in the reply filed on April 20, 2026 is acknowledged.
Status of Claims
This office action for the 18/989851 application is in response to the communications filed May 18, 2026.
Claims 1-30 were initially submitted December 20, 2024.
Claims 1-30 were subject to restriction requirement December 18, 2025.
Claims 1-7 were withdrawn from consideration April 20, 2026.
Claims 8-30 were elected without traverse April 20, 2026.
Claims 8-30 were cancelled April 20, 2026.
Claims 31-53 were added as new April 20, 2026.
Claims 1-7 and 31-53 were cancelled May 18, 2026.
Claims 54-81 were added as new May 18, 2026.
Claims 54-81 are currently pending and considered below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 54-81 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
As per claim 54,
Step 1: The claim recites subject matter within a statutory category as a process.
Step 2A is a two-prong inquiry, in which Prong 1 determines whether a claim recites a judicial exception. Prong 2 determines if the additional limitations of the claim integrates the recited judicial exception into a practical application. If the additional elements of the claim fail to integrate the judicial exception into a practical application, claim is directed to the recited judicial exception, see MPEP 2106.04(II)(A).
Step 2A Prong 1: The claim contains subject matter that recites an abstract idea, with the steps of a method comprising: maintaining, prescriptions for medication currently prescribed to a patient by a plurality of providers from different provider networks; and providing, to each provider within the plurality of providers from different provider networks, with access to add new prescriptions, and modify existing prescriptions. These steps, as drafted, under the broadest reasonable interpretation recite:
certain methods of organizing human activity (e.g., fundamental economic principles or practices including: hedging; insurance; mitigating risk; etc., commercial or legal interactions including: agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations; etc., managing personal behavior or relationships or interactions between people including: social activities; teaching; following rules or instructions; etc.) but for recitation of generic computer components. That is, other than reciting steps as performed by the generic computer components, nothing in the claim element precludes the step from being directed to certain methods of organizing human activity. The identified abstract idea, law of nature, or natural phenomenon identified above, in the context of this claim, encompasses a certain method of organizing human activity, namely managing personal behavior or relationships or interactions between people. This is because each of the limitations of the abstract idea recites a list of rules or instructions that a human person can follow in the course of their personal behavior. If a claim limitation, under its broadest reasonable interpretation, covers at least the recited methods of organizing human activity above, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. See MPEP 2106.04(a).
Step 2A Prong 2: The claim does not recite additional elements that integrate the judicial exception into a practical application. In particular, the additional elements do not integrate the abstract idea into a practical application, other than the abstract idea per se, because the additional elements amount to no more than limitations which:
amount to mere instructions to apply an exception, see MPEP 2106.05(f), such as:
“computer-implemented” which corresponds to merely using a computer as a tool to perform an abstract idea. Paragraph [0071] of the as-filed specification describes that the hardware that implements the steps of the abstract idea amount to nothing more than a generic computer. Implementing an abstract idea on a generic computer, does not integrate the abstract idea into a practical application in Step 2A Prong Two or add significantly more in Step 2B, similar to how the recitation of the computer in the claim in Alice amounted to mere instructions to apply the abstract idea of intermediated settlement on a generic computer.
add insignificant extra-solution activity to the abstract idea, see MPEP 2106.05(g), such as:
“within a repository of medication information, a data store of”, “a provider portal that provides each provider”, “view the data store”, “to the data store” and “within the data store” which corresponds to mere data gathering and/or output.
Accordingly, this claim is directed to an abstract idea.
Step 2B: The claim does not recite additional elements that amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception, add insignificant extra-solution activity to the abstract idea, and/or generally link the abstract idea to a particular technological environment or field of use. Additionally, the additional limitations, identified as insignificant extra-solution activity to the abstract idea, amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields such as:
computer functions that have been identified by the courts as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity, see MPEP 2106.05(d)(II), such as:
“a provider portal that provides each provider”, and “view the data store”, which corresponds to receiving or transmitting data over a network.
“within a repository of medication information, a data store of”, “to the data store” and “within the data store” which corresponds to storing and retrieving information in memory.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 55,
Claim 55 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 55 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising transmitting to a patient mobile device an identification of the prescriptions of the data store, prescribed to the patient by the plurality of providers from different provider networks.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 56,
Claim 56 depends from claim 55 and inherits all the limitations of the claim from which it depends. Claim 56 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising transmitting the identification of the prescriptions of the data store to a computing device of the provider.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 57,
Claim 57 depends from claim 56 and inherits all the limitations of the claim from which it depends. Claim 57 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein transmitting the identification of the prescriptions to the computing device of the provider comprises transmitting the identification of the prescriptions to the computing device of the provider in response to a request received from the patient mobile device to transmit the identification to the computing device of the provider.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 58,
Claim 58 depends from claim 56 and inherits all the limitations of the claim from which it depends. Claim 58 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein transmitting the identification of the prescriptions to the computing device of the provider comprises transmitting the identification of the prescriptions to the computing device of the provider from the patient mobile device.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 59,
Claim 59 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 59 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising: receiving… a request to … add, to …providers with permission to access the data store of prescriptions currently prescribed to the patient, a first provider, from a first provider network, and a second provider, from a second provider network; and providing the first and second providers with access to the data store of prescriptions currently prescribed to the patient, …, in response to receiving the request from the patient.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“digitally” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“from the patient via a patient portal”, “via the provider portal”, and “via the patient portal” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
“a data store of” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and storing and retrieving information in memory.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 60,
Claim 60 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 60 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising restricting each provider within the plurality of providers from modifying prescriptions for which the provider is not the prescribing provider.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 61,
Claim 61 depends from claim 60 and inherits all the limitations of the claim from which it depends. Claim 61 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising: detecting that a new prescription, which a first provider of a first provider network is attempting to add to the data store of prescriptions currently prescribed to the patient, is contraindicated because of an existing prescription that was added to the data store of prescriptions currently prescribed to the patient by a second provider of a second provider network; and in response to detecting that the new prescription is contraindicated because of the existing prescription, performing a …circumvention.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“digital” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 62,
Claim 62 depends from claim 61 and inherits all the limitations of the claim from which it depends. Claim 62 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the …circumvention comprises …alerting the first provider of the first provider network that the attempted new prescription is contraindicated because of the existing prescription added to the data store by the second provider of the second provider network.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“digital” and “digitally” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 63,
Claim 63 depends from claim 61 and inherits all the limitations of the claim from which it depends. Claim 63 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the …circumvention comprises restricting the first provider of the first provider network from adding the new prescription to the data store of prescriptions currently prescribed to the patient.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“digital” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 64,
Claim 64 depends from claim 61 and inherits all the limitations of the claim from which it depends. Claim 64 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the …circumvention comprises providing a …prompt to the first provider of the first provider network suggesting an alternate prescription that is not contraindicated.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“digital” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 65,
Claim 65 depends from claim 61 and inherits all the limitations of the claim from which it depends. Claim 65 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the … circumvention comprises enabling the first provider of the first provider network to contact the second provider of the second provider network to request that the second provider of the second provider network modify or remove the existing prescription.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“digital” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 66,
Claim 66 depends from claim 65 and inherits all the limitations of the claim from which it depends. Claim 66 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising: receiving, from the first provider of the first provider network, a digital message for the second provider of the second provider network, the digital message comprising a request to modify the existing prescription; and in response to receiving the digital message, routing the digital message to the second provider of the second provider network.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 67,
Claim 67 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 67 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising: detecting a metric of patient adherence to a prescription within the data store of prescriptions currently prescribed to the patient;” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“adding the metric of patient adherence to the repository of medication information.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and storing and retrieving information in memory.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 68,
Claim 68 depends from claim 67 and inherits all the limitations of the claim from which it depends. Claim 68 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein detecting the metric of patient adherence comprises detecting the metric of patient adherence based on refill information collected from a pharmacy filling the prescription.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 69,
Claim 69 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 69 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein: the method further comprises providing, to a pharmacy, …access to the data store of prescriptions currently prescribed to the patient by the plurality of providers from different provider networks;” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“a pharmacy portal that provides” and “the provider portal presents, to a provider, an order element that, when selected, initiates a prescription to be ordered at the pharmacy." further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 70,
Claim 70 depends from claim 69 and inherits all the limitations of the claim from which it depends. Claim 70 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the pharmacy portal enables the pharmacy to route digital messages to any provider within the plurality of providers from different provider networks to be received via the provider portal.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 71,
Claim 71 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 71 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“determining, based on timing information maintained in the data store for a first prescription for a first medication prescribed by a first provider of a first provider network, that the patient is to take the first medication at a first moment in time; determining, based on timing information maintained in the data store for a second prescription for a second medication prescribed by a second provider of a second provider network, that the patient is to take the second medication at a second moment in time; and in response to determining that the patient is to take the first medication at the first moment in time and the second medication at the second moment in time,” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“further comprising instructing a patient mobile device to present an alert each time a medication within the data store of prescriptions currently prescribed to the patient is to be taken, wherein instructing the patient mobile device to present the alert each time a medication is to be taken comprises:” and “instructing the patient mobile device to present, at the first moment in time, a first alert that it is time to take the first medication and to present, at the second moment in time, a second alert that it is time to take the second medication.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 72,
Claim 72 depends from claim 71 and inherits all the limitations of the claim from which it depends. Claim 72 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising, each time a medication within the data store of prescriptions is to be taken, in addition to instructing the patient mobile device to present an alert, … verify that a correct medication is being taken, wherein ….verifying that the correct medication is being taken comprises: prompting the patient to present an identifier, affixed to a medication bottle” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“instructing the patient mobile device to digitally” and “digitally” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“to a camera of the patient mobile device; and scanning the identifier presented to the camera” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 73,
Claim 73 depends from claim 72 and inherits all the limitations of the claim from which it depends. Claim 73 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein … verifying that a correct medication is being taken further comprises at least one of: … indicating that the correct medication is being taken in response to determining that the identifier corresponds to the medication; or … indicating that an incorrect medication is being taken in response to determining that the identifier corresponds to another medication.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“digitally” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 74,
Claim 74 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 74 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“a name of the medication; dosing information for the medication; a patient reaction to the medication; timing information for taking the medication; a date on which the medication was originally prescribed; a date on which the prescription was modified; an expiration date for the prescription; a condition targeted by the medication; a number of times the prescription has been filled; a number of refills left for the prescription; contact information for a pharmacy at which the medication has been filled; or contact information for a provider who prescribed the medication.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“wherein the data store comprises, for a prescription for a medication within the data store, at least one of:” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 75,
Claim 75 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 75 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising: receiving, …, a request, from a provider treating the patient at a first provider network, for another provider treating the patient at a second provider network to update or cancel a prescription previously added to the repository of medication for the patient.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“at the repository” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 76,
Claim 76 depends from claim 54 and inherits all the limitations of the claim from which it depends. Claim 76 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising: providing, …, a list of medications currently prescribed to the patient;” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“to a patient mobile device of the patient from the repository of medication information for the plurality of patients” and “and wherein the patient mobile device is configured to present the list of medications to a digital medical record of a provider prior to or during a patient encounter to be entered into the digital medical record as a record of current medications of the patient.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 77,
Claim 77 depends from claim 76 and inherits all the limitations of the claim from which it depends. Claim 77 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein presenting the list of medications to the digital medical record comprises wirelessly transferring the list of medications from the patient mobile device to the digital medical record.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 78,
Claim 78 depends from claim 77 and inherits all the limitations of the claim from which it depends. Claim 78 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein wirelessly transferring the list of medications from the patient mobile device to the digital medical record comprises: presenting, within an interface of the patient mobile device, a wireless-transfer initiation element; receiving user input selecting the wireless-transfer initiation element; and wirelessly transferring the list of medications from the patient mobile device to a computing device of the provider for entry into the digital medical record, in response to receiving the user input.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 79,
Claim 79 depends from claim 76 and inherits all the limitations of the claim from which it depends. Claim 79 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the digital medical record is maintained by at least one of: a drug management system that maintains the repository; or a third-party electronic medical record system.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 80,
Claim 80 is substantially similar to claim 54. Accordingly, claim 80 is rejected for the same reasons as claim 54.
As per claim 81,
Claim 81 is substantially similar to claim 54. Accordingly, claim 81 is rejected for the same reasons as claim 54.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 54-60, 74, 75, 80 and 81 are rejected under 35 U.S.C. 102(a)(2) as being Anticipated by Streat et al. (US 2023/0187086; herein referred to as Streat).
As per claim 54,
Streat discloses a computer-implemented method comprising: maintaining, within a repository of medication information, a data store of prescriptions for medication currently prescribed to a patient by a plurality of providers from different provider networks and providing, to each provider within the plurality of providers from different provider networks, a provider portal that provides each provider with access to view the data store, add new prescriptions to the data store, and modify existing prescriptions within the data store:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
As per claim 55,
Streat discloses the limitations of claim 54.
further comprising transmitting to a patient mobile device an identification of the prescriptions of the data store, prescribed to the patient by the plurality of providers from different provider networks:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
As per claim 56,
Streat discloses the limitations of claim 55.
further comprising transmitting the identification of the prescriptions of the data store to a computing device of the provider:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
As per claim 57,
Streat discloses the limitations of claim 56.
wherein transmitting the identification of the prescriptions to the computing device of the provider comprises transmitting the identification of the prescriptions to the computing device of the provider in response to a request received from the patient mobile device to transmit the identification to the computing device of the provider:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
As per claim 58,
Streat discloses the limitations of claim 56.
wherein transmitting the identification of the prescriptions to the computing device of the provider comprises transmitting the identification of the prescriptions to the computing device of the provider from the patient mobile device:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
As per claim 59,
Streat discloses the limitations of claim 54,
Streat further discloses further comprising: receiving, from the patient via a patient portal, a request to digitally add, to a data store of providers with permission to access the data store of prescriptions currently prescribed to the patient, a first provider, from a first provider network, and a second provider, from a second provider network; and providing the first and second providers with access to the data store of prescriptions currently prescribed to the patient, via the provider portal, in response to receiving the request from the patient via the patient portal:
(Paragraphs [0032], [0116] and [0149] of Streat. The teaching describes that patient visit profiles may provide regularized input to matching engines that may match patient visit profiles with providers. Some or all of the attributed included patient visit profiles may be vectorized of otherwise formatted to be suitable for evaluating with matching models to generate matching scores for matching providers with visits. Healthcare service engines may be arranged to provide patient visit profiles to matching engines. In some embodiments, matching engines may be arranged to match or attempt to match patients to one or more visits or providers based on patient visit profile 606, provider profiles 610, or matching models 612. In this example, matching/routing information 614 represents the output of matching engine 608. Healthcare service engines may be arranged to restrict access to the information included in provider portal based on the organizational structure of the provider organizations. Accordingly, in some embodiments, one or more users of a provider portal may have access to different information. For example, in some embodiments, a healthcare service engine may provide a provider portal scoped to multiple clinic/hospital locations in a healthcare network)
As per claim 60,
Streat discloses the limitations of claim 54.
Streat further discloses further comprising restricting each provider within the plurality of providers from modifying prescriptions for which the provider is not the prescribing provider:
(Paragraphs [0032], [0116] and [0149] of Streat. The teaching describes that patient visit profiles may provide regularized input to matching engines that may match patient visit profiles with providers. Some or all of the attributed included patient visit profiles may be vectorized of otherwise formatted to be suitable for evaluating with matching models to generate matching scores for matching providers with visits. Healthcare service engines may be arranged to provide patient visit profiles to matching engines. In some embodiments, matching engines may be arranged to match or attempt to match patients to one or more visits or providers based on patient visit profile 606, provider profiles 610, or matching models 612. In this example, matching/routing information 614 represents the output of matching engine 608. Healthcare service engines may be arranged to restrict access to the information included in provider portal based on the organizational structure of the provider organizations. Accordingly, in some embodiments, one or more users of a provider portal may have access to different information. For example, in some embodiments, a healthcare service engine may provide a provider portal scoped to multiple clinic/hospital locations in a healthcare network)
As per claim 74,
Streat discloses the limitations of claim 54.
Streat further discloses wherein the data store comprises, for a prescription for a medication within the data store, at least one of: a name of the medication; dosing information for the medication; a patient reaction to the medication; timing information for taking the medication; a date on which the medication was originally prescribed; a date on which the prescription was modified; an expiration date for the prescription; a condition targeted by the medication; a number of times the prescription has been filled; a number of refills left for the prescription; contact information for a pharmacy at which the medication has been filled; or contact information for a provider who prescribed the medication:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
As per claim 75,
Streat discloses the limitations of claim 54.
Streat further discloses further comprising: receiving, at the repository, a request, from a provider treating the patient at a first provider network, for another provider treating the patient at a second provider network to update or cancel a prescription previously added to the repository of medication for the patient:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
As per claim 80,
Claim 80 is substantially similar to claim 54. Accordingly, claim 80 is rejected for the same reasons as claim 54.
As per claim 81,
Claim 81 is substantially similar to claim 54. Accordingly, claim 81 is rejected for the same reasons as claim 54.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 61-66 and 76-79 are rejected under 35 U.S.C. 103 as being unpatentable over Streat in view of Kamen et al. (US 2013/0317753; herein referred to as Kamen).
As per claim 61,
Streat discloses the limitations of claim 60.
Streat does not explicitly teach further comprising: detecting that a new prescription, which a first provider of a first provider network is attempting to add to the data store of prescriptions currently prescribed to the patient, is contraindicated because of an existing prescription that was added to the data store of prescriptions currently prescribed to the patient by a second provider of a second provider network; and in response to detecting that the new prescription is contraindicated because of the existing prescription, performing a digital circumvention.
However, Kamen teaches detecting that a new prescription, which a first provider of a first provider network is attempting to add to the data store of prescriptions currently prescribed to the patient, is contraindicated because of an existing prescription that was added to the data store of prescriptions currently prescribed to the patient; and in response to detecting that the new prescription is contraindicated because of the existing prescription, performing a digital circumvention:
(Paragraph [0080] of Kamen. The teaching describes the new order may be an order for medication and the monitoring server may be adapted to determine if the new order meets the another predetermined criteria by determining if the order for medication is contraindicated by a currently prescribed medication. The monitoring server may communicate with a database to determine if the new order meets the another predetermined criteria. The monitoring server may be configured to send an alert to the monitoring client when the new order does not meet the another predetermined criteria.)
It would have been obvious to one of ordinary skill in the art before the time of filing to add to the prescription management features of Streat, the contraindication circumvention of Kamen. The prior art in Streat and Kamen teaches each element claimed, although not in a single reference. One of ordinary skill in the art would have combined the elements as claimed by known methods and the in combination, each element merely would have performed the same function as it did separately. One of ordinary skill in the art would have recognized that the results of the combination were predictable. Accordingly, the combination of Streat and Kamen would have been found to be obvious by one of ordinary skill in the art.
The combined teaching of Streat and Kamen would have then taught detecting that a new prescription, which a first provider of a first provider network is attempting to add to the data store of prescriptions currently prescribed to the patient, is contraindicated because of an existing prescription that was added to the data store of prescriptions currently prescribed to the patient by a second provider of a second provider network; and in response to detecting that the new prescription is contraindicated because of the existing prescription, performing a digital circumvention:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
(Paragraph [0080] of Kamen. The teaching describes the new order may be an order for medication and the monitoring server may be adapted to determine if the new order meets the another predetermined criteria by determining if the order for medication is contraindicated by a currently prescribed medication. The monitoring server may communicate with a database to determine if the new order meets the another predetermined criteria. The monitoring server may be configured to send an alert to the monitoring client when the new order does not meet the another predetermined criteria.)
As per claim 62,
The combined teaching of Streat and Kamen teaches the limitations of claim 61.
The combined teaching of Streat and Kamen further teach wherein the digital circumvention comprises digitally alerting the first provider of the first provider network that the attempted new prescription is contraindicated because of the existing prescription added to the data store by the second provider of the second provider network:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
(Paragraph [0080] of Kamen. The teaching describes the new order may be an order for medication and the monitoring server may be adapted to determine if the new order meets the another predetermined criteria by determining if the order for medication is contraindicated by a currently prescribed medication. The monitoring server may communicate with a database to determine if the new order meets the another predetermined criteria. The monitoring server may be configured to send an alert to the monitoring client when the new order does not meet the another predetermined criteria.)
As per claim 63,
The combined teaching of Streat and Kamen teaches the limitations of claim 61.
The combined teaching of Streat and Kamen further teaches wherein the digital circumvention comprises restricting the first provider of the first provider network from adding the new prescription to the data store of prescriptions currently prescribed to the patient:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
(Paragraphs [0032], [0116] and [0149] of Streat. The teaching describes that patient visit profiles may provide regularized input to matching engines that may match patient visit profiles with providers. Some or all of the attributed included patient visit profiles may be vectorized of otherwise formatted to be suitable for evaluating with matching models to generate matching scores for matching providers with visits. Healthcare service engines may be arranged to provide patient visit profiles to matching engines. In some embodiments, matching engines may be arranged to match or attempt to match patients to one or more visits or providers based on patient visit profile 606, provider profiles 610, or matching models 612. In this example, matching/routing information 614 represents the output of matching engine 608. Healthcare service engines may be arranged to restrict access to the information included in provider portal based on the organizational structure of the provider organizations. Accordingly, in some embodiments, one or more users of a provider portal may have access to different information. For example, in some embodiments, a healthcare service engine may provide a provider portal scoped to multiple clinic/hospital locations in a healthcare network)
(Paragraph [0080] of Kamen. The teaching describes the new order may be an order for medication and the monitoring server may be adapted to determine if the new order meets the another predetermined criteria by determining if the order for medication is contraindicated by a currently prescribed medication. The monitoring server may communicate with a database to determine if the new order meets the another predetermined criteria. The monitoring server may be configured to send an alert to the monitoring client when the new order does not meet the another predetermined criteria.)
As per claim 64,
The combined teaching of Streat and Kamen teaches the limitations of claim 61.
The combined teaching of Streat and Kamen further teaches wherein the digital circumvention comprises providing a digital prompt to the first provider of the first provider network suggesting an alternate prescription that is not contraindicated:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
(Paragraphs [0080] and [0621] of Kamen. The teaching describes the new order may be an order for medication and the monitoring server may be adapted to determine if the new order meets the another predetermined criteria by determining if the order for medication is contraindicated by a currently prescribed medication. The monitoring server may communicate with a database to determine if the new order meets the another predetermined criteria. The monitoring server may be configured to send an alert to the monitoring client when the new order does not meet the another predetermined criteria. The data management therapy component 3406 can communicate with one or more external data systems 3410. For example, the data management therapy component 3406 may compare the a patient's 3412 ID with electronic medical records 3410 to determine if the therapy entered (e.g., an infusion rate) via the user interface component 3402 is: (1) safe for the patient; (2) conforms with the patient's 3412 ailment, condition, disease, and/or therapy plan; (3) is not contraindicated by another medication or treatment; (4) and does not require the presence of a specialists not-determined to be within the proximity to the patient 3412 (as determined by an RFID tag, voice authentication, facial-recognition, username/password identification or verification, secure signatures, or the like). This element of (3) is construed to mean that another medication was indicated as not being contraindicated)
As per claim 65,
The combined teaching of Streat and Kamen teaches the limitations of claim 61.
The combined teaching of Streat and Kamen further teaches wherein the digital circumvention comprises enabling the first provider of the first provider network to contact the second provider of the second provider network to request that the second provider of the second provider network modify or remove the existing prescription:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
(Paragraph [0080] of Kamen. The teaching describes the new order may be an order for medication and the monitoring server may be adapted to determine if the new order meets the another predetermined criteria by determining if the order for medication is contraindicated by a currently prescribed medication. The monitoring server may communicate with a database to determine if the new order meets the another predetermined criteria. The monitoring server may be configured to send an alert to the monitoring client when the new order does not meet the another predetermined criteria.)
As per claim 66,
The combined teaching of Streat and Kamen teaches the limitations of claim 65.
The combined teaching of Streat and Kamen further teaches further comprising: receiving, from the first provider of the first provider network, a digital message for the second provider of the second provider network, the digital message comprising a request to modify the existing prescription; and in response to receiving the digital message, routing the digital message to the second provider of the second provider network:
(Paragraphs [0052], [0102]-[0104], [0114] and [0242] of Streat. The teaching describes patient interfaces which may provide one or more patient portals, such as, patient portal 406. In one or more of the various embodiments, patient portals may be arranged to provide interactive reports, user interfaces, or the like, that enable patients to view or interact with their healthcare providers. In some embodiments, patient portals may be arranged to enable patients to review upcoming appointments, past appointments, request new appointments, or the like. Further, in some embodiments, patient portals may be arranged to enable to patients to view some or all of their electronic health records (EHRs). In some embodiments, patient portals may be communicatively coupled with healthcare service engine 402 using one or more networks. Accordingly, in some embodiments, healthcare service engines may be arranged to provide the information that may be presented in the patient portal. healthcare service engines, such as, healthcare service engine 402 may be arranged to process various requests from patients, providers, or provider organizations. In some embodiments, healthcare service engines may be arranged to process requests from one or more authorized third-party services, such as, insurance providers, or the like. In some embodiments, healthcare service engines may be arranged to exchange information with other third-party services, such as, EHR systems, hospital management systems, billing services, or the like. In some embodiments, healthcare service engines may be arranged to enable patients to schedule visits with providers. Also, in some embodiments, healthcare service engines may be arranged to enable provider organizations to manage patients, providers, visits, or the like. healthcare service engines may be arranged to provide one or more provider interfaces, such as, provider interfaces 424 that enable providers or provider organizations (e.g., administrative personnel, or the like) to engage with the healthcare service engines. Accordingly, in some embodiments, provider interfaces may include one or more provider portals, such as, provider portal 426 that may enable providers to review practice related information, such as, upcoming appointments, or the like. In some embodiments, provider portals may be arranged to enable providers to communicate with patients (e.g., secure messaging), review past visits, accept/decline visit requests, approve/disapprove treatment requests, approve/disapprove prescription requests, or the like. Healthcare service engines may be arranged to enable patients to request visit times or request providers that provider organizations or providers may be enabled to confirm, modify, or reject upon review. This means that in the context of prescription requests, the provider is able to view, add new, and modify data in the data store. As shown, system 100 of FIG. 1 includes local area networks (LANs)/wide area networks (WANs)—(network) 110, wireless network 108, client computers 102-105, healthcare service platform computer 116, or the like.)
(Paragraph [0080] of Kamen. The teaching describes the new order may be an order for medication and the monitoring server may be adapted to determine if the new order meets the another predetermined criteria by determining if the order for medication is contraindicated by a currently prescribed medication. The monitoring server may communicate with a database to determine if the new order meets the another predetermined criteria. The monitoring server may be configured to send an alert to the monitoring client when the new order does not meet the another predetermined criteria.)
As per claim 76,
Streat discloses the limitations of claim 54.
Streat does not explicitly teach further comprising: providing, to a patient mobile device of the patient from the repository of medication information for the plurality of patients, a list of medications currently prescribed to the patient; and wherein the patient mobile device is configured to present the list of medications to a digital medical record of a provider prior to or during a patient encounter to be entered into the digital medical record as a record of current medications of the patient.
However, Kamen teaches providing, to a patient mobile device of the patient from the repository of medication information for the plurality of patients, a list of medications currently prescribed to the patient; and wherein the patient mobile device is configured to present the list of medications to a digital medical record of a provider prior to or during a patient encounter to be entered into the digital medical record as a record of current medications of the patient:
(Paragraphs [0664] and [0665 of Kamen. The teaching describes a timing diagram 4600 illustrating, in accordance with some embodiments of the present disclosures, a method in which an infusion pump 4408A and/or a hub 4406 requests from the tablet 4402 which prescription was prescribed for a patient by querying an electronic medical records application executed on the tablet 4402. A user may enter the patient's identification or the patient's identification is scanned using the scanner 4404. The electronic medical records application executed on the tablet 4402 may request the prescribed medication from the one or more servers 4410. A tablet application may request the user to choose from a list of available prescriptions if there are multiple prescriptions, e.g., multiple infusion-pump-based prescriptions. The timing diagram 4600 illustrates acts 4602-4652. Act 4602 requests, using a monitoring client during act 4604, a list of prescription for a patient after identifying the patient. Act 4602 “pulls” the prescription information from the monitoring client. The patient may be identified using a barcode scanner, an RFID interrogator, voice- or facial-recognition, or via manual entry. The tablet communicates the patient's ID during act 4606 using an EMR API to a tablet or computer application of 4608. The API may include a secure data class. The patient's identity is communicated in act 4610 to an EMR database, which in act 4612, communicates the list of prescription to an EMR API during act 4614, which is received by the EMR program running on the monitoring client or computer app in act 4616, which in turn communicates them in act 4618 to the monitoring client application. The communication between the EMR Tablet/Computer Application and the EMR database may be via middleware (e.g., middleware on the monitoring server 3 of FIG. 1).)
It would have been obvious to one of ordinary skill in the art before the time of filing to add to the prescription management features of Streat, the prescription listings of Kamen. The prior art in Streat and Kamen teaches each element claimed, although not in a single reference. One of ordinary skill in the art would have combined the elements as claimed by known methods and the in combination, each element merely would have performed the same function as it did separately. One of ordinary skill in the art would have recognized that the results of the combination were predictable. Accordingly, the combination of Streat and Kamen would have been found to be obvious by one of ordinary skill in the art.
As per claim 77,
The combined teaching of Streat and Kamen teaches the limitations of claim 76,
Kamen further teaches wherein presenting the list of medications to the digital medical record comprises wirelessly transferring the list of medications from the patient mobile device to the digital medical record:
(Paragraphs [0664] and [0665 of Kamen. The teaching describes a timing diagram 4600 illustrating, in accordance with some embodiments of the present disclosures, a method in which an infusion pump 4408A and/or a hub 4406 requests from the tablet 4402 which prescription was prescribed for a patient by querying an electronic medical records application executed on the tablet 4402. A user may enter the patient's identification or the patient's identification is scanned using the scanner 4404. The electronic medical records application executed on the tablet 4402 may request the prescribed medication from the one or more servers 4410. A tablet application may request the user to choose from a list of available prescriptions if there are multiple prescriptions, e.g., multiple infusion-pump-based prescriptions. The timing diagram 4600 illustrates acts 4602-4652. Act 4602 requests, using a monitoring client during act 4604, a list of prescription for a patient after identifying the patient. Act 4602 “pulls” the prescription information from the monitoring client. The patient may be identified using a barcode scanner, an RFID interrogator, voice- or facial-recognition, or via manual entry. The tablet communicates the patient's ID during act 4606 using an EMR API to a tablet or computer application of 4608. The API may include a secure data class. The patient's identity is communicated in act 4610 to an EMR database, which in act 4612, communicates the list of prescription to an EMR API during act 4614, which is received by the EMR program running on the monitoring client or computer app in act 4616, which in turn communicates them in act 4618 to the monitoring client application. The communication between the EMR Tablet/Computer Application and the EMR database may be via middleware (e.g., middleware on the monitoring server 3 of FIG. 1).)
As per claim 78,
The combined teaching of Streat and Kamen teaches the limitations of claim 77.
Kamen further teaches wherein wirelessly transferring the list of medications from the patient mobile device to the digital medical record comprises: presenting, within an interface of the patient mobile device, a wireless-transfer initiation element; receiving user input selecting the wireless-transfer initiation element; and wirelessly transferring the list of medications from the patient mobile device to a computing device of the provider for entry into the digital medical record, in response to receiving the user input:
(Paragraphs [0664] and [0665 of Kamen. The teaching describes a timing diagram 4600 illustrating, in accordance with some embodiments of the present disclosures, a method in which an infusion pump 4408A and/or a hub 4406 requests from the tablet 4402 which prescription was prescribed for a patient by querying an electronic medical records application executed on the tablet 4402. A user may enter the patient's identification or the patient's identification is scanned using the scanner 4404. The electronic medical records application executed on the tablet 4402 may request the prescribed medication from the one or more servers 4410. A tablet application may request the user to choose from a list of available prescriptions if there are multiple prescriptions, e.g., multiple infusion-pump-based prescriptions. The timing diagram 4600 illustrates acts 4602-4652. Act 4602 requests, using a monitoring client during act 4604, a list of prescription for a patient after identifying the patient. Act 4602 “pulls” the prescription information from the monitoring client. The patient may be identified using a barcode scanner, an RFID interrogator, voice- or facial-recognition, or via manual entry. The tablet communicates the patient's ID during act 4606 using an EMR API to a tablet or computer application of 4608. The API may include a secure data class. The patient's identity is communicated in act 4610 to an EMR database, which in act 4612, communicates the list of prescription to an EMR API during act 4614, which is received by the EMR program running on the monitoring client or computer app in act 4616, which in turn communicates them in act 4618 to the monitoring client application. The communication between the EMR Tablet/Computer Application and the EMR database may be via middleware (e.g., middleware on the monitoring server 3 of FIG. 1).)
As per claim 79,
The combined teaching of Streat and Kamen teaches the limitations of claim 76.
Kamen further teaches wherein the digital medical record is maintained by at least one of: a drug management system that maintains the repository; or a third-party electronic medical record system:
(Paragraphs [0664] and [0665 of Kamen. The teaching describes a timing diagram 4600 illustrating, in accordance with some embodiments of the present disclosures, a method in which an infusion pump 4408A and/or a hub 4406 requests from the tablet 4402 which prescription was prescribed for a patient by querying an electronic medical records application executed on the tablet 4402. A user may enter the patient's identification or the patient's identification is scanned using the scanner 4404. The electronic medical records application executed on the tablet 4402 may request the prescribed medication from the one or more servers 4410. A tablet application may request the user to choose from a list of available prescriptions if there are multiple prescriptions, e.g., multiple infusion-pump-based prescriptions. The timing diagram 4600 illustrates acts 4602-4652. Act 4602 requests, using a monitoring client during act 4604, a list of prescription for a patient after identifying the patient. Act 4602 “pulls” the prescription information from the monitoring client. The patient may be identified using a barcode scanner, an RFID interrogator, voice- or facial-recognition, or via manual entry. The tablet communicates the patient's ID during act 4606 using an EMR API to a tablet or computer application of 4608. The API may include a secure data class. The patient's identity is communicated in act 4610 to an EMR database, which in act 4612, communicates the list of prescription to an EMR API during act 4614, which is received by the EMR program running on the monitoring client or computer app in act 4616, which in turn communicates them in act 4618 to the monitoring client application. The communication between the EMR Tablet/Computer Application and the EMR database may be via middleware (e.g., middleware on the monitoring server 3 of FIG. 1).)
Claims 67, 68 and 71-73 are rejected under 35 U.S.C. 103 as being unpatentable over Streat in view of Hanson et al. (US 20190326004; herein referred to as Hanson).
As per claim 67,
Streat discloses the limitations of claim 54.
Streat does not explicitly teach further comprising: detecting a metric of patient adherence to a prescription within the data store of prescriptions currently prescribed to the patient; and adding the metric of patient adherence to the repository of medication information.
However, Hanson teaches : detecting a metric of patient adherence to a prescription within the data store of prescriptions currently prescribed to the patient; and adding the metric of patient adherence to the repository of medication information:
(Paragraphs [0062]-[0064] of Hanson. The teaching describes he system 300 may perform proactive care recipient guidance, reminders, and refills. To help encourage correct consumption and management of medications, several features are provided to assist those taking medications. For example, users can receive notifications preemptively reminding them to take medications prior to their scheduled times. Additionally, illumination, audio, or other user alerting devices within the installed home or facility can be employed to notify users to take a specific medication (e.g., reminder) or to alert them to one of various issues (e.g., medication bottle vacant, improper medication removal, medication bottle needing refill, etc.). All notification mechanisms (e.g., IVR, SMS, email, etc.) are possible user alerting devices. Also, information assessed from the analysis of medication reporting data can be used to remind users to refill medications or to signal third-parties (e.g., pharmacies, home care agents, caregivers, etc.) of the need for refills or to initiate refills. Contextual data can also be combined with other sensed data to make health or wellness assessments based on perceived compliance level and user activity. In some examples, the system 300 may analyze data captured by other sensors (e.g., sensors of a home monitoring system) and determine how to report a medication event based on the analysis. In these examples, the system 300 may determine whether a property is occupied by one or more persons other than the medication recipient associated with a medication event and implement different reporting strategies depending on whether the property is occupied. For instance, the system 300 may provide a local alert or reminder (e.g., audible alert in the property) for a missed or improper medication event when the system 300 determines that the property is presently occupied. The system 300 may escalate the local alert to a remote alert or reminder (e.g., a message to a remote monitoring service that dispatches emergency services) if the system 300 determines that no corrective action has been taken for a threshold period of time (e.g., the system 300 does not detect a proper medication event or receive confirmation that the improper medication event is being handled for a threshold period of time). When the system 300 determines that the property is not presently occupied, the system 300 may send the remote alert or reminder in the first instance. Historical data regarding medication compliance may be used in reporting analysis. The historical data may include information describing compliance with past medication schedules and past occupancy/usage data for the property. For example, the system 300 may determine that a first user adheres very strictly to a medication schedule based on compliance with past medication schedules and a second user does not adhere as strictly to a medication schedule, but typically complies with the medication schedule within permissible tolerances. In this example, the system 300 may send a heightened alert (e.g., a message to a remote monitoring service that dispatches emergency services) a short time after the system 300 detects that the first user misses a medication event, but may wait longer to send a heightened alert after the system 300 detects that the second user misses a medication event to allow the second user more time within the permissible tolerances. In another example, the system 300 may monitor past occupancy of the property and determine typical occupancy patterns for the property. In this example, the system 300 may use the typical occupancy patterns to infer whether the property is occupied at the time of a missed or improper medication and handle reporting for the missed or improper medication event based on the inference (e.g., as described above for examples in which occupancy of the property is detected directly).)
It would have been obvious to one of ordinary skill in the art before the time of filing to add to the prescription management features of Streat, the medication adherence processes of Hanson. The prior art in Streat and Kamen teaches each element claimed, although not in a single reference. One of ordinary skill in the art would have combined the elements as claimed by known methods and the in combination, each element merely would have performed the same function as it did separately. One of ordinary skill in the art would have recognized that the results of the combination were predictable. Accordingly, the combination of Streat and Hanson would have been found to be obvious by one of ordinary skill in the art.
As per claim 68,
The combined teaching of Streat and Hanson teaches the limitations of claim 67.
Hanson further teaches wherein detecting the metric of patient adherence comprises detecting the metric of patient adherence based on refill information collected from a pharmacy filling the prescription:
(Paragraphs [0062]-[0064] of Hanson. The teaching describes he system 300 may perform proactive care recipient guidance, reminders, and refills. To help encourage correct consumption and management of medications, several features are provided to assist those taking medications. For example, users can receive notifications preemptively reminding them to take medications prior to their scheduled times. Additionally, illumination, audio, or other user alerting devices within the installed home or facility can be employed to notify users to take a specific medication (e.g., reminder) or to alert them to one of various issues (e.g., medication bottle vacant, improper medication removal, medication bottle needing refill, etc.). All notification mechanisms (e.g., IVR, SMS, email, etc.) are possible user alerting devices. Also, information assessed from the analysis of medication reporting data can be used to remind users to refill medications or to signal third-parties (e.g., pharmacies, home care agents, caregivers, etc.) of the need for refills or to initiate refills. Contextual data can also be combined with other sensed data to make health or wellness assessments based on perceived compliance level and user activity. In some examples, the system 300 may analyze data captured by other sensors (e.g., sensors of a home monitoring system) and determine how to report a medication event based on the analysis. In these examples, the system 300 may determine whether a property is occupied by one or more persons other than the medication recipient associated with a medication event and implement different reporting strategies depending on whether the property is occupied. For instance, the system 300 may provide a local alert or reminder (e.g., audible alert in the property) for a missed or improper medication event when the system 300 determines that the property is presently occupied. The system 300 may escalate the local alert to a remote alert or reminder (e.g., a message to a remote monitoring service that dispatches emergency services) if the system 300 determines that no corrective action has been taken for a threshold period of time (e.g., the system 300 does not detect a proper medication event or receive confirmation that the improper medication event is being handled for a threshold period of time). When the system 300 determines that the property is not presently occupied, the system 300 may send the remote alert or reminder in the first instance. Historical data regarding medication compliance may be used in reporting analysis. The historical data may include information describing compliance with past medication schedules and past occupancy/usage data for the property. For example, the system 300 may determine that a first user adheres very strictly to a medication schedule based on compliance with past medication schedules and a second user does not adhere as strictly to a medication schedule, but typically complies with the medication schedule within permissible tolerances. In this example, the system 300 may send a heightened alert (e.g., a message to a remote monitoring service that dispatches emergency services) a short time after the system 300 detects that the first user misses a medication event, but may wait longer to send a heightened alert after the system 300 detects that the second user misses a medication event to allow the second user more time within the permissible tolerances. In another example, the system 300 may monitor past occupancy of the property and determine typical occupancy patterns for the property. In this example, the system 300 may use the typical occupancy patterns to infer whether the property is occupied at the time of a missed or improper medication and handle reporting for the missed or improper medication event based on the inference (e.g., as described above for examples in which occupancy of the property is detected directly).)
As per claim 71,
Streat discloses the limitations of claim 54.
Streat does not explicitly teach further comprising instructing a patient mobile device to present an alert each time a medication within the data store of prescriptions currently prescribed to the patient is to be taken, wherein instructing the patient mobile device to present the alert each time a medication is to be taken comprises: determining, based on timing information maintained in the data store for a first prescription for a first medication prescribed by a first provider of a first provider network, that the patient is to take the first medication at a first moment in time; determining, based on timing information maintained in the data store for a second prescription for a second medication prescribed by a second provider of a second provider network, that the patient is to take the second medication at a second moment in time; and in response to determining that the patient is to take the first medication at the first moment in time and the second medication at the second moment in time, instructing the patient mobile device to present, at the first moment in time, a first alert that it is time to take the first medication and to present, at the second moment in time, a second alert that it is time to take the second medication.
However, Hanson teaches teach further comprising instructing a patient mobile device to present an alert each time a medication within the data store of prescriptions currently prescribed to the patient is to be taken, wherein instructing the patient mobile device to present the alert each time a medication is to be taken comprises: determining, based on timing information maintained in the data store for a first prescription for a first medication prescribed by a first provider of a first provider network, that the patient is to take the first medication at a first moment in time; determining, based on timing information maintained in the data store for a second prescription for a second medication prescribed by a second provider of a second provider network, that the patient is to take the second medication at a second moment in time; and in response to determining that the patient is to take the first medication at the first moment in time and the second medication at the second moment in time, instructing the patient mobile device to present, at the first moment in time, a first alert that it is time to take the first medication and to present, at the second moment in time, a second alert that it is time to take the second medication:
(Paragraphs [0033], and [0062]-[0064] of Hanson. The teaching describes he system 300 may perform proactive care recipient guidance, reminders, and refills. To help encourage correct consumption and management of medications, several features are provided to assist those taking medications. For example, users can receive notifications preemptively reminding them to take medications prior to their scheduled times. Additionally, illumination, audio, or other user alerting devices within the installed home or facility can be employed to notify users to take a specific medication (e.g., reminder) or to alert them to one of various issues (e.g., medication bottle vacant, improper medication removal, medication bottle needing refill, etc.). All notification mechanisms (e.g., IVR, SMS, email, etc.) are possible user alerting devices. Also, information assessed from the analysis of medication reporting data can be used to remind users to refill medications or to signal third-parties (e.g., pharmacies, home care agents, caregivers, etc.) of the need for refills or to initiate refills. Contextual data can also be combined with other sensed data to make health or wellness assessments based on perceived compliance level and user activity. In some examples, the system 300 may analyze data captured by other sensors (e.g., sensors of a home monitoring system) and determine how to report a medication event based on the analysis. In these examples, the system 300 may determine whether a property is occupied by one or more persons other than the medication recipient associated with a medication event and implement different reporting strategies depending on whether the property is occupied. For instance, the system 300 may provide a local alert or reminder (e.g., audible alert in the property) for a missed or improper medication event when the system 300 determines that the property is presently occupied. The system 300 may escalate the local alert to a remote alert or reminder (e.g., a message to a remote monitoring service that dispatches emergency services) if the system 300 determines that no corrective action has been taken for a threshold period of time (e.g., the system 300 does not detect a proper medication event or receive confirmation that the improper medication event is being handled for a threshold period of time). When the system 300 determines that the property is not presently occupied, the system 300 may send the remote alert or reminder in the first instance. Historical data regarding medication compliance may be used in reporting analysis. The historical data may include information describing compliance with past medication schedules and past occupancy/usage data for the property. For example, the system 300 may determine that a first user adheres very strictly to a medication schedule based on compliance with past medication schedules and a second user does not adhere as strictly to a medication schedule, but typically complies with the medication schedule within permissible tolerances. In this example, the system 300 may send a heightened alert (e.g., a message to a remote monitoring service that dispatches emergency services) a short time after the system 300 detects that the first user misses a medication event, but may wait longer to send a heightened alert after the system 300 detects that the second user misses a medication event to allow the second user more time within the permissible tolerances. In another example, the system 300 may monitor past occupancy of the property and determine typical occupancy patterns for the property. In this example, the system 300 may use the typical occupancy patterns to infer whether the property is occupied at the time of a missed or improper medication and handle reporting for the missed or improper medication event based on the inference (e.g., as described above for examples in which occupancy of the property is detected directly). The control panel 30 also analyzes the scheduled medication events in relation to the sensor data that initiated the process to check the state of the medication for the person 20 (i.e., the output from the contact sensor 40). In this example, the control panel 30 compares the timing of the next scheduled medication events to a threshold that is set for determining whether or not to remind the person 20 of the next scheduled medication events. The threshold may be set based on user input, may be pre-set by a manufacturer or installer of the control panel 30, or may be set based on monitored activity of the person 20 over time. For instance, the control panel may analyze past output from the contact sensor 40 and determine that the person 20 leaves the home 10 for an average of one hour when the person 20 exits the home through the exterior door. Based on the determination that the person 20 leaves the home 10 for an average of one hour when the person 20 exits the home through the exterior door, the control panel 30 sets the threshold at one hour because it is relatively unlikely that the person 20 will complete a medication event that is scheduled for less than an hour after the person 20 exits the home through the exterior door and it is relatively likely that the person 20 will complete a medication event that is scheduled for more than an hour after the person 20 exits the home through the exterior door. Accordingly, the control panel 30 compares the time remaining until the next medication event for Medication One to the threshold of one hour and also compares the time remaining until the next medication event for Medication Two to the threshold of one hour. In this example, the control panel 30 determines that the time remaining until the next medication event for Medication One (i.e., twelve minutes) is less than the threshold and the control panel 30 determines that the time remaining until the next medication event for Medication Two (i.e., four hours) is more than the threshold.)
It would have been obvious to one of ordinary skill in the art before the time of filing to add to the prescription management features of Streat, the medication adherence processes of Hanson. The prior art in Streat and Kamen teaches each element claimed, although not in a single reference. One of ordinary skill in the art would have combined the elements as claimed by known methods and the in combination, each element merely would have performed the same function as it did separately. One of ordinary skill in the art would have recognized that the results of the combination were predictable. Accordingly, the combination of Streat and Hanson would have been found to be obvious by one of ordinary skill in the art.
As per claim 72,
The combined teaching of Streat and Hanson teaches the limitations of claim 71.
Hanson further teaches further comprising, each time a medication within the data store of prescriptions is to be taken, in addition to instructing the patient mobile device to present an alert, instructing the patient mobile device to digitally verify that a correct medication is being taken, wherein digitally verifying that the correct medication is being taken comprises: prompting the patient to present an identifier, affixed to a medication bottle, to a camera of the patient mobile device; and scanning the identifier presented to the camera:
(Paragraphs [0030], [0033], [0058] and [0062]-[0064] of Hanson. The teaching describes he system 300 may perform proactive care recipient guidance, reminders, and refills. To help encourage correct consumption and management of medications, several features are provided to assist those taking medications. For example, users can receive notifications preemptively reminding them to take medications prior to their scheduled times. Additionally, illumination, audio, or other user alerting devices within the installed home or facility can be employed to notify users to take a specific medication (e.g., reminder) or to alert them to one of various issues (e.g., medication bottle vacant, improper medication removal, medication bottle needing refill, etc.). All notification mechanisms (e.g., IVR, SMS, email, etc.) are possible user alerting devices. Also, information assessed from the analysis of medication reporting data can be used to remind users to refill medications or to signal third-parties (e.g., pharmacies, home care agents, caregivers, etc.) of the need for refills or to initiate refills. Contextual data can also be combined with other sensed data to make health or wellness assessments based on perceived compliance level and user activity. In some examples, the system 300 may analyze data captured by other sensors (e.g., sensors of a home monitoring system) and determine how to report a medication event based on the analysis. In these examples, the system 300 may determine whether a property is occupied by one or more persons other than the medication recipient associated with a medication event and implement different reporting strategies depending on whether the property is occupied. For instance, the system 300 may provide a local alert or reminder (e.g., audible alert in the property) for a missed or improper medication event when the system 300 determines that the property is presently occupied. The system 300 may escalate the local alert to a remote alert or reminder (e.g., a message to a remote monitoring service that dispatches emergency services) if the system 300 determines that no corrective action has been taken for a threshold period of time (e.g., the system 300 does not detect a proper medication event or receive confirmation that the improper medication event is being handled for a threshold period of time). When the system 300 determines that the property is not presently occupied, the system 300 may send the remote alert or reminder in the first instance. Historical data regarding medication compliance may be used in reporting analysis. The historical data may include information describing compliance with past medication schedules and past occupancy/usage data for the property. For example, the system 300 may determine that a first user adheres very strictly to a medication schedule based on compliance with past medication schedules and a second user does not adhere as strictly to a medication schedule, but typically complies with the medication schedule within permissible tolerances. In this example, the system 300 may send a heightened alert (e.g., a message to a remote monitoring service that dispatches emergency services) a short time after the system 300 detects that the first user misses a medication event, but may wait longer to send a heightened alert after the system 300 detects that the second user misses a medication event to allow the second user more time within the permissible tolerances. In another example, the system 300 may monitor past occupancy of the property and determine typical occupancy patterns for the property. In this example, the system 300 may use the typical occupancy patterns to infer whether the property is occupied at the time of a missed or improper medication and handle reporting for the missed or improper medication event based on the inference (e.g., as described above for examples in which occupancy of the property is detected directly). The control panel 30 also analyzes the scheduled medication events in relation to the sensor data that initiated the process to check the state of the medication for the person 20 (i.e., the output from the contact sensor 40). In this example, the control panel 30 compares the timing of the next scheduled medication events to a threshold that is set for determining whether or not to remind the person 20 of the next scheduled medication events. The threshold may be set based on user input, may be pre-set by a manufacturer or installer of the control panel 30, or may be set based on monitored activity of the person 20 over time. For instance, the control panel may analyze past output from the contact sensor 40 and determine that the person 20 leaves the home 10 for an average of one hour when the person 20 exits the home through the exterior door. Based on the determination that the person 20 leaves the home 10 for an average of one hour when the person 20 exits the home through the exterior door, the control panel 30 sets the threshold at one hour because it is relatively unlikely that the person 20 will complete a medication event that is scheduled for less than an hour after the person 20 exits the home through the exterior door and it is relatively likely that the person 20 will complete a medication event that is scheduled for more than an hour after the person 20 exits the home through the exterior door. Accordingly, the control panel 30 compares the time remaining until the next medication event for Medication One to the threshold of one hour and also compares the time remaining until the next medication event for Medication Two to the threshold of one hour. In this example, the control panel 30 determines that the time remaining until the next medication event for Medication One (i.e., twelve minutes) is less than the threshold and the control panel 30 determines that the time remaining until the next medication event for Medication Two (i.e., four hours) is more than the threshold. The control panel 30 further is connected to the camera 60. The camera 60 is positioned to have the medication tray 70 within its field of view and the camera 60 captures images of the medication tray 70. The control panel 30 provides commands to control the camera 60 to capture images of the medication tray 70 and the control panel 30 receives output from the camera 60. The output received by the control panel 30 may be the images captured by the camera 60 and the control panel 30 may process the captured images to determine a state of the medication in the medication tray 70. Alternatively, the camera 60 may process the captured images to determine a state of the medication in the medication tray 70 and provide output to the control panel 30 that indicates the state of the medication in the medication tray 70. The connection between the control panel 30 and the camera 60 may be a wired connection or a wireless connection. The system 300 further includes one or more medication containers 126 and one or more trigger sources 128. The medication containers 126 may be pill bottles or other containers or structures that are capable of storing medication for use by a patient. The medication containers 126 may be marked in an identifiable manner so that the system 300 can identify a particular medication container and distinguish between the different medication containers 126 used by a patient. For instance, the medication containers 126 may be different colors where a type of medication is associated with a color and the system 300 can determine which medicine is being taken by detecting the color of the medication container being used. The medication containers 126 also may have other identifying marks (e.g., bar codes) or the medication containers 126 may include other types of identification devices, such as radio-frequency identification (RFID) tags.)
As per claim 73,
The combined teaching of Streat and Hanson teaches the limitations of claim 72.
Hanson further teaches wherein digitally verifying that a correct medication is being taken further comprises at least one of: digitally indicating that the correct medication is being taken in response to determining that the identifier corresponds to the medication; or digitally indicating that an incorrect medication is being taken in response to determining that the identifier corresponds to another medication:
(Paragraphs [0030], [0033], [0058] and [0062]-[0064] of Hanson. The teaching describes he system 300 may perform proactive care recipient guidance, reminders, and refills. To help encourage correct consumption and management of medications, several features are provided to assist those taking medications. For example, users can receive notifications preemptively reminding them to take medications prior to their scheduled times. Additionally, illumination, audio, or other user alerting devices within the installed home or facility can be employed to notify users to take a specific medication (e.g., reminder) or to alert them to one of various issues (e.g., medication bottle vacant, improper medication removal, medication bottle needing refill, etc.). All notification mechanisms (e.g., IVR, SMS, email, etc.) are possible user alerting devices. Also, information assessed from the analysis of medication reporting data can be used to remind users to refill medications or to signal third-parties (e.g., pharmacies, home care agents, caregivers, etc.) of the need for refills or to initiate refills. Contextual data can also be combined with other sensed data to make health or wellness assessments based on perceived compliance level and user activity. In some examples, the system 300 may analyze data captured by other sensors (e.g., sensors of a home monitoring system) and determine how to report a medication event based on the analysis. In these examples, the system 300 may determine whether a property is occupied by one or more persons other than the medication recipient associated with a medication event and implement different reporting strategies depending on whether the property is occupied. For instance, the system 300 may provide a local alert or reminder (e.g., audible alert in the property) for a missed or improper medication event when the system 300 determines that the property is presently occupied. The system 300 may escalate the local alert to a remote alert or reminder (e.g., a message to a remote monitoring service that dispatches emergency services) if the system 300 determines that no corrective action has been taken for a threshold period of time (e.g., the system 300 does not detect a proper medication event or receive confirmation that the improper medication event is being handled for a threshold period of time). When the system 300 determines that the property is not presently occupied, the system 300 may send the remote alert or reminder in the first instance. Historical data regarding medication compliance may be used in reporting analysis. The historical data may include information describing compliance with past medication schedules and past occupancy/usage data for the property. For example, the system 300 may determine that a first user adheres very strictly to a medication schedule based on compliance with past medication schedules and a second user does not adhere as strictly to a medication schedule, but typically complies with the medication schedule within permissible tolerances. In this example, the system 300 may send a heightened alert (e.g., a message to a remote monitoring service that dispatches emergency services) a short time after the system 300 detects that the first user misses a medication event, but may wait longer to send a heightened alert after the system 300 detects that the second user misses a medication event to allow the second user more time within the permissible tolerances. In another example, the system 300 may monitor past occupancy of the property and determine typical occupancy patterns for the property. In this example, the system 300 may use the typical occupancy patterns to infer whether the property is occupied at the time of a missed or improper medication and handle reporting for the missed or improper medication event based on the inference (e.g., as described above for examples in which occupancy of the property is detected directly). The control panel 30 also analyzes the scheduled medication events in relation to the sensor data that initiated the process to check the state of the medication for the person 20 (i.e., the output from the contact sensor 40). In this example, the control panel 30 compares the timing of the next scheduled medication events to a threshold that is set for determining whether or not to remind the person 20 of the next scheduled medication events. The threshold may be set based on user input, may be pre-set by a manufacturer or installer of the control panel 30, or may be set based on monitored activity of the person 20 over time. For instance, the control panel may analyze past output from the contact sensor 40 and determine that the person 20 leaves the home 10 for an average of one hour when the person 20 exits the home through the exterior door. Based on the determination that the person 20 leaves the home 10 for an average of one hour when the person 20 exits the home through the exterior door, the control panel 30 sets the threshold at one hour because it is relatively unlikely that the person 20 will complete a medication event that is scheduled for less than an hour after the person 20 exits the home through the exterior door and it is relatively likely that the person 20 will complete a medication event that is scheduled for more than an hour after the person 20 exits the home through the exterior door. Accordingly, the control panel 30 compares the time remaining until the next medication event for Medication One to the threshold of one hour and also compares the time remaining until the next medication event for Medication Two to the threshold of one hour. In this example, the control panel 30 determines that the time remaining until the next medication event for Medication One (i.e., twelve minutes) is less than the threshold and the control panel 30 determines that the time remaining until the next medication event for Medication Two (i.e., four hours) is more than the threshold. The control panel 30 further is connected to the camera 60. The camera 60 is positioned to have the medication tray 70 within its field of view and the camera 60 captures images of the medication tray 70. The control panel 30 provides commands to control the camera 60 to capture images of the medication tray 70 and the control panel 30 receives output from the camera 60. The output received by the control panel 30 may be the images captured by the camera 60 and the control panel 30 may process the captured images to determine a state of the medication in the medication tray 70. Alternatively, the camera 60 may process the captured images to determine a state of the medication in the medication tray 70 and provide output to the control panel 30 that indicates the state of the medication in the medication tray 70. The connection between the control panel 30 and the camera 60 may be a wired connection or a wireless connection. The system 300 further includes one or more medication containers 126 and one or more trigger sources 128. The medication containers 126 may be pill bottles or other containers or structures that are capable of storing medication for use by a patient. The medication containers 126 may be marked in an identifiable manner so that the system 300 can identify a particular medication container and distinguish between the different medication containers 126 used by a patient. For instance, the medication containers 126 may be different colors where a type of medication is associated with a color and the system 300 can determine which medicine is being taken by detecting the color of the medication container being used. The medication containers 126 also may have other identifying marks (e.g., bar codes) or the medication containers 126 may include other types of identification devices, such as radio-frequency identification (RFID) tags.)
Claims 67, 68 and 71-73 are rejected under 35 U.S.C. 103 as being unpatentable over Streat in view of Rourke et al. (US 2016/0034668; herein referred to as Rourke)
As per claim 69,
Streat discloses the limitations of claim 54.
Streat does not explicitly teach wherein: the method further comprises providing, to a pharmacy, a pharmacy portal that provides access to the data store of prescriptions currently prescribed to the patient by the plurality of providers from different provider networks; and the provider portal presents, to a provider, an order element that, when selected, initiates a prescription to be ordered at the pharmacy.
However, Rourke teaches wherein: the method further comprises providing, to a pharmacy, a pharmacy portal that provides access to the data store of prescriptions currently prescribed to the patient by the plurality of providers from different provider networks; and the provider portal presents, to a provider, an order element that, when selected, initiates a prescription to be ordered at the pharmacy:
(Paragraphs [0073]-[0075] and Figure 1 of Rourke. The teaching describes the system provides a central portal for a patient to manage and view all of his/her prescriptions in one place, while the system may also divide and send the patient's prescriptions to different pharmacies based on pharmacies' expertise and prices. Such a system may result in more optimal costs and services and permit pharmacies to more efficiently manage their inventories. The total fulfillment system of some embodiments provides an online tracking system allowing patients, doctors, and other users of the system to track prescription orders. Such a system may allow users to track when an order has been received by a pharmacy, adjudicated, fulfilled, and shipped. The data from such a system could ideally be used to track prescription ordering histories and to provide data that can be analyzed to determine how to increase prescription fulfillment efficiencies.)
It would have been obvious to one of ordinary skill in the art before the time of filing to add to the portal system of Streat, the pharmacy portal aspects and teachings of Rourke. Paragraph [0066] of Rourke teaches that the implementation of the fulfilment system disclosed provides an improvement in the reduction of healthcare costs for a patient and results in improved patient adherence to the prescribed medication. One of ordinary skill in the art in possession of Streat would have looked to Rourke to achieve these advantages for their own patients. One of ordinary skill in the art would have added to the teaching of Streat, the teaching of Rourke based on this incentive without yielding unexpected results.
As per claim 70,
The combined teachings of Streat and Rourke teaches the limitations of claim 69.
Rourke further teaches wherein the pharmacy portal enables the pharmacy to route digital messages to any provider within the plurality of providers from different provider networks to be received via the provider portal:
(Paragraph [0094] of Rourke. The teaching describes that regarding connectivity requirements, in some embodiments, in order to join the system 200, the supplier workstation 230 must download certain software and demonstrate that it is able to successfully receive electronic messages from the healthcare hub/server 250 and reply to such messages. For example, in one embodiment, the supplier workstation 230 much establish connectivity through an HTTP Web Request/Response and format messages with an XML body. In certain embodiments, the reply messages must conform to a specified format to ensure seamless communication within the system. As one example, in some embodiments, the supplier workstation 230 must prove that it is able to receive a new prescription message from the server 250 and identify all data included in the message. In some embodiments, a new prescription message will follow the same or similar format as an Industry ERx Switch New Rx Message or other format commonly used in the industry. The message of various embodiments will include all data elements needed to fill the prescription and may include additional elements. For example, the message may include some or all of: a patient's name, date of birth, gender, shipping address, the name and quantity of the prescribed good or service, the patient's health coverage information such as a group code, BIN number, a prescription drug's PCN, if applicable, a patient's diagnoses and/or known allergies, and information about the transferring pharmacy, if applicable. In certain embodiments, in order to join the system 200, the supplier workstation 230 must also demonstrate that it is able to generate a new prescription number and construct a reply message confirming receipt of the prescription within 60 seconds (or other specified time interval), wherein the reply message includes the new prescription number. In some embodiments, the new prescription number must be unique to any other prescription received by the supplier on that date; the prescription order will remain the same for the life of the prescription. The server 250 of some embodiments will store the prescription number. In some embodiments, the supplier must also demonstrate that it is able to receive a refill request message containing the prescription number, find the original prescription associated with the refill request, respond to the refill request message within a specified time period, and successfully refill the prescription. Additionally, the supplier workstation 230 may be required to demonstrate that it can send status messages for prescription receipt, fulfillment, shipment, and optionally, delivery, as such trigger events occur. The shipment message of some embodiments must include a carrier and tracking number. In various embodiments, upon receipt and processing of the status messages by the server, the status immediately updates within the system and data transmitted to a provider workstation 220 or consumer workstation 240 reflects the update. In some embodiments, the supplier workstation 230 must also demonstrate that it has properly encrypted all messages, for example, using an encryption process such as the X509 XML encryption process.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAD A NEWTON whose telephone number is (313)446-6604. The examiner can normally be reached M-F 8:00AM-4:00PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PETER H. CHOI can be reached at (469) 295-9171. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHAD A NEWTON/Primary Examiner, Art Unit 3681
Prosecution Insights