IP Library Granted Patent US 10,755,803
Granted Patent B2
US 10,755,803 · App. 14/318,500 · Granted Aug 25, 2020

Electronic health record system context API

Inventors: Thomas William Evans (Concord, CA); Jonathan Mark Malek (Sacramento, CA); Matthew Christopher Douglass (San Francisco, CA); Ryan Paul Howard (San Francisco, CA)
Assignee: ALLSCRIPTS SOFTWARE, LLC
G16H10/60G06F19/00
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,755,803
App. No.
14/318,500
Granted
Aug 25, 2020
Kind
B2
Abstract

Embodiments allow for the retrieval of information identifying the current context (patient being seen, medical record associated with the patient, or medical field selected) of a practice member. That information may be used as a key for subsequent API calls to match data submitted with records in an EHR system. In addition, a confidence level may be associated with that context. The confidence level may describe the level of confidence that context is correctly associated with that key.

Claims (58)

1. A computer-implemented method to help an application operate more efficiently on data elements of an electronic health record (EHR) system, comprising:

receiving, from the application operated by a member of a medical practice interacting with a patient, a context application program interface (API) call; and

in response to the context API call:

retrieving a current status of the member in the application with respect to the patient,

determining, based on the current status, a plurality of keys, each key identifying one possible EHR element that is related to information of the patient in the EHR system,

for each key, calculating, by an adaptive algorithm based on historical activity of the member within a status similar to the current status of the application, a confidence value indicating how likely that key is to be selected by the member,

selecting, by the adaptive algorithm from the determined plurality of keys, a key that identifies a possible EHR element, the key selected based on whether the calculated confidence value for the selected key is above a threshold value, and

returning the selected key to the application, wherein responsive to receiving the selected key, the application prompts the member to verify that the selected key corresponds to a correct EHR element such that after the verification, the application uses the selected key to operate on the correct EHR element in the EHR system.

2. The method of claim 1 , further comprising:

retrieving a second current status of a second member in a second application with respect to the patient, wherein the second member is from the medical practice, and

wherein the calculation is based on the current status and the second current status.

3. The method of claim 1 , wherein the context API call is initiated in response to a save request by the application to save a set of data, wherein the selected key is a first key, the method further comprising:

in response to the context API call:

selecting, from the determined plurality of keys, a second key that identifies a possible EHR element, the second key selected based on whether the calculated confidence value for the second selected key is above the threshold value, and

returning the selected first and second keys to the application, wherein responsive to receiving the selected first and second keys, the application prompts the member to verify one of the selected first and second keys as a key that corresponds to the correct EHR element such that after the verification, the application uses the verified key to save the set of data to the possible EHR element identified by the verified key.

4. The method of claim 3 , wherein the verified key is used in subsequent read or write API calls.

5. The method of claim 1 , wherein the possible EHR element is a selected one of a patient, a patient's chart note, and a field of the patient's chart note.

6. The method of claim 1 , wherein the current status is a selected one of a role of the member, a current cursor position in the application, a last accessed field in the application, and a current task of the application in the foreground.

7. The method of claim 1 , wherein the calculation is performed based on a history of past selected keys, further comprising:

saving the current status, the plurality of keys, and the history of past selected keys in a feedback database; and

using, by the adaptive algorithm, data from the feedback database in a subsequent calculation.

8. The method of claim 3 , wherein the first and second keys are returned in an order based on the respective calculated confidence values.

9. A computer-implemented system to help an application operate more efficiently on data elements of an electronic health record (EHR) system, comprising:

a computing device;

a medical record database;

a context application program interface (API) server, implemented on the computing device, that receives from the application operated by a member of a medical practice interacting with a patient, a context API call; and

a processing module on the context API server that in response to the context API call,

retrieves a current status of the member in the application with respect to the patient,

determines, based on the current status, a plurality of keys, each key identifying one possible EHR element that is related to information of the patient in the EHR system,

for each key, calculates, by an adaptive algorithm based on historical activity of the member within a status similar to the current status of the application, a confidence value indicating how likely that key is to be selected by the member,

selects, by the adaptive algorithm, from the determined plurality of keys, a key that identifies a possible EHR element, the key selected based on whether the calculated confidence value for the selected key is above a threshold value, and

returns the selected key to the application, wherein responsive to receiving the selected key, the application prompts the member to verify that the selected key corresponds to a correct EHR element such that after the verification, the application uses the selected key to operate on the correct EHR element in the EHR system.

10. The system of claim 9 , wherein the processing module retrieves a second current status of a second member in a second application with respect to the patient, wherein the second member is from the medical practice, and wherein the calculation is based on the current status and the second current status.

11. The system of claim 9 , further comprising:

a feedback database;

a memory storage;

an interface module on the context API server, that in response to receiving the context API call initiated by a save request, from the application, to save a set of data, saves the retrieved current status to the memory storage; and

an I/O module, that in response to returning the selected key causing the application to use the selected key to operate on the EHR element:

receives the selected key verified by the member, the verified key corresponding to the correct EHR element;

saves the selected key to the feedback database; and

saves the set of data to the possible EHR element in the medical record database.

12. The system of claim 11 , wherein the determination is based on looking up data from the feedback database.

13. The system of claim 12 , wherein the adaptive algorithm uses data from at least one of the feedback database and the memory storage to perform the calculation.

14. A program storage device tangibly embodying a program of instructions executable by at least one machine to perform a method to help an application operate more efficiently on data elements of an electronic health record (EHR) system, comprising:

receiving, from the application operated by a member of a medical practice interacting with a patient, a context application program interface (API) call; and

in response to the context API call:

retrieving a current status of the member in the application with respect to the patient,

determining, based on the current status, a plurality of keys, each key identifying one possible EHR element that is related to information of the patient in the EHR system,

for each key, calculating, by an adaptive algorithm based on historical activity of the member within a status similar to the current status of the application, a confidence value indicating how likely that key is to be selected by the member,

selecting, by the adaptive algorithm from the determined plurality of keys, a key that identifies a possible EHR element, the key selected based on whether the calculated confidence value for the selected key is above a threshold value, and

returning the selected key to the application, wherein responsive to receiving the selected key, the application prompts the member to verify that the selected key corresponds to a correct EHR element such that after the verification, the application uses the selected key to operate on the correct EHR element in the EHR system.

15. The program storage device of claim 14 , wherein the context API call is initiated in response to a save request by the application to save a set of data, wherein the selected key is a first key, the method further comprising:

in response to the context API call:

selecting, from the determined plurality of keys, a second key that identifies a possible EHR element, the second key selected based on whether the calculated confidence value for the second selected key is above the threshold, and

returning the selected first and second keys to the application, wherein responsive to receiving the selected first and second keys, the application prompts the member to verify one of the selected first and second keys as a key that corresponds to the correct EHR element such that after the verification, the application uses the verified key to save the set of data to the possible EHR element identified by the verified key.

16. The program storage device of claim 14 , wherein the calculation is performed based on a history of past selected keys, further comprising:

saving the current status, the plurality of keys, and the history of past selected keys in a feedback database; and

using, by the adaptive algorithm, data from the feedback database in a subsequent calculation.

Assignments (8)
PATENT SECURITY AGREEMENT Recorded Jun 18, 2025
From: ALLSCRIPTS SOFTWARE, LLC
To: WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT
Reel/Frame 071682/0579 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded May 14, 2018
From: PRACTICE FUSION, INC.
To: ALLSCRIPTS SOFTWARE, LLC
Reel/Frame 045798/0095 →
SECURITY INTEREST Recorded Mar 26, 2018
From: PRACTICE FUSION, INC.
To: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT
Reel/Frame 045349/0872 →
RELEASE OF SECURITY INTEREST Recorded Feb 16, 2018
From: ORIX GROWTH CAPITAL, LLC
To: PRACTICE FUSION, INC.
Reel/Frame 044954/0691 →
SECURITY INTEREST Recorded Oct 7, 2016
From: PRACTICE FUSION, INC.
To: ORIX GROWTH CAPITAL, LLC
Reel/Frame 039969/0106 →
RELEASE OF SECURITY INTEREST Recorded Oct 7, 2016
From: VENTURE LENDING & LEASING VII, INC.
To: PRACTICE FUSION, INC.
Reel/Frame 039969/0230 →
SECURITY INTEREST Recorded Oct 14, 2014
From: PRACTICE FUSION, INC.
To: VENTURE LENDING & LEASING VII, INC.
Reel/Frame 033942/0569 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 7, 2014
From: EVANS, THOMAS WILLIAM; MALEK, JONATHAN MARK; DOUGLASS, MATTHEW CHRISTOPHER; HOWARD, RYAN PAUL
To: PRACTICE FUSION, INC.
Reel/Frame 033249/0944 →
Continuity (1)
Related Publication 20150379205A1 · Dec 31, 2015